SEO Audit Report: What Goes In It, and the Template We Use

An SEO audit report is the document you hand to someone who did not run the audit. That is the whole constraint, and it is why a findings export is not a report: the export tells the reader what a tool noticed, and the report has to tell them what to do on Monday.

Our step-by-step guide to performing the audit covers the investigation. This page is only about the document that comes out of it: the structure, how to group findings, how to verify one before it reaches the page, and what to leave out.

What is an SEO audit report, and how is it different from the audit?

The audit is the investigation. The report is the argument you build from it. They are produced by different skills and judged by different standards, which is why good auditors routinely write bad reports.

Those two things come apart constantly. A long crawl export can be a complete audit and a failed report at the same time, because the reader cannot tell which three findings matter and so nothing happens.

The practical test: hand the document to someone who was not involved and watch what they do. If they ask "so what should we fix first", the report has not done its job, however accurate the findings are.

What is the structure of an SEO audit report?

Six sections, in this order. The order is the template, because it puts the decision before the evidence rather than after it.

#	Section	What goes in it	Length
1	Scope and date	What you checked, what you did not, how many pages, which tools, the date of the crawl	Half a page
2	The three things to fix first	Three items, each with the reason it is in this list and not the next one	Half a page
3	Findings grouped by cause	Grouped by the thing producing them, not by the tool or the check that found them	The bulk
4	Effort and owner	A named owner and a rough size for each group. Engineering, content or either	One table
5	What you expect each fix to change	The metric, the direction, and when you will look	One table
6	Limits	What the audit could not see, and what that means for confidence	Half a page

Section 2 is the report. Everything else is supporting material. If a reader only gets through the first page, they should still know what to do, and that is a deliberate design choice rather than an executive-summary convention.

Should findings be ordered by severity or by cause?

Both, doing different jobs. Severity decides what is urgent. Cause decides how the report is structured, and confusing the two produces a report that is accurate and unusable.

Severity tiers belong in the prioritisation step, where you work out that an indexing failure outranks a missing meta description. They also belong as a column in the findings table, restated rather than assumed, so the reader shares your scale. Our guide to performing the audit sets out the tiers we use.

What severity should not do is set the running order of section 3, because a severity-sorted list scatters one underlying problem across the whole document. Forty pages missing a meta description is not forty findings. It is one template that does not output a meta description, and writing it as forty lines turns a thirty-minute fix into a quarter of work nobody schedules.

Grouping by cause collapses the count to something a human can hold, attaches each group to the one change that resolves it, and exposes the cases where a hundred findings share a single root. That last one is the most valuable thing an audit can tell you, and a severity sort hides it.

How do you verify a finding before it reaches the report?

Open it. Every finding should be checked by hand at least once at the group level, because the label a tool puts on a finding is often wrong even when the tool has spotted something real.

We have a worked example from our own site. A content audit of this blog flagged 123 posts for broken internal links. Checking the targets found zero broken links: no 404s anywhere. But the audit had not found nothing. Of 171 flagged instances, 139 pointed at URLs that 308-redirect rather than resolving directly, and 33 were written as absolute URLs where the house style is root-relative. Both are worth fixing and neither is what the report said. The label was wrong, the signal was not. The full account is in our write-up of that audit.

That is the failure mode to design against: a report that names the wrong problem sends somebody to fix something that is not broken while the real issue stays open. The rule that follows is cheap. For each cause group, open two affected URLs, confirm what is actually happening, and write the report against that rather than against the tool's label.

What should you leave out of the report?

Three things, and leaving them out is what makes the rest credible.

• Findings you would not act on. If a check failed and the correct response is to do nothing, either explain why or cut it. A report padded with non-actionable fails trains the reader to skim.
• Raw tool exports pasted in as appendices. Link to them. Four hundred rows in the document signals volume, not rigour.
• Recommendations you have not checked against this site. Generic advice lifted from a checklist is the tell that nobody opened the actual pages.

A single overall score is the fourth candidate and a closer call. It travels well with executives and it compresses away the thing the reader needs, so if you include one, be ready for "out of what". The rule we hold ourselves to is narrower than leaving it out: a score must never report an absence as a failure. The audit behind our own product states it plainly, that it will not score a dimension it could not measure and that unmeasured is reported as unmeasured, never as zero. Our piece on SEO scores works through why that distinction decides whether a score is worth anything.

What should the report say about things you could not check?

Say them plainly, in their own section, with the consequence. An audit always has gaps: pages behind a login, a staging environment you were not given, a crawl that sampled rather than covered, a JavaScript framework the crawler rendered inconsistently.

Readers do not punish stated limits. They punish discovering an unstated one later. A report that says "we sampled 500 of 12,000 pages, so template-level problems are reliable and page-level ones are not" is more useful and more trusted than one that silently implies full coverage.

How long should an SEO audit report be?

As long as the findings require, and the useful constraint is the first page rather than the page count. A report with three clear priorities on page one can run long without anyone minding, because the length is optional reading.

What goes wrong is the inverse: a short report that opens with methodology, or a long one that never nominates a priority. In both cases the reader has to do the auditor's job, and in both cases the length was not the problem.

What happens to the report after you send it?

Section 5 gets checked, on the date it names. This is the part almost everyone skips, and it is the only way anyone finds out whether the audit was any good.

Write the expected change before the work starts. Then on that date, look. Some fixes will have done nothing, and knowing which is worth more than the fix itself, because it tells you where your model of the site is wrong. An audit nobody measures afterwards produces the same report again next year.

The sequencing decision, which of the grouped findings to take first, has its own logic and is covered in prioritising fixes after an audit.