Sites that load fast and convert
Custom builds and integrations
Bounded, auditable, human-approved
Being found, staying fast, staying safe
Content and links get the attention, and neither matters if a page is blocked by a stray line in robots.txt, buried four clicks deep with no internal links, or served as an empty shell that only fills in once JavaScript runs.
Technical SEO is unglamorous plumbing, and it is where most of the recoverable losses sit. It rarely creates rankings on its own — what it does is stop a site from throwing away the rankings its content had already earned, which on a neglected site is a substantial amount.
Move over the graph to crawl it ↓Scope
All six are about access rather than quality. A page can be excellent and fail every one of them.
Every page needs a link from somewhere a crawler already visits. A page reachable only from a search box, a dropdown that needs JavaScript, or nowhere at all is effectively unpublished.
The term: orphan pages. Common after redesigns.
A single misplaced line in robots.txt can exclude a whole section. It happens most often when a staging rule survives the move to production and nobody checks.
Takes: minutes to fix, months to notice.
If the page arrives empty and fills in through JavaScript, indexing depends on a rendering pass that is slower, delayed and less reliable than reading HTML.
Affects: most single-page applications by default.
Noindex tags, canonical tags pointing somewhere else, and conflicting signals between the sitemap and the page itself. Individually small, collectively decisive.
Frequent cause: a plugin default nobody reviewed.
Thousands of near-identical filter and pagination URLs dilute a site. Search engines index a subset and choose which — and the one they pick is often not the one you wanted.
The term: index bloat. Faceted navigation is the usual source.
Every redesign retires URLs. Without redirects, the links and rankings those pages accumulated are discarded — and the visitor gets a 404 instead of the thing they clicked.
Cost: permanent, and entirely avoidable.
Interactive
A site with a thousand real URLs, each blocker switched on. Turn them off one at a time and watch how much of the site comes back.
None of these are exotic and no single one is fatal. They compound — each blocker takes a share of what survived the last one, which is why a site can look basically fine on inspection and still have two thirds of its pages missing from the index.
Interactive
Five ways a site handles an address that used to work. Four of them lose something; one is correct and takes about the same effort.
Redirects are the most common thing done badly during a redesign, and the damage is invisible from inside the business. Nobody at your company clicks the old URLs — but the links pointing at them, and the people following those links, are real.
Coverage
The audit runs against your live site rather than a staging copy, because the two are rarely identical and it is the live one that search engines see.
Diagnostics
JavaScript rendering
Platforms audited
Servers, CDN & delivery
Patterns
Not exotic failures. These are the ordinary ones, and they appear on well-built sites run by competent people.
The most common and most costly. A relaunch changes the URL structure, nobody maps the old addresses to the new ones, and every accumulated link points at nothing.
Usually the first thing we fix
The page source is a near-empty shell. It usually gets indexed eventually, but slower, less reliably, and often missing the parts that load last.
Almost every React or Vue build
Faceted navigation generating a distinct address for every combination of colour, size and sort order. The crawler spends its time there instead of on your real pages.
Every e-commerce site over a certain size
A page in the sitemap, canonicalised to a different URL, linked with a nofollow, and carrying a noindex from a plugin. Each was added by someone with a reason.
Accumulates quietly over years
Pages that matter commercially sitting five clicks from the homepage with two internal links, while a tag archive nobody reads has forty.
Invisible without a crawl
Schema copied from a tutorial that describes a different business, contradicts the visible page, or was never added at all on the templates where it would help.
Modest effect, low cost, often skipped
Honesty
It is a necessary condition, not a sufficient one, and the industry is not always straight about that distinction.
A perfectly crawlable page about a subject with no demand, or one that says less than the pages already ranking, will not rise because its markup improved.
Technical work removes obstacles. If the obstacles were the whole problem the recovery is dramatic; if they were not, it is modest and honest reporting should say which.
Recrawling and reindexing take time, and larger or lower-priority sites wait longer. Weeks is normal, and a fix deployed today is not measurable tomorrow.
A clean audit degrades. New templates, plugins, redesigns and content all reintroduce issues, which is why a periodic recrawl beats a one-off certificate.
Speed is related and separate. Crawlability determines whether a page is seen; performance affects whether visitors stay and how efficiently the site is crawled.
Most technical problems are fixable in place. If someone recommends replacing the site to solve them, ask specifically which issue requires it.
Scope
A full crawl first, then a prioritised list, then the fixes — with the order decided by impact rather than by ease.
Every URL a crawler can reach, with status codes, directives, canonicals, depth and internal link counts recorded for each.
What is actually indexed versus what should be, using Search Console alongside the crawl, because the gap between the two is the finding.
Raw HTML compared against the rendered page, so content that exists only after JavaScript runs is identified rather than assumed to be fine.
Old URLs recovered, mapped to their closest equivalent, implemented as single-hop permanent redirects and verified after deployment.
Click depth, internal linking and navigation assessed against which pages actually matter to the business.
Robots, sitemaps, canonicals, noindex and parameter handling reconciled so every signal says the same thing.
Validated markup for the templates where it earns something, matching the visible content rather than contradicting it.
We make the changes, or hand your developers a specific list with the reasoning attached. Both are normal.
A recrawl after deployment to confirm the fixes landed, plus monitoring so the next regression is caught in weeks rather than a year.
Questions
The clearest signal is a gap between the number of pages you have and the number indexed. Search Console shows it directly, and most site owners have never opened that report.
Traffic that dropped after a redesign without a content change is the other classic indicator, and it is almost always redirects.
Not inherently, but it needs deliberate handling. If the HTML arrives essentially empty and the content appears only after JavaScript executes, indexing becomes slower and less reliable.
Server-side rendering or pre-rendering solves it. Whether that is a small configuration change or a real piece of work depends on how the application was built.
Weeks, typically. Pages have to be recrawled and reassessed, and that queue is not under anyone's control.
Some fixes surface faster — restoring redirects to pages with existing links tends to show sooner than architectural changes.
Yes, and it is often the better arrangement. You get a specific list — the issue, the affected URLs, the change required and why it matters — and your team implements it.
We then recrawl to confirm the fixes landed as intended, which catches the ones that were half-applied.
The audit and fixes are a defined project. What follows is genuinely worth monitoring, because every deployment and every plugin update can reintroduce something.
For most sites a quarterly recrawl is enough. Large or frequently changing sites benefit from something continuous.
It removes the ceiling; it does not replace the content. If pages were being blocked, fixing that reveals whatever quality was already there — for better or worse.
The audit will say which of the two situations you are in, and that is worth knowing before spending on either.
Related and covered separately, because they are a different kind of work with different tooling and different fixes.
Crawlability decides whether a page can rank at all. Speed affects experience, conversion and how efficiently a large site gets crawled.
Usually not. The overwhelming majority of technical issues are fixable on the site you already have, frequently in days.
If someone recommends a rebuild to fix technical SEO, ask which specific issue requires it. Occasionally there is a real answer; more often there is not.
Call back
Leave a number and a good time. We will call you back to talk about what you are trying to build — no charge for the conversation.
Or call us directly +1 (647) 385-5532