SEO Audit Example: The Report Template and Its Prioritization Table

You know what an SEO audit covers, and the most concrete question remains: what the document looks like once it is written. Which chapters, in what order, so that it reads for a management team as well as for a developer? Which columns make a recommendation executable? And what do you show to prove that a fix produced an effect? This SEO audit example gives the shape of the deliverable, with a recommendation table template and a review grid to copy.

What an audit example has to make visible

A useful example does not consist in stacking up metrics: it has to explain what is wrong, why it matters and how to fix it, then turn all of it into a roadmap. The findings themselves change from one site to the next and are never copied over; what is copied is the way the document presents them, proves them and orders them. If the question is still what an SEO audit covers and when to trigger it, that framing is what to read first: what follows is about the document delivered, not about the decision to launch it.

The four judgement calls an example makes visible

A method describes what to look at; an example shows what has been settled. That is the difference with a guide explaining how to perform an SEO audit from framing to delivery: the latter says in what order to work, this one says what goes into the document and in what form. Four judgement calls become readable in it:

• The level of proof expected: Search Console screenshots, Analytics exports, HTML extracts, lists of affected URLs, before/after.
• Granularity: anomalies grouped by template rather than page by page, except for business pages, which are handled by name because a single one of them weighs more than a batch of secondary pages.
• Prioritization: separating errors, warnings and remarks so as to concentrate the effort on what really weighs on performance.
• Translation into decisions: who does what (SEO, content, dev), when, with which acceptance criteria.

The four components of a deliverable

The value of a report does not come from its volume: it comes from its structure and its proof. A deliverable rests on four components, and each one has to be visible at a glance:

• Findings: worded in plain language (“discovered URLs are not indexable”, “strategic pages are too deep”, “several pages are competing for the same intent”).
• Proof: Search Console (coverage, URL inspection, performance), Analytics (engagement, conversions), and observable elements (HTTP status, tags, rendering).
• Priorities: a classification and a scoring, for example the ICE framework — Impact, Confidence, Ease — whose role is to make the order arguable, not to produce a mark.
• Action plan: tasks, owners, dependencies, validation criteria, measurement window.

The four hold together: a finding without proof gets contested, proof without a priority piles up, a priority without an owner never leaves the document.

The structure of the report: chapters and reading order

For an audit to be genuinely useful, the report has to be “readable” by several audiences: management (impact and risks), marketing (editorial priorities), the product/tech team (precise tickets). It is this constraint, and this one alone, that justifies the order of the chapters: the document starts with what interests the person deciding, then works down to what the person executing needs. A report that opens on the methodology forces management to look for its answer on page 12, and it will not look.

The executive summary and its four questions

The executive summary runs to one or two pages and answers four questions, in this order:

• What is blocking growth? (e.g. incomplete indexing, duplication, slowness on high-intent pages).
• What can produce a measurable gain quickly? (e.g. snippet optimization to gain CTR, consolidating cannibalizing pages).
• What are the risks of not fixing it? (e.g. loss of crawl, deindexing, dilution of relevance).
• What is the 30/60/90-day roadmap? (an execution-driven breakdown).

Each answer is quantified on the scope audited, never in the abstract: it is your pages, your queries and your volumes that give the order of magnitude. A market benchmark serves to situate the stake, not to replace it: the click-through rate on the first organic position (desktop) is 34% (SEO.com, 2026), while the click-through rate on page 2 of the SERPs is 0.78% (Ahrefs, 2025). The SEO statistics, with their source and their year are cited in this chapter, and nowhere else in the report.

The seven sections, and the level of detail by audience

The body of the report breaks down into seven sections, and this order is the reading order, not the working order:

• 1. Executive summary (expected gains, risks, five priorities).
• 2. Methodology and scope (data sources, samples, limits).
• 3. Technical audit (crawling, indexing, performance, structure).
• 4. Semantic audit (mapping, intent, cannibalization, content).
• 5. Popularity and link building (link profile, quality, risks) — to be calibrated to your sector.
• 6. Prioritization table (30/60/90-day roadmap).
• 7. Measurement plan (KPIs, baseline, schedule).

