Technical SEO is eligibility engineering: crawlability, rendering, canonical discipline, redirects, structured data and speed. Content decides whether you rank; the technical layer decides whether you are allowed to compete at all. Audit order matters, and most audits run it backwards.
The audit sequence, ordered by cost of being wrong
1. Crawl and render
What do bots actually receive? Not what a browser shows — what arrives in the HTML response.
Client-side rendering, blocked resources, an over-broad robots.txt rule, a stray noindex left from a staging deploy: any one of these can make substantial portions of a site invisible while everything looks correct to a human visitor. And the stakes are higher for AI crawlers, which do not execute JavaScript at all — the GEO article covers that consequence in full.
This is first because nothing below it matters if it fails.
2. Status and redirect hygiene
404s where equity used to live. Redirect chains taxing every hop. And the most expensive self-inflicted wound available in search: a redesign that renamed URLs without 301s.
That last one deserves emphasis because it is both common and entirely avoidable. Every renamed URL without a redirect hands back the accumulated ranking signal of that page — every link earned, every year of history. The internet does not know your new sitemap exists; it knows the old one, link by link. The redesign service exists because this keeps happening to businesses whose designers considered redirects an IT concern.
Redirect to the specific successor, never in bulk to the homepage. A redirect to / is a soft 404 with better manners, and search engines treat it accordingly.
3. Canonical discipline
Parameter variations, http and https twins, www and non-www, trailing-slash duplicates, staging environments accidentally indexed. Every duplicate splits signals between versions of the same page, so both rank worse than one would.
One URL per intention. Everything else canonicalised or redirected, consistently, including in your own internal links — because internal links that point at the non-canonical version undermine the canonical tag you just added.
4. Structured data
Valid, connected, and honest. Schema that overclaims — marking up things that are not really reviews, or products that are not really products — invites manual action, and the recovery is slower than the gain was ever worth. Schema that underclaims leaves eligibility unearned.
The part teams miss is connected: separate islands of schema on separate pages are weaker than one graph with stable identifiers that link organisation, person and offerings across the site.
5. Speed
Core Web Vitals measured on real pages under real conditions, not on a developer’s laptop on office wifi. The causes are almost always the same three: unoptimised images, render-blocking fonts, and JavaScript nobody has audited since it was added.
Fix causes rather than scores. A score improved by deferring something that visitors need is a worse page with a better number.
The maintenance truth
Technical SEO decays through deployments, not through time. A release that changes routing, adds a script, or alters rendering can undo months of work in an afternoon, and nobody will notice until traffic moves.
So the maintenance schedule should follow your release cadence: a re-crawl after significant deployments, plus a quarterly check for drift. What it should not be is a monthly retainer producing reports about weather — that shape of engagement bills for attention rather than delivering it.
Measure in Search Console, not dashboards
Vendor dashboards estimate. Search Console holds the ground truth: which queries produced impressions, which produced clicks, which pages are indexed and which are excluded and why.
The critical operational fact about it: it does not backfill. Data accumulates from the day you install it, and every week without it is query data permanently unavailable. That is why “install Search Console and Bing Webmaster Tools today” is the first item on every audit I run — before content, before fixes, before strategy. It costs nothing and the alternative is deciding without evidence for however long it takes someone to remember.
What a good audit deliverable looks like
Findings ranked by impact per unit of effort, with the three that actually move the needle flagged as such at the top. Each finding stated as a specific, verifiable change rather than a category — “add 301 from these 47 URLs to these successors” rather than “improve redirect strategy”.
And a re-crawl afterwards that proves the delta. An audit without a verification pass is an opinion; an audit with one is a completed piece of work.
If the deliverable is forty pages and the reader cannot tell what to do on Monday, it was written to justify a fee rather than to change a site.
The five checks worth running yourself, this week
None of these need a specialist, and each takes minutes.
Fetch a key page without JavaScript — curl it, or disable scripts — and read what comes back. If your commercial content is missing, stop reading this article and fix that.
Search your own domain in Google with a site: query and count the results against what you expect. Wildly more means duplicates; wildly fewer means indexing problems.
Click three internal links from your own homepage and check for redirects in the chain. Internal links pointing at redirected URLs are free performance left on the table and a sign that a migration was never finished.
Check a phone page on a real phone on mobile data. Not a simulator. The gap between the two is where most speed problems live.
Open Search Console and look at the coverage report. If it is not installed, that is finding number one, and it is the only one on this list with a permanent cost for delay.
Anything alarming in those five justifies a proper audit. Nothing alarming means your problem is probably content rather than plumbing, which is a much better place to be.
The three findings that recur most often
Across audits, the same three problems account for a disproportionate share of lost eligibility.
A rendering gap nobody knew about. Usually a section of the site — the blog, the product catalogue, a filtered listing — mounting client-side while the rest is static. It looks fine to everyone internally, because everyone internally uses a browser.
A redesign that lost URLs. Sometimes years earlier, still costing traffic, and reconstructible from old sitemaps or archive snapshots if anyone looks. The equity does not come back on its own, but the redirects can still be laid and often recover a meaningful share.
Search Console installed late or not at all. Which means the data needed to diagnose everything else does not exist for the period in question, and cannot be recovered. It is the one finding whose cost is strictly a function of delay, which is why it heads every list I write.
None of the three is sophisticated. All three are common, and each is cheaper to fix than to keep paying for.
Related reading
/blog/generative-engine-opt — the AI-crawler consequences of the same audit · /blog/local-seo — the map-pack layer · /blog/google-updates — what updates actually reprice · /services/technical-seo — the audit, run for you
Questions I actually get
What is the correct audit order?
Crawl and render first, then status and redirect hygiene, then canonical discipline, then structured data, then speed. That order is by cost of being wrong, not by ease of fixing — a rendering failure makes everything downstream irrelevant, while a slow image costs a fraction of a ranking.
Our agency says everything is fine.
A crawl report settles it in a week, either way, and costs less than the argument. If they are right you have documentation; if they are not, you have specifics rather than a disagreement about competence.
Does the CMS matter?
Barely. WordPress, Shopify, custom builds — the protocol layer does not care. What differs is which traps each platform sets by default, and those are knowable per platform rather than mysterious.
Is technical SEO a one-time project or ongoing?
A project plus a quarterly check, plus a re-crawl after significant releases. Decay comes from deployments rather than from time passing, so the maintenance schedule should follow your release cadence rather than the calendar.
How much does site speed actually matter?
It matters at the margin and it matters more on mobile than most desktop-based teams assume. It is fifth on the list because a fast page that crawlers cannot render is still invisible — fix eligibility first, then fix experience.
What should we measure success against?
Search Console, not vendor dashboards. It holds the ground truth on impressions, clicks and queries, and it does not backfill — which is why installing it before you need it is the first item on every audit I run.