Technical SEO audit template for an evidence-led review
A reusable audit report structure that connects each technical observation to affected URLs, interpretation, priority and verification.
Set scope, evidence date and representative samples
Folio detail
Begin with the business question, hostnames, environments, date of collection and any areas deliberately excluded. Record whether evidence comes from a public crawl, Search Console, server logs, release records or manual inspection. Large sites need stated sampling rules for templates and directories; a few convenient URLs cannot represent everything. Note access limitations instead of filling gaps with assumptions. The scope page should also identify migrations or releases that may affect interpretation. This makes the audit repeatable and prevents a later reader from mistaking a time-bound observation for a permanent property of the site.
Record findings as evidence, interpretation and action
Folio detail
Every finding should list affected URLs or a reproducible selection rule, observed evidence, likely consequence, confidence and a bounded recommendation. Separate a confirmed directive from an inference about impact. Screenshots can illustrate a problem, but preserve text exports, response headers or crawl fields where possible. Avoid severity based only on a third-party score. Priority should reflect dependency, scope and business relevance: a noindex on an important service template differs from one on an intentionally excluded utility page. Name evidence that would change the conclusion when uncertainty remains.
Inspect templates, rendered content and structured data
Folio detail
For representative page types, compare titles, descriptions, headings, meaningful rendered text, crawlable links and mobile behaviour. Check whether templates create empty, duplicated or misleading elements at scale. Validate structured data against the visible page and applicable search documentation; passing a syntax test does not make unsupported claims acceptable or guarantee a rich result. Include performance evidence only with collection context, device and URL sample. Accessibility and usability observations can be important to visitors, but label them accurately rather than claiming every presentation issue is a direct ranking factor.
Cover discovery, response and canonicalisation systematically
Folio detail
Review crawlable links, XML sitemaps, robots controls, status codes, redirects, duplicate URL variants and canonical declarations. Compare declared signals rather than checking each in isolation. A URL in a sitemap that redirects or names another canonical creates avoidable ambiguity. Inspect parameter handling and faceted routes only where they exist; do not pad the report with irrelevant checklist rows. For redirects, capture source, each hop and final destination. For errors, distinguish intentional removal from broken internal references. The objective is a coherent URL system, not a report in which every possible technical term appears.
Finish with implementation and verification records
Folio detail
Group actions by dependency and responsible discipline, such as platform, development, content or analytics. Each ticket needs exact scope, desired behaviour, test method and rollback consideration. Retest the live deployment rather than closing an item because code was merged. Keep unresolved unknowns in a visible register and identify the evidence owner. A concise executive summary should explain the few issues that materially affect the stated question, sound foundations to preserve, and work that can wait. The audit supports decisions; it cannot promise crawling, indexing, traffic or rankings after implementation.
Practical report-template
Technical audit finding record
Duplicate this record for each distinct issue; do not combine unrelated symptoms into one recommendation.
Audit scopeHosts, directories, templates, exclusions, collection date and business question.