Technical SEO Audit Checklist

Filed November 10, 2026
Crawling and indexing, guide 15 of 16

A technical SEO audit answers one question: can search engines discover, crawl, render and index the pages a site wants in search, and is anything technical holding those pages back? A checklist is only useful if every item says what evidence proves it, how severe a failure is, who owns the fix and how to verify it. This checklist is built that way. It is an audit procedure, not a substitute for the specialist guides on each topic; each section names what to check and where to look, and leaves deep diagnosis to the dedicated method.

How to use the checklist

Severity levels

Level	Meaning	Example
Critical	Blocks crawling or indexing of important pages, or exposes the site to a policy action	Site-wide <!–INLINECODE0–>; robots.txt <!–INLINECODE1–>; manual action
High	Degrades indexing or understanding of many important pages	Canonicals pointing to wrong pages on a template
Medium	Wastes crawling or weakens signals on a subset	Redirect chains in internal links
Low	Hygiene with limited effect	Inconsistent trailing slashes that already redirect

Fields for every finding

Item: what was checked.
Evidence: the report, export, command output or URL sample that shows the state.
Scope: number of URLs or templates affected, and how the number was obtained.
Severity: using the table above.
Owner: developer, content, SEO, hosting.
Fix: the specific change.
Verification: how to confirm the fix worked, and when.

An item without evidence is not a finding. “Site speed seems slow” is not a finding; “LCP at the 75th percentile is 4.1 seconds for the product template in the CrUX data for October” is.

Phase 1: inventory

[ ] Count indexable URLs the site intends to have (CMS export, XML sitemaps).
[ ] Count URLs Google reports as indexed and not indexed (Page indexing report).
[ ] Count URLs a crawl from the home page reaches.
[ ] Compare the three numbers. Large gaps define where the rest of the audit focuses.

Phase 2: crawl access

Check	Evidence	Severity if failing
robots.txt returns 200, parses, does not block important paths or rendering resources	robots.txt report in Search Console; fetch	Critical to Medium
Server returns 200 for important pages to Googlebot (no 5xx, 403, 429 to verified crawlers)	Crawl Stats host status and response codes; server logs	Critical to High
Redirects are single-hop and point to relevant destinations	Crawl export of redirect chains; <!–INLINECODE2–> samples	Medium
No redirect loops	Crawl export; Page indexing "Redirect error"	High
Internal links point to final URLs, not redirects or 404s	Crawl export of internal link targets by status	Medium
Faceted and parameter URLs are controlled	Crawl Stats sample URLs; logs	Medium to High on large sites

When a row fails, diagnose it with the dedicated guide: robots.txt rules and testing, 5xx and 429 responses, redirect chains and loops, 404s that matter and crawl budget on large sites.

Phase 3: indexation controls

Check	Evidence	Severity if failing
No unintended <!–INLINECODE3–> (meta or <!–INLINECODE4–>) on important templates	Crawl export of robots directives; Page indexing "URL marked 'noindex'"	Critical
Pages meant to be removed are crawlable and carry <!–INLINECODE5–> or return 404/410	URL Inspection samples	Medium
Canonicals are self-referencing on unique pages and point to the right URL on duplicates	Crawl export of canonicals; URL Inspection Google-selected canonical	High
Google-selected canonical matches the declared canonical for key pages	URL Inspection	High
Sitemaps list only canonical, indexable, 200-status URLs	Sitemap vs crawl comparison	Medium
Pagination uses unique URLs and self-canonicals	Template review	High on catalogs

The rules behind these rows are covered in the guides to noindex and X-Robots-Tag directives and to pagination and canonical tags.

Phase 4: site architecture

[ ] Important pages are reachable within a few clicks of the home page.
[ ] No orphan pages among those meant to rank (known URLs vs crawl comparison).
[ ] Navigation links are standard <a href> elements in rendered HTML.
[ ] URL structure is readable and consistent; Google’s URL structure guidelines recommend readable words over long ID numbers where possible and hyphens to separate words.
[ ] Internal links use descriptive anchor text.

Phase 5: rendering

[ ] Rendered HTML (URL Inspection, View crawled page) contains the main content, links and structured data.
[ ] Content does not depend on user interaction to load.
[ ] JavaScript and CSS required for rendering are not blocked by robots.txt.
[ ] Lazy-loaded content loads when it enters the viewport.
[ ] Single-page applications use real URLs (History API), not fragments, for distinct content.

Phase 6: mobile and page experience

[ ] Mobile and desktop versions have equivalent content, metadata, structured data and robots rules (critical on dynamic serving or separate mobile URLs).
[ ] Core Web Vitals in the Search Console report or CrUX: LCP, INP and CLS by template, read at the 75th percentile.
[ ] No intrusive interstitials covering main content on mobile.
[ ] HTTPS on all hostnames, no mixed content.

Phase 7: structured data and search features

[ ] Markup is valid (Schema Markup Validator; troubleshooting sequence).
[ ] Markup meets requirements for the Google features it targets (Rich Results Test) and those features still exist.
[ ] Marked-up content is visible on the page.
[ ] Rich result reports and the Unparsable structured data report in Search Console show no template-wide errors.

Phase 8: international (if applicable)

[ ] Hreflang sets are complete, reciprocal, self-referencing and use valid codes.
[ ] Each language version is its own canonical; where two regional versions in the same language are near-identical, Google’s multi-regional guidance recommends picking a preferred version with rel="canonical" and hreflang.
[ ] No automatic redirects based on language or IP.

Phase 9: security and policy

[ ] Manual Actions report: no actions.
[ ] Security Issues report: no issues.
[ ] No hacked content or injected links (spot checks, site: searches for spam terms, log anomalies).

Phase 10: measurement setup

[ ] Search Console properties verified for all relevant hosts; Domain property preferred where possible.
[ ] Analytics tracking present on all templates and not double-counting.
[ ] Baseline exported: indexed counts, top pages, top queries, Core Web Vitals by template, crawl stats.

Prioritization

Order the fix list by severity first, then by the number of important URLs affected, then by effort. A critical issue on one template that affects every product page outranks a medium issue across the blog. Group findings by owner so each team receives a coherent list.

Worked example of a finding record

Here is a hypothetical finding from an audit of an online store:

Item: canonical tags on paginated category pages.
Evidence: crawl export shows 3,214 URLs with ?page= canonicalized to page 1; URL Inspection on 10 samples shows Google selected page 1 as canonical.
Scope: all paginated category pages (3,214 URLs on 410 categories).
Severity: High. Products listed only on deeper pages lose a discovery path.
Owner: developer (category template).
Fix: self-referencing canonical on each paginated URL; keep <a href> next and previous links.
Verification: a new crawl export should show 0 paginated URLs canonicalized to page 1; recheck URL Inspection on the same 10 samples after recrawl.

Reporting the audit

Lead with the critical and high findings and their scope. Separate what was measured from what was inferred. List what was not checked (for example, log files not provided) as limits of the audit, not as clean results. An audit that says “no issues found” must say what was examined and with which data.