Site Audits · Lesson 04 · Interpretation

Findings

How to interpret crawl data, connect related issues to a root cause, and write findings with evidence, clear recommendations, and testable acceptance criteria.

04 Site Audits10 min Read timeIntermediate Level

04 / Interpretation

A finding is an issue that has been verified, explained, and connected to a fix. Where a crawl export says "312 URLs with duplicate titles", a finding explains the root cause, shows evidence, describes the impact, and states exactly what needs to change and how to confirm it worked.

This lesson covers how to interpret crawl data, write findings that developers and stakeholders can act on, include evidence and acceptance criteria, and validate fixes with a recrawl.

1. Issue versus finding

Issue	Finding
Produced by the crawler	Written by the auditor
States a condition	Explains cause, impact, and fix
Lists affected URLs	Groups URLs by pattern with examples
May be a false positive	Has been verified
Ends at detection	Ends with acceptance criteria and validation

Interpretation is the audit

A crawler can detect a canonical pointing elsewhere. Only an auditor can decide whether that canonical is a deliberate consolidation or a template bug sending authority to the wrong page.

2. Interpreting crawl data

Look for patterns before reading individual URLs. Useful questions include:

Do affected URLs share a folder, template, or parameter?
Did the issue appear after a specific release or date?
Does the issue affect indexable pages or only noindexed ones?
Does Search Console confirm the same pattern?
Are several issues symptoms of one cause?

Connecting related issues

Separate flagsDuplicate titles: 480
Duplicate content: 480
Canonical missing: 480Three issues, same 480 URLs.

One findingFilter parameters create indexable duplicatesAdd canonicals to the clean URL and limit parameter crawling.

Three reported issues become one root cause and one fix.

3. The structure of a strong finding

Section	Contents
Title	A short, specific statement, for example: Product filter URLs are indexable duplicates
Summary	One or two sentences on what is wrong and why it matters
Evidence	Affected URL count, sample URLs, screenshots, source code, Search Console data
Root cause	The template, setting, or process that creates the issue
Impact	Effect on crawling, indexing, rankings, AI visibility, or users
Recommendation	The exact change, with code or configuration examples
Acceptance criteria	Conditions that must be true when the fix is complete
Priority and owner	Priority tier, effort, and who is responsible

4. Evidence that convinces

Evidence turns an opinion into a finding. Include three to five sample URLs rather than a spreadsheet of thousands, and show the exact problem in the source:

URL: /shoes/?color=red&sort=price
Status: 200
Canonical: missing
Title: Running Shoes | Store
Same title on: /shoes/, /shoes/?color=blue

Add supporting data where available: the Search Console page indexing report, log file hits from Googlebot on parameter URLs, or the date the issue first appeared in scheduled crawls.

5. Writing clear recommendations

Weak	Strong
Fix duplicate titles	Update the category template so the title uses the category name followed by the brand, for example: Running Shoes for Women \| Store
Improve redirects	Change the 14 redirects in the attached list to point directly to the final URL, removing the intermediate hop
Check canonicals	Add a self-referencing canonical to all product templates and point parameter URLs to the clean URL

A good recommendation names the template or setting, gives an example, and avoids SEO jargon where a developer may not know it.

6. Acceptance criteria and validation

Acceptance criteria define "done". They should be testable by anyone, including the developer who ships the fix.

Acceptance criteria
1. All /shoes/?* URLs return a canonical to the clean category URL.
2. Filter links include rel="nofollow" or are excluded from the sitemap.
3. A recrawl shows zero duplicate titles in /shoes/.

Test on stagingConfirm the change before release when possible.
Recrawl with the same settingsUse the baseline configuration so results are comparable.
Compare crawlsConfirm the issue count dropped and no new issues appeared.
Request indexing where usefulUse Search Console for key URLs after major fixes.
Monitor over weeksIndexing and ranking changes take time to show.

The SiteAuditLint compare view shows fixed, new, and remaining issues between two crawls.

Match the format to the audience. Developers need tickets with evidence and acceptance criteria. Content teams need URL lists and writing guidance. Leadership needs a short summary of risks, progress, and expected outcomes.

SiteAuditLint can produce HTML reports and exports, send issues to Slack, and create Linear tickets. Reporting in depth is covered in the SEO Reporting course.

8. Common mistakes with findings

Reporting raw counts

Large numbers without context cause alarm but not action.

No root cause

Fixing symptoms page by page while the template keeps creating new ones.

Unverified flags

Reporting intentional noindex pages as errors damages credibility.

Vague fixes

Recommendations that a developer cannot implement without more questions.

No validation

Closing tickets without confirming the fix in a recrawl.

9. Practical exercise: Write one finding

Choose the highest priority issue from your last crawl and write a complete finding using the structure above.

Key takeaways

A finding is a verified issue with cause, impact, fix, and validation.
Look for patterns and shared root causes before reading individual URLs.
A few clear sample URLs are more persuasive than a full export.
Recommendations should name the template or setting and include an example.
Acceptance criteria define when a fix is complete.
Validate every fix with a comparable recrawl.

Knowledge check

You have completed Site Audits. Next, learn how JavaScript affects rendering and discovery in JavaScript SEO.