Technical SEO audit checklist: what the report must prove before more content

Six inspection layers and one ranked backlog

A technical SEO audit checklist should cover six layers in the order a search engine meets a page: crawl access, index eligibility, JavaScript rendering, page signals such as titles, internal links and structured data, performance measured on real visits, and finally duplicate URLs and language versions. What you should receive is a ranked backlog rather than a crawler export. Each row names the problem, shows the evidence, lists the template or URL pattern affected, estimates impact and effort, assigns an owner and states how the fix will be verified. A report that cannot be turned into that table has handed the analysis back to you.

The order matters because each layer depends on the one before. A page returning the wrong status code gains nothing from a better title. That is also why the audit belongs before a bigger content budget: new articles published into a site with broken discovery inherit its faults.

Crawl access and index eligibility come first

The first pass asks whether the URLs meant to rank can be reached and kept. The auditor checks status codes, redirect chains, robots.txt rules, XML sitemaps and internal links, including how deep important pages sit and which receive no internal links at all.

A crawlable page can still be excluded by a noindex tag, a canonical pointing elsewhere or a soft 404, where the page says nothing was found while the server reports success. The Page indexing report in Search Console lists these reasons with example URLs, but the lists are capped, so they reveal patterns rather than a full inventory.

Imagine a store with 1,200 products whose filters generate far more crawlable combinations than products. The useful finding is not “too many URLs” but which combinations deserve crawling, which should be kept out and which hub pages should link to the categories that sell.

Rendering checks for pages built with JavaScript

Google processes JavaScript pages in three phases: crawling, rendering and indexing. Pages that return a success code wait in a rendering queue, and Google’s documentation says that wait can last seconds or much longer. The audit therefore compares the HTML the server sends with the HTML after scripts run, template by template, and flags anything that exists only after rendering.

Several checks come straight from Google’s JavaScript SEO basics. Google finds links only when they are anchor elements with an href attribute, so menus driven by click handlers can hide whole sections. If the original HTML carries noindex, Google may skip rendering, and a script that removes the tag later will not help. Scripts should not rewrite the canonical, and single-page apps need proper error handling to avoid soft 404s.

Evidence here is a capture, not an opinion: the rendered HTML and screenshot from a URL Inspection live test or the Rich Results Test, stored beside the finding. A note saying “possible rendering issues” without it means nobody checked.

Page signals and Core Web Vitals from real visits

Page signals are the parts of the HTML that describe a page: title, meta description, headings, link anchors and structured data. The test is consistency, not volume. Price and availability in product markup must agree with the visible page, and template-generated titles must stay unique. New schema types are a poor priority while existing markup contradicts the page.

Performance needs a distinction many reports blur. Field data comes from real users, such as the Chrome User Experience Report behind PageSpeed Insights and the Core Web Vitals report in Search Console. Lab data comes from simulated loads in Lighthouse or Chrome DevTools. web.dev is clear that lab measurement does not replace field measurement, and a lab run without a user cannot measure Interaction to Next Paint at all.

A sound performance finding starts from field data for a group of similar pages, names the metric that fails on mobile or desktop, and only then uses lab runs to locate the cause, such as the element behind Largest Contentful Paint.

Duplicate URLs, canonical ownership and language versions

Sites produce duplicates without trying: tracking parameters, sort orders, trailing slashes, protocol variants. Google’s guidance treats redirects and rel=canonical as strong canonical signals and sitemap inclusion as a weak one, notes that signals add up when they agree, and advises against using robots.txt or noindex to choose a canonical within a site.

Canonical ownership means two decisions per duplicate cluster: which URL represents it, and which part of the system emits that signal, whether a CMS field, a template helper, a redirect rule or the sitemap generator. URL Inspection shows the user-declared canonical beside the Google-selected one; when they differ, the report should name the conflicting signal that wins.

Language versions need their own check: each should declare a canonical in its own language, and hreflang sets should be complete in every direction. Picture a five-language site where one shared helper prints the English canonical on every locale. The report should name that helper once rather than list every affected page.

Template faults versus one-off page faults

Most technical faults are born in templates. A product layout without a canonical or a category page exposing every filter as a link repeats the fault on every URL built from it. One-off faults, such as a single redirect loop or a manually set noindex, exist too, but they rarely explain a sitewide pattern.

That changes sampling. Instead of sorting warnings by count, the auditor lists the templates, takes a few representative URLs from each, including an old page, a recent one and an unusual one, and inspects those in depth. Search Console’s Core Web Vitals report already groups similar pages the same way. The full crawl then measures how far each template fault spreads.

It also changes how the report reads. Say a clinic has forty service pages on one template, and a tool reports two hundred title warnings that trace back to two template fields. Written as one root cause, that is one developer task and one re-check. Written as two hundred rows, it looks like a month of work and gets postponed.

The backlog row every finding must fill

The report format is where audits differ most, and it can be agreed before work starts: put the columns in the brief or ask for an anonymised sample row. A finding without evidence cannot be reviewed, one without an owner will not be scheduled, and one without a verification step can never be closed.

Priority should combine the impact of a fault with the value of the pages it touches, weighed against effort. A missing canonical on a filtered listing and on the main category template are different priorities, even when a tool labels both with the same severity.

Proving the audit is complete before sign-off

Acceptance means confirming the audit is complete and correct, not long. Before work starts, agree a fixed URL sample: the homepage, the main commercial pages, a couple of articles, a redirected legacy address, a utility page such as internal search, and one page you know is broken. The report should give a verdict on each, including “no issue” where that is honest.

Then spot-check. Reproduce three or four findings with your developer using the live test, rendered HTML, response headers or field data; if the evidence does not reproduce, the rest of the report deserves the same doubt. Every template should also appear in the report, even if only as checked and clean.

Once the first fixes ship, Search Console gives dated proof. Validate fix in the Page indexing report re-checks URLs known to have the issue and can take days or longer. It is optional, since Google also notices fixes during normal crawling, but it leaves a record. A re-crawl of the affected patterns closes the loop.

When a narrower check is enough, and what access to grant

A full audit fits after a migration, a redesign, a change of CMS or rendering framework, a large content import, a new language or an unexplained fall in indexed pages. After a small release, a targeted check is usually proportionate: re-crawl the templates the release touched, compare their rendered HTML with the previous version, and confirm status codes, canonicals and structured data on those URLs.

Either way, the auditor needs access, or findings become guesses made from outside. Provide Search Console rights to run URL Inspection and export reports, analytics, server logs where they exist, sitemap locations, staging access, the template list, the URL families that carry revenue and recent release dates. Each missing item narrows what the audit can prove.