An audit should tell the developer which URLs to test, what failure to reproduce and how to confirm the fix. A severity score without that trail is not a ticket.
Crawlability and indexation
Start with the URLs search engines can find and those that should appear in results. Check robots directives, XML sitemaps, indexability signals, pagination and parameter behavior, and samples from Search Console. State when a finding comes from a crawl versus live search data.
- Blocked or accidentally noindexed pages
- Canonical and duplicate URL patterns
- Redirect chains and error responses
Rendering, navigation, and site architecture
Inspect whether important links and page content remain discoverable when JavaScript is involved. Review menu paths, orphaned pages, depth, internal linking, structured data, and template-level issues. A site-wide bug often matters more than a one-page typo.
- Rendered HTML checks
- Internal-link destination integrity
- Site structure by template
Performance with honest context
Separate laboratory performance diagnostics from field data. Report the device, source, time period, and template. Core Web Vitals can inform prioritization, but a faster score alone is not a guarantee of higher rankings or more conversions.
- Largest Contentful Paint conditions
- Interaction responsiveness and layout stability
- Image, script, and caching opportunities
Business relevance and prioritization
An audit becomes useful when the findings are ranked by impact, confidence, effort, number of affected pages, and dependencies. The document should explain why one fix comes before another, not simply display severity labels generated by a tool.
- Priority rationale
- Assigned implementation owner
- Estimated dependency and review point
Verification and handoff
Every recommendation needs a testable finish. Link to the live change, re-crawl representative pages, and record what improved, what remains, and where external factors limit confidence. Never mark a fix complete just because an email was sent.
- Before/after evidence
- Implementation date and URL
- Reviewer signoff or outstanding blocker
Sample audit issue record and re-test procedure
A useful audit finding is reproducible. Suppose a priority service URL has two consecutive redirects before the canonical destination. The issue ticket should expose the response sequence rather than just label the page “high priority.”
| Example or checkpoint | Recommended action | Review or acceptance |
|---|---|---|
| Evidence | Request URL, redirect status chain, final destination, crawl timestamp | Another reviewer can reproduce the observation |
| Risk assessment | Internal linking to old URL may waste hops or confuse canonical targeting | Priority depends on page importance and actual crawl impact |
| Recommended action | Update internal links to the canonical destination; review redirect rules | Developer has exact links or templates to change |
| Acceptance | Re-crawl sample URLs and inspect final canonical response | Document before/after proof and remaining exceptions |
High impact is an assessment, not a guarantee. Prioritize across affected templates, expected search value and implementation cost, then retest after publishing.
Download: Technical audit issue tracker (CSV)
Relevant reference material
Frequently asked questions
Should the audit include every tool warning?
Tool exports can be attached, but the executive audit should focus on validated and prioritized findings.
Can a technical audit guarantee traffic growth?
No. The audit removes or explains barriers; demand, content, and competition remain relevant.
Who implements the changes?
The scope should name whether the SEO agency, developer, or client implements each recommendation.
An audit issue a developer can actually close
Hypothetical example: a category template generates non-canonical indexable URLs. An actionable audit records the URL pattern, the response and indexability signals, the intended canonical, and a retest after deployment.
| Evaluation element | Practical check |
|---|---|
| Observation | Specific URL pattern and how the crawler finds it |
| Reproduction | HTTP status, canonical, robots and internal link evidence |
| Proposed fix | Approved canonical policy and relevant template changes |
| Retest | Confirm expected URLs and signals after publishing |
| Closure | Attach dated validation rather than relying on a completion label |