Order matters here more than any single item does. Crawlability comes first because a page a crawler cannot reach makes every later finding on this list moot. Structured data and internal linking come last because they refine a page that a crawler can already reach and index, not fix one that can't be found at all. Run the five categories in this order and a real problem never hides behind a smaller one.
Crawlability
Crawlability decides whether a crawler reaches a page at all, before anything else on this list has a chance to matter.
- robots.txt carries no Disallow rule blocking a page that should rank
- The XML sitemap lists only canonical, indexable URLs, and matches what is actually live today, not a build from three deploys ago
- Every redirect chain longer than one hop collapses to a single 301
- Pages with no internal link pointing to them, findable only through the sitemap, get found and either linked or removed
- Content that only appears after a script runs gets checked against what a crawler sees without executing that script
Indexation
A crawler reaching a page and that page staying in the index are two different outcomes. This category checks the gap between them.
- Canonical tags point at the URL meant to rank, not a duplicate or a parameter variant
- No noindex tag survives from a staging environment
- Google Search Console's Page Indexing report gets read row by row, not just the top-line count
- URL parameters (sorting, filtering, session IDs) canonicalize to one clean URL instead of spawning duplicates
- A paginated series uses a self-canonical per page, not one long page pretending to be page one
Core Web Vitals
Three metrics decide whether a page counts as fast, and Google publishes the exact thresholds rather than leaving them to guesswork.
- Largest Contentful Paint measures at 2.5 seconds or under, the good threshold stated directly by web.dev, "Largest Contentful Paint (LCP)" (web.dev/articles/lcp)
- Interaction to Next Paint measures at 200 milliseconds or under, per web.dev, "Interaction to Next Paint (INP)" (web.dev/articles/inp)
- Cumulative Layout Shift measures at 0.1 or under, per web.dev, "Cumulative Layout Shift (CLS)" (web.dev/articles/cls)
- Field data from real visitors, via the Chrome UX Report, gets checked alongside a lab tool, since the two disagree often enough to change a finding
- Every measurement runs on the mobile version of the page specifically, since Google indexes mobile first
Structured data
Structured data tells a crawler what a page is without asking it to guess from prose. This category catches the gap between markup that exists and markup that actually works.
- Every page carries the schema.org type that matches it, not a generic WebPage fallback
- JSON-LD validates in Google's Rich Results Test with zero errors, not just zero warnings
- Every @id reference inside the graph resolves to a real node in the same document
- Required properties for the type in use are present: a Product with a price, an Article with a headline, a FAQPage with real questions and answers
- The schema describes what a visitor actually sees on the page. A rating with no visible reviews behind it is a mismatch, not a shortcut
Internal linking
Link equity moves through a site along real internal links. A page nobody links to competes at a disadvantage no matter how good the content is.
- Click depth from the homepage to every page meant to rank gets counted, not estimated
- Orphan pages, reachable only through the sitemap and linked from nowhere else, get identified
- Anchor text pointing at a page names that page’s actual topic, not a generic "click here" or "read more"
- Pages already carrying external backlinks get checked for how many internal links pass that authority onward
- Broken internal links get caught before a customer or a crawler hits one
What this checklist doesn't replace
A crawler tool produces most of the raw data behind this checklist in minutes. What it doesn't do is decide which finding matters first, or read a flagged item and recognize it as a false positive on a page that was never meant to rank anyway. That judgment call is the part a spreadsheet export skips, and it's the part that turns 25 checks into an ordered fix list instead of an ordered pile of warnings.
When to run this again
Run it immediately after a redesign or a migration. Both change what a crawler sees overnight, and a delayed check means weeks of an invisible defect eating traffic before anyone notices. Outside of that, a quarterly cadence suits a site that keeps changing; a site that rarely changes needs it less often. A site that has not been checked since its last redesign is running on assumptions, not a current picture.
Running this checklist by hand answers the mechanical half of the question: can a crawler reach, index, and correctly read the page. Turning 25 checks into one prioritized fix list your developer can act on, scoped and delivered against a specific site, is what a technical SEO audit engagement does with the same five categories above.
Questions
Does passing this checklist guarantee a top Google ranking?
No. Passing it removes crawl, index, and rendering problems from the list of reasons a page isn't ranking. Ranking position is decided by systems outside any consultant's or business's control, so nothing here or anywhere else guarantees a specific position. What the checklist does is rule out the mechanical explanations first, so whatever diagnosis comes next, content, backlinks, competition, starts from a clean baseline instead of an unknown one.
What tools do you use to run this checklist?
A site crawler for the raw data, Google Search Console for indexation and field Core Web Vitals numbers, and a manual pass through every flagged item before any of it reaches a fix list. The crawler produces a list of candidates. The manual pass decides which ones are real and which one is a false positive on a page that was never meant to rank in the first place.
How long does it take to run this checklist properly?
Length scales with site size, not a fixed hour count: a five-page brochure site and a two-thousand-page catalog run the same five categories at very different speeds. What stays constant is the order. Crawlability and indexation come first, because a problem in either one can make a later finding, however real, irrelevant until the earlier one is fixed.
Does this checklist cover AI crawlers, not just Google?
Crawlability checks whether GPTBot, PerplexityBot, and Google's own crawler can all reach a page, not Google's crawler alone. Whether an AI assistant goes on to cite that page correctly, once it can reach it, is a separate and more specific measurement, covered on the AI search visibility page, not this checklist.
I already pass the Rich Results Test. Does the structured-data check still apply?
Passing the Rich Results Test confirms the markup is syntactically valid, not that it's complete or accurate. A JSON-LD block can validate with zero errors and still omit a type the page needs, or describe something the page doesn't actually show. The check above goes past validation into whether the schema matches the page it sits on.
Crawlability above covers whether an assistant can reach a page at all. Whether it goes on to cite that page correctly is a separate, more specific measurement, covered on the AI search visibility page.