The caveat on the fifth section is part of the template: in a sector where external authority does not separate the competitors, a detailed link analysis takes up thirty pages for no decision at all. The level of detail is adjusted by audience without duplicating content: sections 1 and 6 read on their own for management, sections 3 and 4 carry the detail down to URL level for those who will execute, and section 7 is the only one both will read together.

The methodology section: declared scope, sample, limits

This is the chapter most often rushed, and the one that separates an honest report from a report claiming to cover everything. It does not choose the scope — that decision was taken earlier — it declares it, along with what was excluded from it and why. Three elements appear in it.

First, the segments retained: business pages (categories, products, service pages), blog, support pages, local pages. Then, the templates: grouping by template — listing, product page, article, brand page — is the report's unit of writing, because that is where the root causes sit. An exemplary technical audit does not list 300 pages with the same anomaly: it groups by template and quantifies the scale. The formula to remember comes down to one line: one template diagnosis = one fix that improves dozens or hundreds of URLs. Finally, the sample: on a large site, an audit by template paired with a representative sample per segment is worth more than a superficial exhaustive sweep; on a small site, completeness is often reachable and is declared as such.

That leaves the point almost no report writes down: what was not looked at. An inaccessible staging environment, a section being rebuilt, partial Analytics access: each of these limits changes the reach of a conclusion, and keeping quiet about them amounts to letting people believe that the report's silence means the absence of a problem. The objectives are declared in the same place: specific and measurable, suited to your context, and presented as hypotheses to be verified, never as a promised result.

The prioritization table: columns, scoring, arbitration

This is the most reusable part of the document, and the one that decides whether the report will produce tickets or stay a PDF. A recommendation table is not a sorted list of anomalies: it is the point where each finding becomes a line of action, with its proof, its owner and its closing condition. The columns are copied from one audit to the next; what changes is the discipline with which they are filled in.

What each column has to carry to be verifiable

Nine columns are enough, and none of them is decorative:

• Finding.
• Type (technical, semantic, UX, popularity).
• Proof (GSC/GA4 link, export, screenshot).
• Estimated impact (crawl/indexing, CTR, conversion).
• Effort (low/medium/high, plus the dependencies).
• Risk (regression, deployment, side effects).
• Recommendation.
• Owner.
• Validation (how to check that it is fixed).

The last one is what makes the table executable: without it, nobody will be able to say whether the line is closed. A badly filled column does not produce vagueness, it produces a precise blockage, and it is always the same ones that empty out when the document is written in a hurry. The table below takes the six columns where this plays out.

The rule that decides between two lines

Once the lines are written, they have to be ordered, and that is where scoring shows its limit. Two lines can get the same mark for opposite reasons: one because it affects few pages but the right ones, the other because it affects many with no consequence. Classification into Errors / Warnings / Remarks therefore comes before the score: it separates what stops the site from existing in the index from what improves it at the margin, and the score only comes into play inside each category.

The arbitration rule is then written in one sentence, and it is documented in the template so that the question is not replayed at every audit. The objective is not to “push the score up”, but to prevent a critical error from being neutralized by marginal optimizations. In practical terms: a critical error — a 404 on a high-conversion page, for instance — comes before a minor optimization, such as a missing alt attribute on old content. Written into the table, it makes the ranking defensible in a meeting, which a score alone has never allowed.

A finding documented end to end

A table row points to a written finding, and it is that template which structures all the rest of the report. It is short, repeatable, and applies just as well to an indexing anomaly as to a content problem:

• Problem: “X is preventing Y pages from being indexed”.
• Proof: GSC export + 3 example URLs + an extract of the code/rendering.
• Root cause: template, redirect rule, noindex tag, inconsistent canonical…
• Fix: technical action + owner + deadline.
• Validation: how to confirm it in Search Console.

