A practical checklist for technical SEO audit

A technical SEO checklist should protect you from skipped evidence. It should not force every website through the same hundred warnings. The best checklist follows the search pipeline: request, crawl, render, understand, index, and serve.

Use this checklist before, during, and after an audit. Each item needs either evidence, an intentional exclusion, or an unavailable state.

Before the crawl

• Write the audit question and business reason.
• List included hosts, paths, protocols, and environments.
• Exclude destructive URLs, account areas, checkout actions, and approved parameter traps.
• Record important page templates and conversion journeys.
• Choose crawl speed, render mode, authentication, and evidence-retention settings.
• Save the audit date, timezone, app version, and owner.

Transport and access checklist

• Record requested URL, final URL, status, MIME type, and redirect hops.
• Confirm important HTML pages return a successful response.
• Retry timeouts and uncertain HEAD failures with GET.
• Keep the exact source page for every broken link.
• Check robots.txt availability and rules.
• Confirm required scripts, styles, images, and API calls are accessible.

Indexing and canonical checklist

• Compare meta robots with X-Robots-Tag headers.
• Review self-referential and cross-page canonical targets.
• Find canonical chains, loops, failed targets, and non-indexable targets.
• Compare canonicals with redirects, sitemaps, internal links, and hreflang.
• Separate intentional exclusions from conflicting signals.
• Keep blocked, unavailable, indexed, and not-indexed states distinct.

Discovery and rendering checklist

• Parse XML sitemaps and retain their declared URLs and last-modified values.
• Build internal-link edges from confirmed source or rendered documents.
• Find important pages with no confirmed internal source.
• Compare mobile and desktop navigation when links differ.
• Keep source HTML and rendered DOM as separate layers.
• Record render readiness, important network failures, and evidence coverage.

Page meaning and quality checklist

Element	Check	Useful evidence
Title	Unique, descriptive, aligned with page purpose	Source and rendered value
Main heading	One clear page topic and a logical outline	Rendered H1–H6 tree
Main content	Available, specific, and useful for the intended task	Extracted text and template sample
Links	Crawlable, descriptive, and pointed at final approved URLs	Source, anchor, target, status
Images	Meaningful alternatives where the image carries information	Element, source, alt value
Structured data	Matches visible reviewed facts and supported types	Markup, validation, visible source

Performance checklist

For Core Web Vitals, preserve the data source, device, page group, percentile, and time period. Google’s good thresholds are LCP within 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. Connect a poor metric to the real element or interaction before assigning work.

Handoff and verification checklist

• Give every confirmed finding an owner and reviewer.
• Name the exact URL or template and current evidence.
• State the smallest safe change and rollback condition.
• Separate planned, implemented, reviewed, and verified states.
• Repeat the same check after release with comparable scope.
• Save the fresh outcome even when the condition did not improve.

How to use the checklist in a real review

Work from left to right, but stop when a required input is missing. If a page times out, retain the timeout and source-link evidence. Do not continue down the checklist and mark the title, H1, content, images, and schema as missing. Those checks require a successful HTML document.

Use template samples to keep the review manageable. For an online store, sample the home page, a category, a normal product, an unavailable product, a filtered category, a help article, and the checkout entry page. Add exceptions when the evidence varies. The sample helps you understand causes; the complete eligible set supplies the final count.

At signoff, read every high-priority task as if you were the developer receiving it. It should name the URL or template, current evidence, desired condition, owner, reviewer, release risk, and fresh check. If the instruction says only ‘fix canonical’ or ‘improve speed,’ the checklist has found an observation but has not finished the handoff.

A checklist also needs a stopping rule. Once every applicable check has evidence or an explicit unavailable state, the important findings have owners, and the verification plan is written, stop adding columns. More checks can create the appearance of depth while hiding the few decisions that matter.

Keep the checklist beside the evidence, not in a separate forgotten document. Link each completed item to the crawl view, export, screenshot, header capture, or manual note that supports it. When a check is intentionally skipped, name the reason and reviewer. This small discipline makes the audit easier to resume after an interruption and easier for a second person to challenge. It also exposes stale evidence: a saved result from before a migration, release, or template change should not silently stand in for the current site.

Sources and measurement notes

• Google Search Central: crawling and indexing overview
• Google Search Central: JavaScript SEO basics
• Google Search Central: Core Web Vitals
• Ubersuggest, India, English: “technical SEO audit” was checked on 28 September 2026. The broader seed showed about 320 monthly searches and difficulty 16/100. This is cluster context, not a traffic forecast for this URL.

Frequently asked questions

What belongs in a technical SEO audit checklist?

Include scope, transport, access, index controls, canonicals, discovery, rendering, page meaning, structured data, performance, prioritization, and verification.

Should I use the same checklist for every website?

Use the same evidence principles, but adapt the page types, rendering method, important journeys, markets, and risk thresholds to the site.

How many URLs should I sample manually?

There is no universal number. Include each important template, high-value pages, normal pages, and known exceptions. Increase the sample when results vary.

Does a sitemap replace an internal-link check?

No. A sitemap can suggest URLs for discovery. It does not prove that visitors or crawlers can reach a page through confirmed internal links.

Should Core Web Vitals be in the checklist?

Yes, when field or suitable lab evidence is available. Preserve device, page group, collection period, metric, measured element, and source.

When is the checklist complete?

It is complete when each applicable check has a result or an explicit unavailable state, important findings have owners, and every planned fix has a verification method.

Will completing the checklist guarantee rankings?

No. A checklist reduces missed technical evidence. It cannot guarantee crawling, indexing, rankings, traffic, or conversions.

Use the checklist with a live crawl

Read the complete audit method · Run your first LLMIC audit · Compare LLMIC plans