Technical SEO Audit: The Checklist Nobody Verifies

Search “technical SEO audit” and page one hands you two things: audit tools that will crawl your site for free, and ten-step guides that end the same way every time — with a prioritized findings list. Export the crawl, triage the errors, fix the criticals, done. What no ranking guide tells you is what happens after “done.” The canonical fix shipped. Did anything change? The 40-page audit PDF cannot answer that, because the audit ended the day it was delivered — and the number that would prove the fix worked does not exist until roughly three weeks later, in Search Console.

This guide argues that an audit ending at the findings list is half a job. The other half — the half almost nobody ships — is committing each fix to a Search Console metric before it ships, then re-reading that metric about three weeks later and recording whether it moved. Below is a repo-first checklist across the five layers that matter — crawl, indexation, canonicals, structured data, Core Web Vitals — with each item tied to the metric that will judge it. This is the technical layer of our agentic SEO pillar; the verification mechanics it leans on are covered in depth in the sibling guide on closed-loop SEO.

The audit that ends at a findings list is half a job

A technical SEO audit is a systematic check of whether search engines can crawl, index, understand, and quickly render your site. That part every guide gets right. Where the standard playbook fails is its definition of finished: the deliverable is the document. Findings ranked by severity, screenshots of the crawler dashboard, a traffic-light summary. The implicit contract is that someone else will do the fixing, and nobody at all will do the proving.

The result is a pattern anyone who has bought an audit will recognize. Three months later, half the criticals are fixed, a quarter are disputed, and no single fix can be tied to a single movement in the data. Was the indexation recovery caused by the sitemap fix or by the crawl-budget change that shipped the same week? Nobody can say, because nobody committed in advance to the metric that would judge each fix, and nobody scheduled the re-read. The audit produced work; it never produced proof.

A findings list tells you what might be wrong. Only a re-measured metric tells you the fix did anything. The audit industry ships the first and quietly hopes nobody asks for the second.

The fix is structural, not heroic: every finding leaves the audit carrying three fields — the expected impact, the Search Console metric that will judge it (clicks, impressions, CTR, or position), and the target that counts as success. When the fix ships, a timestamp is recorded. About three weeks later, the metric is re-read and the verdict written down: confirmed, regressed, or inconclusive. That is the whole other half. It fits in three columns on a task board, and it changes what the word “audit” means.

Repo-first beats crawl-first

The second thing the standard playbook gets backwards is where the audit looks. The classic method is crawl-first: point a crawler at the rendered site, wait, and reverse-engineer the causes from the symptoms. That was the only option when auditors were outsiders. But if you — or your agent — can read the repository the site is built from, the source of truth for most technical SEO is sitting in a handful of files, current and exact, with no crawl delay and no rendering ambiguity.

On a modern framework site, robots rules, the sitemap, canonical logic, metadata, redirects, and structured data are all code. A crawler tells you a page has two conflicting canonicals; the repo tells you which template writes each one and why. A crawler samples; the repo is exhaustive — a canonical bug in one layout file is a canonical bug on every page that layout renders, and you can know that from a single file read. On a Next.js site, the first pass of an audit is reading perhaps ten files.

Crawling still has a place — it is the integration-only fallback when there is no repo to read, and it remains the honest check that what the code intends is what the server serves. But the order matters: read the source first, crawl to confirm, and use Search Console throughout as the record of what Google actually did with it all.

The repo-first checklist, layer by layer

Five layers, in dependency order — each one is a precondition for the ones after it. A page that cannot be crawled cannot be indexed; a page indexed under the wrong canonical splits whatever signals it earns; schema on a page nobody can find marks up nothing. For each layer: what to read, what to look for, and the Search Console metric that will verify the fix.

1. Crawl — can search engines reach it?

Read the robots rules and the middleware before trusting any crawler output. The classic failures are all source-visible: a disallow rule written for staging that shipped to production, middleware that redirects or challenges bot user-agents, redirect chains assembled across config and code, and internal links pointing at redirected or dead URLs. On a site we audited, an entire template’s pages were invisible to engines not because of content quality but because a route-level rule quietly excluded them — a one-line find in the source that no amount of dashboard-staring had surfaced. Verification metric: impressions on the affected URLs — pages that become crawlable start being shown, and that shows up within the three-week window.

2. Indexation — is the right set of pages in the index?

Compare three sets: what the sitemap declares, what the repo actually routes, and what Search Console reports as indexed. The gaps are the findings. Pages in the sitemap that return errors, routed pages missing from the sitemap, noindex directives left over from launch, and the quiet weed problem — parameter URLs, tag archives, and paginated duplicates soaking up crawl attention that your money pages need. Indexation is also where bloat hides: a thousand thin, auto-generated pages in the index dilute rather than help. Verification metric: impressions for pages you got indexed; position on the pages you pruned around, which stop competing with themselves.

3. Canonicals — does every page have exactly one address?