Two findings are enough to show how it is filled in. What matters is not the anomaly chosen, it is that none of the five lines stays empty.

A technical finding, written through to its validation

Take the gap between submitted pages and indexed pages on a listing template. Problem: a batch of URLs appears in the sitemap but does not enter the index. Proof: the export of the indexing report on a given date, three URLs from the batch inspected one by one, and the code extract showing the directive at fault. Root cause: a canonical in the template points to the parent page instead of the page itself — a single place to fix, for the whole batch. Fix: change the rule in the template, with an owner on the development side and a release date. Validation: after deployment, re-inspect the three control URLs, then check that the gap between submitted pages and indexed pages closes across the full batch.

An example stops there: what is reproduced is not the check, it is the way of writing it. The list of points to check — crawl directives, statuses, redirects, canonicals, rendering, orphan pages — belongs to the detail of a site's technical SEO audit checks and the order to run them in.

A semantic finding, written in the same template

The same format holds for a content problem. Problem: several pages stay at the status “Discovered – currently not indexed”, a frequent state when the content is judged too thin against what the query expects. Proof: the status recorded in URL inspection, the zero impression volume on those pages, and the actual content of three of them. Root cause: a page published without the sections that the competing results all cover. Fix: add the useful sections — including a FAQ where the questions genuinely exist — then request reindexing, with an owner on the editorial side. Validation: the move of the status to “indexed”, then the appearance of impressions on the target queries.

The value of the finding is methodological: it connects useful content, indexing and performance in a single verifiable line. Deciding whether to create a page, enrich one or merge several, on the other hand, is a judgement call in its own right, dealt with by the semantic audit's matching of page to query, cannibalization included. The report carries its conclusion, not its demonstration.

Before / after: what the report shows to prove the effect

An audit that shows no before/after stays a photograph, and its reader will have to take it on trust that the fixes were good for something. The report obviously cannot contain the “after” on the day it is delivered: what it has to contain is the reading that makes the after readable, and the commitment to replay it identically. That is the role of the measurement plan, the last section of the template.

The baseline: what you record before fixing

The discipline comes down to one sentence: establish a baseline before the fix and measure the after, rather than concluding from an impression. In practical terms, the report attaches three items, put together while the site is still in its initial state:

• The Search Console before/after exports: pages, queries, errors, indexing, over an explicitly stated reference period.
• The list of URLs changed, and the mapping of 301 redirects if addresses change.
• The sample of key URLs inspected: indexing, canonical chosen, rendering — the same ones that will be re-inspected afterwards.

On the Analytics side, the initial reading covers engagement and conversion, segmented by organic landing page. These items cannot be reconstituted after the fact: once the fix is deployed, the previous state has disappeared from the interfaces, and any variation observed becomes an impression again.

The measurement window and what you replay

The measurement plan announces three things: what the reading is replayed on, on what deadline, and what will count as confirmation. You replay exactly the same reading, on the same basket of URLs and queries — changing the scope between the before and the after is the most common way of concluding wrongly. The deadline is stated with its condition: the disappearance of the finding is checked from the re-crawl onwards, a technical and binary fact, whereas the effect on visibility is read over several weeks, the time it takes for indexing to settle on the template concerned.

Take the most common fix in this area, reworking the title and meta description tags of a template: the initial finding records missing tags, duplicates and lengths unsuited to the usual benchmarks — in the order of 60 characters for the title, 160 for the meta description. The indicator to replay is CTR at comparable position, not raw traffic: the impact of an optimized meta description on CTR is +43% (MyLittleBigWeb, 2026), but a position gain occurring in the same week would make attribution impossible. Hence the closing instruction: annotate the deployment dates.

The reusable template and its review grid

What remains is to turn the report into a template you take out as it is. Two items are enough: a checklist guaranteeing that no family of checks has been forgotten, and a review grid to run over the document before sending. Neither is a work programme: they are safety nets, to be run once the document is already written.

The six families of checks

The template's checklist falls into six families, and each becomes a sub-part of the report when it carries findings:

