SEO Audit Report: Evidence, Findings and Action Plan

An SEO audit report turns crawl, Search Console and page review evidence into decisions. Start with the SEO audit hub, then download the blank audit report template and the implementation tracker.

This page defines a reusable reporting method. It is distinct from the completed owned-site report example, which records AuditWeb findings with dated evidence. Do not copy its site-specific observations into a client report.

What is an SEO audit report?

An SEO audit report is a dated record of what was checked, what the evidence shows, what remains uncertain and what an owner should do next.

Define the audit property, URL scope, search types, crawl date, Search Console date range, tools and access level. State exclusions such as log files, analytics or backlink data that were unavailable. A report can then be reproduced without implying that an unavailable source was checked.

Who is the report for and what is in scope?

The report serves decision-makers who need risk and priority, and implementers who need exact URLs, evidence and acceptance checks. State both audiences and the boundary before listing findings.

Audience: name the business owner, marketing lead, developer, content team or agency reviewer who will act on the report.
Scope: record domains, subdomains, templates, markets, devices and search types included.
Evidence window: record crawl timestamps and completed Search Console periods. Label current observations separately from historical comparisons.
Access limits: mark data as available, partial, estimated or unavailable. Never turn a missing export into a zero.

How should the executive summary work?

An executive summary should answer what changed, how much is affected, what is known, what is uncertain and which three actions deserve attention first.

Use a short structure: scope and date; observed state; three to five findings; business relevance; and next decisions. Describe impact as observed clicks, impressions, affected URL counts or implementation risk. If traffic or revenue impact is modelled, show the inputs and label it as an estimate.

Write “clicks fell in the comparison period and the loss is concentrated in the /guides/ template” when that is what the evidence shows. Keep the cause open until tested.

What should technical findings include?

Technical findings should state the observed access, crawl, indexability, status, canonical, redirect, structured-data or performance condition and its scope.

Every finding needs a claim, source, scope, severity, confidence, recommendation and verification condition. This lets another person reproduce the observation and challenge the interpretation.

Field	Record	Why it matters
Observation	Exact metric, rule or page state	Separates the evidence from the interpretation.
Scope	Affected URLs, template, query group or count	Prevents one URL from representing the whole site.
Source and date	Crawl export, Search Console view or manual check	Shows when the evidence was true and where it came from.
Severity and confidence	Consequence plus known, likely or uncertain	Stops speculation being presented as a confirmed defect.
Fix and retest	Owner action, acceptance check and review date	Turns a report row into a measurable task.

On small screens, swipe or use arrow keys inside the table region to inspect every column.

What should on-page findings include?

On-page findings should identify the current title, description, heading, internal-link or content evidence and the page's search data where available.

Record the page intent, affected URL or template, search queries and comparison dates. Recommend a specific edit and a check that can confirm the change without claiming a guaranteed ranking result.

How should content and search data be read?

Read content findings alongside page and query performance. A word count, average position or crawler warning is a prompt for review, not a standalone quality verdict.

In Search Console compare the same completed periods and segment by page, query, device, country and search type. Keep clicks, impressions, CTR and average position separate. The Performance report documentation says anonymised queries are omitted and table data can be truncated; filters can therefore change totals. It also commonly credits performance to the selected canonical URL. State these limits beside any chart or table.

For content review record intent, factual currency, first-hand evidence, authorship, citations, internal links and competing page types. Mark “known” when a source directly supports it, “likely” when several observations point in the same direction, and “uncertain” when a test is still needed.

How should links and performance be recorded?

Link and performance sections should report dated observations and source limits. Avoid third-party labels that imply Google has classified a link or page.

For links record referring URL, target URL, first or last observed date, anchor context and whether the link was requested or unsolicited. Investigate disavow only when the Google manual-action context supports it; ordinary unsolicited links do not generally require a disavow file. For performance record field versus lab data, device, sample window and the page or template represented.

How should Core Web Vitals be reported?

Core Web Vitals should be reported as user-experience evidence with source, device, sample window and affected templates.

Field and lab measurements answer different questions. A regression does not by itself explain every ranking change. Pair it with affected templates, search data and deployment history.

How do you benchmark competitors?

Benchmark competitors by the queries and page types that matter to the audited site. Record what is visible and comparable rather than inventing authority or traffic values.

Capture the query set, date, result type, competing URL, intent and difference being tested. A competitor's title or link profile is a lead rather than proof of causation.

How do you prioritise implementation?

Prioritise by severity, affected scope, confidence, business importance and effort. Use a small consistent scale and explain the decision in each row.

Critical: a security, manual-action or indexability blocker with evidence and a clear owner.
High: a broad or commercially important issue where the evidence supports a near-term fix.
Medium: a meaningful improvement with bounded scope or moderate confidence.
Low: a polish or monitoring item that should not displace proven blockers.

Do not attach guaranteed rankings, traffic percentages or fixed recovery dates. If modelling upside, state the baseline, assumptions, range and reason the estimate may be wrong.

How do owners retest findings?

An action is ready for retest when its owner, status, implementation date and acceptance evidence are recorded. The tracker should preserve the original observation so a later result can be compared.

Use statuses such as open, in progress, ready for retest, verified and blocked. Add a concrete acceptance check. URL Inspection compares indexed and live views for one URL, but a live test does not check every indexing condition or guarantee inclusion.

Remeasure the same scope after the change. Report improved, unchanged or inconclusive with dates and evidence. Do not call a recommendation verified because a deployment occurred.

How should findings be shared?

Share the executive summary with decisions and risks, then give each implementation team the evidence rows and tracker tasks needed to act.

Keep raw exports, query strings, client URLs and access details in the agreed private workspace. In a public or portfolio version use redacted URLs, grouped metrics and clearly labelled illustrative examples. The report example is the place to see presentation style; this page is the evidence and workflow reference.

What questions come up in an SEO audit report?

What should an SEO audit report include?

It should state scope and dates, summarise evidence-led findings, list affected URLs or groups, separate known facts from hypotheses, and assign prioritised actions with owners and retest conditions.

How should SEO recommendations be prioritised?

Use severity, affected scope, business importance, confidence and implementation effort. Assign an owner, status and retest condition instead of promising a ranking or traffic outcome.

Where can I start a report?

Use the blank audit report template for evidence and the implementation tracker for ownership and status. Use the separate completed report example to see an owned-site deliverable format.