What evidence should an SEO audit report example contain?
An effective SEO audit report example should contain evidence for each finding, including the affected URLs, technical data, search performance signals, content analysis and clear comparisons where relevant. It should then connect that evidence to prioritised, actionable recommendations, explaining the likely impact and the work required to resolve each issue.
An effective SEO audit report example should provide verifiable evidence for every material finding. It should show what was reviewed, identify the affected URLs or page groups, explain the data behind each observation, and connect the evidence to a practical recommendation. A report that only lists issues without supporting examples, measurements or context is difficult to validate and unlikely to guide implementation effectively.
Start with the audit scope and method
The report should explain the scope of the review so the reader understands what the evidence represents. This should include the website properties reviewed, the relevant subdomains or directories, the crawl or data-collection date, and any limitations caused by blocked resources, restricted access or incomplete data.
It should also identify the main sources used, such as a website crawl, search performance data, analytics data, server logs, manual page reviews or backlink analysis. Different sources answer different questions. A crawl can identify broken links and indexability signals, while search performance data can show how pages appear in search results. Stating the method makes the findings reproducible and helps distinguish measured evidence from professional judgement.
Include affected URLs and representative examples
Each finding should identify the pages affected. Where an issue applies across a large group of pages, the report should explain the pattern and provide representative URLs rather than presenting an unqualified total. For example, a finding about missing title elements should show examples from the relevant template or directory and clarify whether the issue affects every page or only selected pages.
A useful evidence table commonly includes:
- the affected URL or URL pattern;
- the issue identified;
- the observed evidence;
- the likely SEO or user impact;
- the recommended action; and
- the team or role best placed to resolve it.
Examples should be specific enough for a developer, content specialist or SEO practitioner to locate the problem without repeating the entire investigation.
Show technical evidence, not just technical labels
Technical findings need evidence from the parts of the website that influence crawling, rendering and indexing. Depending on the audit scope, this may include:
- crawlable URLs and the response received when they are requested;
- indexability directives and canonical references;
- XML sitemap contents and whether listed URLs are suitable for indexing;
- robots directives and blocked resources;
- redirect chains, redirect loops and incorrectly redirected pages;
- broken internal links and links pointing to unsuitable destinations;
- duplicate or near-duplicate URL variants;
- pagination, faceted navigation and parameter handling;
- mobile rendering and content that is missing from smaller screens;
- structured data present on the page and any validation issues; and
- performance signals affecting the loading and usability of important templates.
The evidence should show the observed value or behaviour where practical. For example, rather than stating that canonicalisation is inconsistent, the report could show the page URL, its declared canonical URL and the alternative URL versions discovered during the crawl. This allows the recommendation to address the actual configuration rather than a general technical concern.
Performance findings should also identify the page template, device context and test conditions. Results can vary according to location, connection and page state, so the report should avoid presenting a single test as a permanent property of the whole website.
Use search and analytics data to establish significance
Technical evidence shows what is happening on the website, but search and analytics data can help establish which findings matter most. Where data is available, include relevant signals such as impressions, clicks, click-through rate, indexed page coverage, landing-page engagement and conversions. The report should state the period and property used, because the interpretation of a result depends on its date range and data source.
Search performance evidence might show that an important page receives impressions but few clicks, that a key service page is visible for less relevant queries, or that organic visits have declined after a site change. These observations should be connected to the page title, description, content alignment, technical accessibility or other relevant cause. Search data alone rarely proves why performance changed, so the report should separate the recorded signal from the proposed explanation.
Analytics evidence should be interpreted carefully. A low engagement signal may reflect page quality, user intent, tracking configuration or the type of visit being measured. Where the data cannot establish causation, use qualified language and recommend further validation.
Evidence content quality and search intent
A content finding should show more than a judgement that a page is too short, weak or outdated. It should explain the page’s purpose, the search intent it appears to target and the evidence that the current content does not meet that purpose.
Useful evidence can include:
- the primary topic and closely related subtopics covered;
- important information missing from the page;
- sections that are duplicated across several URLs;
- outdated claims, products, services or references;
- unclear headings or a structure that makes the answer difficult to find;
- weak alignment between the page title, visible content and target query;
- thin supporting information around important commercial pages; and
- competing pages on the same website that address the same intent.
When comparing a page with search results, the report should explain the basis of the comparison. It may assess the types of pages appearing, the topics addressed, the depth of explanation, the clarity of the answer or the level of commercial detail. It should not recommend copying another page. The purpose is to identify an information or usability gap that can be addressed with original, accurate content.
Document internal linking and site structure evidence
Internal linking findings should show how important pages are connected to the rest of the site. Evidence may include orphaned pages, pages receiving few internal links, links from irrelevant contexts, excessively deep navigation paths or anchor text that does not describe the destination.
A useful report can map the relationship between key landing pages, supporting content and conversion pages. It should explain whether the proposed change is intended to improve discovery, clarify topical relationships, distribute internal authority or help users move to the next relevant action. Recommendations should identify suitable source pages or content sections where this can be implemented.
Support backlink and external signal findings carefully
If external links or reputation signals form part of the audit, include the source and date of the data, the pages receiving links and any clear relevance or quality concerns. Avoid treating every unfamiliar or low-authority link as harmful. Evidence should distinguish between links that are simply unhelpful, links associated with obvious manipulation and links that may warrant closer review.
External evidence is often incomplete because different tools discover different links. The report should acknowledge that limitation and avoid making definitive claims that the available data cannot support.
Make recommendations traceable to the evidence
Every recommendation should be traceable to a documented finding. Explain what should change, why it matters, which pages or templates are involved, and how completion can be checked. For example, a recommendation to improve a page template should identify the template-level evidence, the affected page group and the validation steps required after deployment.
Recommendations are more useful when they state the expected outcome without guaranteeing a ranking result. Suitable outcomes might include improved crawl access, clearer page relevance, reduced duplication, better internal discovery or a more complete answer for the intended audience.
Include validation and limitations
The strongest SEO audit report examples describe how findings will be validated. This may involve a post-implementation crawl, inspection of updated templates, review of search data after an appropriate period, or manual checks of the affected URLs. Record any assumptions, excluded areas and unresolved data questions so future audits can distinguish new issues from known limitations.
In practice, the best evidence is specific, dated, reproducible and proportionate to the finding. It combines technical observations with search, content and business context, then gives the reader enough detail to decide what to do next and confirm whether the work has been completed successfully.

Evidence in an SEO audit report should make each finding verifiable by showing the affected page, the observed condition and the data source used. This allows the reader to distinguish a measured issue from an assumption and gives the implementation team enough information to investigate it without repeating the audit.
For each significant finding, include:
- the affected URL, template or URL pattern;
- the crawl date or reporting period;
- the relevant technical, search or analytics observation;
- the likely impact on crawling, visibility, usability or conversions; and
- the recommended action and method for checking completion.
For example, a canonicalisation finding is stronger when it shows the page URL, the canonical declared on that page and any alternative versions discovered. This is more useful than simply labelling the issue as “inconsistent canonicals”, because the developer can identify the configuration problem and the SEO team can confirm the correction after implementation.