• Crawling: what the crawlers reach, and what stops them.
• Indexing: what enters the index, what is kept out of it and on what grounds.
• Technical quality: consistency of the signals, statuses, page structure.
• Content: intent covered, completeness, uniqueness of the reference page.
• Measurement: data sources, baseline, validation indicators.
• Citability (GEO): what makes a page usable as a source by generative engines.

The prioritization table carries these families over into its “Type” column, which allows the report to be read both ways: by family to check the coverage, by priority to decide. The sixth is named in the template even when it has not been investigated: a family declared out of scope is a piece of information, a family absent from the contents page reads as an oversight.

Precision, traceability, non-redundancy, measurability

The review grid is run over the finished document, and four criteria are enough to head off most of the reproaches a report gets:

• Precision: name URLs, templates, sections, not generalities.
• Traceability: every recommendation has to point to a piece of proof.
• Non-redundancy: group the findings by root cause, avoid repeating the same problem across twenty pages.
• Measurability: define a validation criterion.

Reviewed this way, a report often loses a third of its volume and gains its ability to produce tickets. The cost of that discipline lies elsewhere: gathering the findings, their proof and their priority into a single exportable record, instead of copying them by hand from an export into a spreadsheet, is precisely the task covered by the audit and mapping module.

FAQ on SEO audit examples and templates

How do you present audit results in a clear and actionable way?

Present a decision-driven executive summary, then a prioritized list in Errors / Warnings / Remarks, then the proof (Search Console, Analytics, example URLs), and finally a dated roadmap with owners and validation criteria. Clarity and prioritization count for more than stacking up data: a report that does not sort passes the sorting on to its reader.

Is there a reusable template across types of site?

Yes, provided it stays adaptable. The structure “executive summary → methodology → technical → semantic → prioritization → measurement” works for most sites. What changes from one context to the next is the level of detail, the sampling according to volume, and the weight of the popularity section, which is calibrated to the sector.

What does a complete audit look like (format, chapters, deliverables)?

A document structured in seven chapters, including a prioritization table and a measurement plan. The deliverables expected are a diagnosis with example URLs, a roadmap connected to the objectives, and the validation criteria for each recommendation. The value does not come from the report's volume: it comes from its structure and its proof.

What is the difference between a technical analysis and a semantic analysis?

Technical analysis checks the engines' ability to crawl, render and index correctly: structure, HTTP statuses, directives. Semantic analysis checks that each page targets a clear intent, with content that is relevant and differentiating enough. In the report, both are written in the same finding template, which allows them to be prioritized on the same scale.

How many pages should you audit to get a reliable sample?

It all depends on the size of the site. For a large site, favour an audit by template and a representative sample per segment — business pages, blog, support pages. For a smaller site, an exhaustive audit is often possible. The important thing is to spell out the scope and the limits in the report's methodology.

How do you turn a list of findings into a prioritization?

First classify into Errors / Warnings / Remarks, then apply a scoring inside each category. Prioritize what unblocks crawling and indexing, then what affects high-value pages. The rule to document: a critical error comes before a minor optimization, whatever mark the latter obtains.

Which KPIs should you track after the audit to validate the gains?

In Search Console: indexing, errors, impressions, clicks, CTR and positions, by page and by query. In Analytics: engagement and conversions from organic traffic. Work with a baseline recorded before the fix and replay exactly the same reading after deployment, annotating the dates to make attribution possible.

Continue reading

• You have the shape of the report but nothing to produce the proof it calls for: the choice and assembly of SEO audit tools, what each one produces and what it does not settle.
• The report is delivered to you by a third party and you have to accept it before paying: what to require on an agency SEO audit, deliverables and acceptance included.
• The fixes are delivered and the before/after is no longer enough: SEO tracking puts KPIs, annotations and the monitoring of gains in place over time.
• You have to declare a scope and do not yet know what your site is made of: the website analysis maps the templates, the page roles and the traffic segments.