An audit checklist is only valuable insofar as it’s sequencing. Most of the ones in circulation are inventories, a hundred and eighty items with no sequence and no weighting, and they produce the artifact everybody complains about afterwards: a workbook that gets opened once.
The order below is the order I work in, and the sequence matters because each stage constrains the next. You can’t judge index coverage until you know what a full crawl found. You can’t judge internal linking until you know which templates render server-side. Run them out of order and you’ll spend the engagement writing tickets for symptoms.
This is written for estates in the tens of thousands of URLs and up. On a 300-page brochure site you can skip most of it, read the rendered HTML yourself and spend far less time. Google draws the same line about its own reporting: the Crawl Stats report is aimed at advanced users, and if your site has fewer than a thousand pages you shouldn’t need it at all.
Get the access and the baseline before you crawl anything
Most of the elapsed time in an audit disappears into waiting for access. Ask for everything on day one, in writing, and expect at least one item to come back refused. That refusal is itself a finding, because it tells you what the organization can and can’t see about its own site.
Search Console, as a domain property rather than a URL-prefix property. Google’s property types are explicit about the difference: a domain property covers every subdomain and multiple protocols, while a URL-prefix property covers only URLs carrying that exact prefix, protocol included. Prefix properties hide the subdomains and protocol variants where the interesting problems live, and the Crawl Stats report only opens for root-level properties anyway. Read access does the job at this stage, which is also what Google tells buyers to grant when someone offers them an audit.
Analytics with unsampled export. Then agree, before you look at a single number, which revenue or conversion metric this audit gets judged against six months from now. That conversation costs ten minutes and saves a quarter of arguing later.
Thirty days of raw server or CDN logs rather than a summarized report. Cloudflare, Akamai and Fastly all export them. It’s the request most likely to come back refused, so make it first and escalate early.
Staging credentials, plus how staging keeps crawlers out (robots.txt, HTTP auth or an IP allowlist), because that decides how much you can test before anything launches.
Then the baseline: indexed URL count, organic sessions and revenue split by template, and Core Web Vitals field data from the Chrome UX Report. Site-wide averages won’t survive the first argument about attribution.
That per-template split is the part teams skip and the part that pays for the whole exercise. A number for the whole site tells you nothing about whether product detail pages or category pages carry the business, and every prioritization call downstream depends on knowing which.
Crawl the site properly before you read the index coverage report
Seed the crawler from more than the homepage. Use the XML sitemaps, a URL export from the CMS, the top 10,000 pages from analytics, and every page Search Console reports impressions for. A crawl that only follows internal links confirms your architecture back to you and misses every orphan you own.
Run it twice, once with JavaScript rendering off and once with it on, then diff the two. The difference is the part of the site that only exists after hydration. That diff doubles as a map of what generative search can’t see, because most AI crawlers only parse the HTML response and can’t run client-side scripts.
Index coverage comes next, because the crawl tells you what the report means. Four states carry nearly all of the signal, and Google’s definitions are worth reading closely rather than from memory. “Crawled, currently not indexed” is a page Google fetched and didn’t index, with no need to resubmit. “Discovered, currently not indexed” is a page it found but hasn’t crawled, typically because the fetch looked likely to overload your site. “Duplicate without user-selected canonical” means Google picked somebody else’s URL as the canonical. “Alternate page with proper canonical tag” is behaving correctly and needs nothing from you. Sample twenty URLs from each and look at them by hand.
A large “crawled, currently not indexed” bucket is a quality and duplication signal wearing a technical label, and I’ll argue with anyone who proposes to fix it by resubmitting a sitemap. Google’s own note on that state says there’s no need to resubmit. It fetched those pages and declined them. The only question left is what’s on them.
Check rendering, architecture and internal links template by template
For rendering, take five URLs per template and compare raw HTML against rendered HTML: main copy, internal links, canonical tag, structured data. On a Next.js or Nuxt application, confirm which routes are statically generated, which are server-rendered and which fall back to the client, because those three behave differently and the team usually believes they’re all the same.
For architecture, the checks are click depth from the homepage, orphan pages that sit in a sitemap but never appear in the crawl graph, pagination on long category lists, and the faceted navigation rules deciding which filter combinations render as a link at all. Internal links stay the strongest lever you have that needs neither a content budget nor a developer.
Check the sitemaps against the crawl in both directions. A URL in your sitemap returning anything other than a 200 and a self-referencing canonical tells search engines you don’t know your own inventory.
Audit on-page, content, links and Core Web Vitals by template
Audit templates, not pages. Sample ten URLs per template and check title and heading construction, canonical behaviour under parameters, structured data validity against the Schema.org type you actually claim, and whether the primary content sits in the HTML or arrives from an API call after load.
On content, look for cannibalization first (several URLs ranking interchangeably for one query is a strategy problem in a technical costume), then for templates producing pages with nothing on them, which is standard on tag archives, location stubs and auto-generated filter pages.
On links, three things: referring domains trended over two years, broken backlinks pointing at URLs a previous migration dropped, and internal anchor text distribution. The first is context, the second is free recovery, the third you control outright.
On performance, use field data rather than lab scores. The thresholds are public and unambiguous: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1, assessed at the 75th percentile of page loads. A Lighthouse run on your own laptop is a debugging tool, not evidence.
On most enterprise sites I audit, performance isn’t the top of the list. A site failing INP while indexing correctly is in better shape than a site passing every Core Web Vitals threshold while most of its catalogue sits in “crawled, currently not indexed”. Fix the indexing first.
Prioritization is what turns an audit into shipped work
Everything above generates findings. What turns findings into engineering work is a score, and the score worth defending is estimated revenue impact divided by engineering effort, with both numbers argued out in front of the people who’ll do the work rather than assigned quietly in a spreadsheet.
Revenue impact means naming which templates this touches, what those templates earn today, and the plausible range of change. Effort means a real number from a real engineer, in days, after they’ve read the ticket. If you can’t get either number, say so in the document instead of inventing a colour-coded priority nobody can defend.
An unprioritized checklist isn’t an audit. It’s a list of homework, and homework gets filed.
The trade-off is fewer findings. A prioritized audit of a large estate might surface a dozen items worth building this quarter and explicitly park several dozen more. It looks thinner than an eighty-row issue log, and thinner is exactly why the dozen get built.
How to start an SEO audit this week
Before anyone runs a crawl, get the domain-level Search Console property, get the log files, and write down baseline revenue by template. Those three take about a week to obtain and they make every later stage interpretable. Then crawl, then read index coverage against the crawl, and only then start writing findings down.
If you’d rather have this run by somebody who’s done it on catalogues of a million URLs, that’s what my audit engagements are for, and the architectural work that usually follows sits under technical SEO.