The highest-leverage read in the whole audit, because canonical logic usually lives in one or two template files and an error there multiplies across the entire site. Check that every route emits exactly one canonical, that it is absolute and self-consistent (trailing slash, protocol, www), that parameterized and paginated variants point where they should, and that nothing canonicalizes to a redirect or a 404. Duplicate-address problems rarely look dramatic in a crawl — they look like a site that ranks slightly worse than it should everywhere at once, because every split URL splits its signals. Verification metric: position on the queries the consolidated page serves — consolidation shows up as the surviving URL ranking where two half-URLs used to hover.

4. Structured data — can engines classify what they read?

Read the JSON-LD components, not the rendered output, and ask three questions: is the schema valid, is it truthful, and is it attached to the right template? The common repo-visible failures are schema describing content the page no longer has, FAQPage markup whose questions drifted from the visible FAQ, and article markup missing the author and date fields engines actually use. Schema matters twice now — for classic rich results, and because a passage an engine can classify confidently is a passage it can quote in an AI answer, which is the territory of answer engine optimization. Verification metric: CTR on the marked-up pages’ queries — rich results change how the listing looks, and how a listing looks changes who clicks it.

5. Core Web Vitals — does it render fast enough to keep?

The thresholds are documented and non-negotiable: Google’s “good” bar is LCP within 2.5 seconds, INP within 200 milliseconds, CLS within 0.1, judged at the 75th percentile of real-user visits. The repo-side reads: unoptimized or unsized images, fonts loaded without a swap strategy, third-party scripts blocking the main thread, and client-side JavaScript hydrating components that could have stayed static. Confirm with field data — lab scores flatter every site. CWV is the layer most likely to be over-prioritized, so score it honestly: it is a tiebreaker and a user-experience floor, not a rankings lever. Verification metric: position on head queries where you sit within a place or two of a faster competitor — and expect this one to verify inconclusive more often than the other four.

The other half: verifying every fix in Search Console

Here is the discipline that separates an audit from a findings list. Before any fix ships, the finding is recorded as a task carrying its proof contract: the expected impact in plain terms, the verify metric from the table above, and the target that counts as success. The fix ships with a timestamp and a note of exactly what changed — the commit, the PR, the files. Then the clock runs. Google has to recrawl the page, reprocess it, and accumulate enough fresh query data to compare against the before-window. In practice that takes about three weeks — shorter and you are reading noise, much longer and other causes crowd in.

At the three-week mark, the metric is re-read on the affected URLs and queries, and the verdict is written down. Confirmed: the committed metric hit its target and held — the fix is proven, and you now know something about your site you did not know before. Regressed: it moved the wrong way — the fix reopens with better information. Inconclusive: the data cannot yet say — schedule one more read, then accept the honest null. All three are results. The only failure mode is the one the standard audit institutionalizes: marked done, never measured.

Note what committing the metric in advance quietly prevents: goalpost-moving. If the canonical consolidation was supposed to move position and instead impressions rose somewhere else, the honest verdict is not-confirmed — not a victory lap around whichever chart turned green. The full taxonomy of which numbers can carry that weight, and which are vanity, is the subject of the sibling guide on SEO KPIs; the short version is that a metric only proves anything if it was chosen before the fix and can be traced to it.

Run it as a board, not a document

The reason the verification half almost never ships is not that anyone disputes it — it is that no human reliably remembers, three weeks after each of thirty fixes, to re-read a specific metric on a specific set of URLs. Vigilance does not scale; systems do. The working shape is a task board where every audit finding lands as a task with its proof contract attached, every shipped fix flips to done with its timestamp and PR, and a weekly monitor reads Search Console and writes verdicts onto anything past its verification date. The audit stops being a document with a delivery date and becomes a loop with a cadence — which is the whole thesis of closed-loop SEO, applied to the technical layer.

Run this for a couple of quarters and a second-order asset appears: a per-site record of which technical tactics actually verify. Canonical consolidations confirming reliably; schema additions moving CTR on commercial templates but not informational ones; CWV work reading inconclusive twice in a row. The next audit starts from that evidence instead of from a generic severity scale — which is precisely the difference between auditing a site for the first time forever, and getting smarter about one site every cycle.

What verification will honestly tell you

A caution the tool-shaped guides never include: run this loop honestly and a meaningful share of your technical fixes will verify inconclusive. That is not a flaw in the method — it is the method working. Plenty of technical work is hygiene: real, worth doing, and individually too small to move a query-level metric against background noise. The loop does not exist to flatter every fix. It exists to stop you spending another quarter on the category of fix that never confirms, and to double down on the category that does.

It also recalibrates severity. Crawler dashboards score issues by how detectable they are, not by how much they cost you — a thousand “missing alt text” warnings photograph well in a report, while one template-level canonical bug quietly halves the signals of every page it touches. After a few cycles of verdicts, severity stops being the crawler’s opinion and starts being your own site’s measured history. And in a results page increasingly headed by AI answers — the query this article targets carries an AI Overview and roughly a thousand searches a month — the crawlable, canonical, classifiable page is also the page that can be cited at all, which is where the technical layer meets zero-click SEO.

If you want to see the find half run against your own data, the free SEO report connects your Search Console and surfaces where the technical layer is costing you — the pages shown but never chosen, the URLs competing with themselves. And if you would rather the whole loop ran without you driving each step — findings filed, fixes shipped, verdicts read three weeks later — book a call and we will walk you through how the audit becomes a system.