Run any crawler over a site and it will produce several hundred findings, colour-coded by severity the tool assigned. The severity reflects how confident the tool is that it found something, not how much that something matters to your rankings. Working through the list top to bottom is how audits take three months and change nothing.
This is the order we use instead. It is ordered by dependency: each step only matters if the steps before it pass. The reasoning is given for each so you can adapt it, and the last section lists the findings that most checklists include and that you can safely leave until the end.
Before the checklist, three sources
A crawl tells you what a crawler can reach from the homepage. Server logs tell you what Googlebot actually fetched, and how often. Search Console tells you what Google indexed and what it decided to do with the rest. Most technical problems live in the gaps between these three.
Pages in the crawl but absent from logs have a discovery problem: Google is not fetching them, usually because of link depth, crawl budget, or a robots directive. Pages in the logs but not indexed have a quality or duplication problem: Google fetched them and chose not to keep them. Pages indexed under a different URL than the one you intended have a canonicalisation problem.
Get all three before writing a finding. Without logs, on a small site, Search Console’s crawl stats and URL inspection are an acceptable substitute.
The checklist, in dependency order
1. Discovery
Can Google find every page you want indexed? Check that robots.txt does not block anything important, that the XML sitemap lists only indexable, canonical, 200-status URLs, and that every important page is reachable through internal links within three or four clicks of the homepage. Compare the sitemap URL count with the crawl’s count of indexable pages; a large difference in either direction is a finding. Check that paginated, filtered, or parameterised URLs are not generating an unbounded number of crawlable pages that dilute crawl attention.
2. Indexing
Of the pages Google found, which did it keep? Search Console’s page indexing report groups excluded pages by reason. “Crawled, currently not indexed” and “Discovered, currently not indexed” are the two that matter most. The first usually means thin, duplicate, or low-value content; the second means crawl budget or link depth. Sample ten URLs from each group and inspect them. Do not try to fix all of them; find the template or section they share.
3. Rendering
Does Google see the same content a user does? For each template, compare the raw HTML response with the rendered DOM, then check the rendered HTML Google actually indexed using URL inspection. Content that only appears after client-side JavaScript runs is indexed later, less reliably, or not at all; Google’s JavaScript SEO basics describes the two-wave process behind that. The usual fix is server rendering or static generation for indexable templates, and removing any dependence on client-side fetches for primary content. This step is why JavaScript-framework sites often have fine content and poor rankings.
4. Canonicalisation and duplication
Does every indexable page declare itself canonical, and does Google agree? Check that canonicals are absolute, self-referencing, and consistent with the sitemap and internal links. Find duplicate content across trailing slash variants, uppercase and lowercase paths, HTTP and HTTPS, www and bare domain, and tracking parameters. Search Console’s “Duplicate, Google chose different canonical than user” is the report to read. Pick one URL form for the whole site and enforce it with redirects, not only with canonical tags; Google’s documentation on consolidating duplicate URLs lists the signals it weighs.
5. Redirects and status codes
Every non-200 response in the crawl is a finding, ranked by how many internal links point at it. Redirect chains waste crawl budget and dilute signals; collapse them to a single hop. Soft 404s (a page that says “not found” with a 200 status) confuse indexing. Internal links to redirected URLs should be updated to the final destination.
6. Internal linking and depth
Which pages receive internal links, and are they the pages you want to rank? Export internal link counts per URL and compare them with commercial value. It is common to find the pricing page with three internal links and a four-year-old blog post with three hundred. Orphan pages (no internal links) will not rank regardless of content. Fix at the template level: navigation, footer, related-content modules, and breadcrumbs move far more links than hand-editing pages.
7. Structured data
Does the structured data validate, and does it describe content that is visible on the page? Run each template through Google’s Rich Results Test and the Schema Markup Validator. Remove types that no longer earn anything: HowTo rich results were retired and FAQ rich results restricted in August 2023, and FAQ rich results were retired for all sites in May 2026, so marking up FAQs is maintenance without benefit. Check that Organization, Article, Person, and BreadcrumbList nodes reference each other by @id rather than repeating the data, and that author and publisher entities point at real, visible people and organisations.
8. Core Web Vitals
The three Core Web Vitals are Largest Contentful Paint (target under 2.5 seconds), Interaction to Next Paint (under 200 milliseconds), and Cumulative Layout Shift (under 0.1), assessed at the 75th percentile of real users. INP replaced First Input Delay in March 2024; if a report still shows FID, it is out of date. Use field data from the Chrome UX Report or your own real-user monitoring to find which templates fail, then use Lighthouse to diagnose why. Lab scores are a diagnostic tool, and a page can score well in Lighthouse and fail in the field. Typical fixes are image sizing and format, font loading, third-party scripts, and reserving space for late-loading elements.
9. Access for AI search and answer engines
Answer engines and AI overviews fetch pages with their own crawlers and reward the same things Google does, plus a few of their own. Check that robots.txt does not block GPTBot and OAI-SearchBot, ClaudeBot, PerplexityBot, and Google-Extended unless that is a deliberate policy. Check that primary content is in the HTML, not behind client-side rendering, because most of these crawlers do not execute JavaScript. Check that each important page has at least one self-contained passage that answers its question in a few sentences, that authors are named, and that dateModified is present and true. A plain-text /llms.txt describing the site is cheap and increasingly read.
10. Everything else
Titles and descriptions missing or duplicated across templates, hreflang errors on multilingual sites, mixed content, mobile usability, and image optimisation belong here. They matter, and they come after the nine items above because none of them will help a page Google cannot fetch, render, or index.
What to ignore, or fix last
Most checklists include these. Most of them do not affect rankings, and time spent on them is time not spent above.
Missing alt text on decorative images. Alt text matters for accessibility and for image search on images that carry meaning. On a decorative divider it is noise.
“Low word count” warnings. Word count is not a ranking factor. A short page that answers the query beats a long one that circles it.
H1 length, multiple H2s, or “H2 before H1” ordering flags. Google reads headings for structure, not for compliance with a tool’s rule set. One H1 per page is a good convention; the rest is style.
Meta keywords. Ignored by Google for well over a decade.
Exact keyword density. Not a thing.
Domain-level authority scores. Third-party estimates of a site’s link profile, not a Google metric.
Turning findings into a plan
A finding is not a task. To turn the list into a plan, give each item three attributes: the number of URLs affected, the traffic or commercial value of those URLs, and the effort to fix at template level. Sort by the first two multiplied, divided by the third. A rendering fault on a product template that affects five hundred pages carrying most of the revenue sits at the top. A missing description on a single archived post sits at the bottom, if it appears at all.
Then write each item for the developer who will ship it: the problem, the evidence, the exact change, and how to verify it. The quality of that ticket decides whether the fix ships in a week or sits for a quarter.
This is the checklist behind the audit we run, and it is delivered as part of our technical SEO service either as pull requests or as tickets. If you are comparing agencies, how SEO agency pricing works explains why “technical SEO” on a quote can mean a list of findings or shipped code, and why the price difference is large.