Most published technical SEO checklists have 150 items and are useless for the same reason: they are ordered alphabetically rather than by impact, and they do not tell you what a failing result actually costs.
This is the sequence we work through, in order, with what each check is really looking for.
1. Crawl the site properly before looking at anything else
Everything downstream depends on having an accurate picture of what exists. That means a full crawl, not a sample.
Configuration matters more than people expect:
- Render JavaScript if any part of the site depends on client-side hydration. Crawling the raw HTML on a React or Vue site tells you what a crawler sees on its first pass, which is useful, but you need both views to know whether content is reaching the index.
- Respect robots.txt on the first crawl, then ignore it on the second. The difference between the two crawls is the set of URLs you are actively blocking — and that list is frequently full of things nobody meant to block.
- Set crawl depth high enough to reach the tail. Stopping at depth five on a catalog site hides exactly the pages that are orphaned.
- Crawl with and without a trailing slash, and over both protocols, if there is any history of migrations.
What you are looking for: total indexable URLs, response code distribution, depth distribution, and the gap between what is crawlable and what you thought existed.
2. Reconcile the crawl against Search Console coverage
This is the single most informative step in an audit and the one most often skipped.
You now have two lists: URLs your crawler found, and URLs Google reports in the index coverage report. The interesting findings all live in the difference:
- In the index but not in your crawl — orphaned pages, old URLs Google still remembers, or pages reachable only through a sitemap.
- In your crawl but excluded from the index — the “Discovered – currently not indexed” and “Crawled – currently not indexed” buckets, which usually mean quality or crawl-budget problems rather than technical blocks.
- Indexed but not submitted — a strong sign that parameter URLs or facets are leaking into the index.
A typical finding on a catalog site of any size is 200 or more indexable URLs that should not be indexable: parameter variants, internal search results, paginated duplicates, staging leftovers. None of them will ever earn a click, and collectively they consume the crawl budget that should be going to your category pages.
3. Read the server logs
Log files are the only source that tells you what Googlebot actually requested, rather than what you assume it requested.
Pull 30 days minimum, filter to verified Googlebot, and answer three questions:
- What percentage of crawl requests hit URLs you care about? On sites with facet problems this is routinely under 30%.
- How often are your money pages crawled? If a top category page is fetched once a month, a change you ship today takes a month to register.
- What is Googlebot hitting that you did not know existed? Old parameter patterns, redirect chains and abandoned subdirectories surface here and nowhere else.
Not every client can provide logs, and where server access does not allow it we say so rather than pretending the crawl alone is sufficient.
4. Canonical and redirect integrity
Canonical problems are quiet. Nothing breaks, nothing errors, and Google simply chooses a different URL than the one you wanted.
Check for:
- Canonical conflicts — a page canonicalising to URL A while the sitemap declares URL B and internal links point at URL C.
- Canonical chains — A canonicalises to B, which canonicalises to C. Treat these as broken.
- Self-referencing canonicals on parameter URLs, which is how facets end up indexed.
- Redirect chains longer than one hop, especially in navigation and internal links.
- Redirects to 404s, a common leftover from migrations that silently discards link equity.
5. Core Web Vitals, on field data only
Lab scores from a synthetic test on a fast connection tell you almost nothing about what your buyers experience. The metrics Google uses come from the Chrome User Experience Report — real sessions on real devices.
Assess per template, not per page. A single slow product template affects every product URL, and fixing it once fixes all of them. Diagnosing page by page produces a list nobody can act on.
The published thresholds for LCP, INP and CLS are documented in Google’s Core Web Vitals guidance, and field data is what counts toward them. If a template passes in the lab and fails in the field, the field result is the true one.
6. Index bloat and thin content
Count how many indexable URLs genuinely deserve to rank. On most sites the honest number is far lower than the total.
The usual sources:
- Tag and author archives on a blog, each holding three posts
- Internal search result pages
- Paginated series where page 2 onward duplicates page 1’s copy
- Faceted combinations, the largest source by far on ecommerce
- Print or AMP variants left over from an earlier stack
Each of these is a decision, not an automatic noindex. A paginated series may be valuable; an internal search result page almost never is.
7. Internal link graph and orphan pages
Export the internal link graph and look at two things.
Orphans — indexable pages with zero internal links pointing at them. They exist on nearly every site above a few thousand URLs and they cannot rank, because there is no path to them and no signal about their importance.
Distribution — which pages receive the most internal links. On most sites this list is dominated by navigation and footer links, meaning the pages receiving the strongest internal signal are the ones that need it least. Redirecting that signal toward commercial templates is among the cheapest wins in on-page SEO.
8. Rendering and content parity
For any site depending on client-side rendering, compare the raw HTML against the rendered DOM for a sample from each template.
What matters: is the primary content present in the initial HTML, or does it require JavaScript execution? Are internal links real <a href> elements, or click handlers a crawler will never follow? Is structured data injected client-side, and if so does it survive rendering?
None of this is automatically fatal — Google does render JavaScript — but it adds latency to indexing and introduces a failure mode that is invisible unless you check.
9. Structured data coverage and validity
Check what markup exists, whether it validates, and whether it is eligible for anything. Markup that validates but is not attached to a supported rich result type is not a problem, but it is also not a win. Google documents which types are supported in its structured data guidance.
Common findings: product markup missing required fields, review markup on pages with no visible reviews (a guideline violation), and Organization markup asserting a phone number or address the business no longer uses.
How to prioritise what you find
An audit that produces 300 findings and no ordering is a list, not a plan. Score every finding on two axes:
- Engineering effort — can this ship in a CMS field, a template change, or does it need a migration?
- Revenue impact — how many URLs does it affect, and are those URLs commercially relevant?
Template-level fixes win almost every time, because one deploy touches thousands of URLs. A title-tag pattern change on a product template is usually the highest-leverage single change available on a catalog site.
Anything that is high effort and low impact goes in an appendix and stays there.
This is the sequence behind the 12-page audit we deliver inside five business days, free, with no call required to receive it. If the honest conclusion is that your own developers can clear the list in a two-week sprint, the document will say that. See what the audit covers in full or send us your domain.
