What a Real Technical SEO Audit Includes (and What Is Just a Crawl Export)

Technical audits are the easiest SEO product to fake, because a crawler produces several hundred findings in an afternoon. Export the findings, wrap them in a template, colour-code by severity, and you have something that looks like a deliverable. What you are actually paying for is judgement: which of those findings affect revenue, in what order, and at what cost to implement.

This piece describes what a substantive audit contains, how to specify one before you buy, and how to tell a diagnostic document from a formatted spreadsheet.

Rendering, not just crawling

For any JavaScript-heavy site, the decisive question is what Googlebot sees after rendering. Raw HTML crawls describe a document that no longer represents most modern applications.

• Which content exists in the initial HTML, which appears after hydration, and which never appears to a crawler at all.
• Whether internal links are real anchors with href attributes or click handlers that a crawler cannot follow.
• Whether metadata, canonicals, and structured data are present pre-render or injected client-side.
• How the rendered output differs between a first visit and a returning session, and whether personalisation hides primary content.
• What happens when a third-party script fails or times out — does the page still contain its content?

An audit that reports only raw-HTML crawl data will miss the failures that matter most on modern stacks. Ask explicitly whether rendering comparison is in scope and how it is performed.

Indexation logic, expressed as rules

Good audits explain, page type by page type, which URLs should be indexable and why. The output should be a set of rules your team can apply to new templates, not a one-off list of URLs to noindex that will be obsolete after the next release.

The test of this section is whether your engineering team could implement it without asking follow-up questions, and whether it tells them what to do with a template that does not exist yet.

Architecture and internal linking

Depth from the homepage, hub-and-spoke structure, and internal anchor distribution determine which pages accumulate authority. This is where audits create their most durable value, and where crawl exports say the least — a crawler can count links, but it cannot tell you which commercial page deserves them.

A substantive architecture section covers click depth to every revenue-relevant page, orphan detection, the ratio of navigational to contextual internal links, anchor text distribution across key pages, and whether the site's structure still matches how the business describes its products. It should end with a recommended structure, not just a diagnosis of the existing one.

Performance tied to templates and components

Core Web Vitals findings are only actionable when mapped to templates and the specific components causing them. 'Improve LCP' is not a task. 'Defer the hero carousel script and preload the hero image on the product detail template, where LCP is 4.1s at the 75th percentile on mobile' is a task with an owner and an acceptance test.

Expect field data from real users segmented by template and device, not only lab scores from a synthetic test. Expect the audit to distinguish between problems in your code, problems in third-party tags, and problems in your hosting or CDN configuration, because those three have completely different owners.

Log file analysis, where it is available

Server logs are the only direct evidence of how crawlers actually behave on your site. For large sites they are the difference between hypothesis and fact.

• Which sections receive crawl attention and which are effectively ignored.
• How much crawl activity is spent on parameters, redirects, and error responses.
• Response codes served to crawlers specifically, which sometimes differ from those served to browsers.
• Crawl frequency by template, and how quickly new content is discovered.

For a two-hundred page brochure site this is unnecessary. For a large e-commerce catalogue or a marketplace, an audit without it is guessing about the most expensive category of problem.

The rest of the checklist, briefly

1. 1Status codes and redirects: chains, loops, soft 404s, and redirects that lose relevance by pointing everything at the homepage.
2. 2Canonicalisation: protocol, subdomain, trailing slash, and case consistency; cross-domain canonicals.
3. 3Sitemaps: accurate, segmented by page type, free of non-indexable URLs, and referenced from robots.txt.
4. 4robots.txt: no accidental blanket disallows, no blocking of resources required for rendering.
5. 5Structured data: valid, matching visible content, and applied to the types that actually earn enhancements in your vertical.
6. 6International signals: hreflang cluster integrity, if applicable.
7. 7Mobile parity: the mobile experience contains the same content, links, and metadata as desktop.
8. 8Security and infrastructure: HTTPS everywhere, valid certificates, sensible caching, and stable response times under load.

The deliverable that actually matters

Ask for the remediation plan format before you buy. This is the clearest possible pre-purchase signal, and it costs the agency nothing to show you a redacted example.

Every issue should carry: a description in plain language, the evidence, the expected impact with reasoning, the effort estimate, the template scope, the owner, a dependency note, and a validation step that defines what 'done' looks like. Issues should be ranked by expected value rather than by crawler severity labels, because a crawler's 'critical' is frequently commercially irrelevant and its 'notice' is occasionally the thing costing you the most.

How to specify an audit before you buy it

1. 1State the business question. 'Why has non-brand traffic to product pages declined since the replatform?' produces a different audit from 'give us a technical review'.
2. 2Confirm rendering analysis, log analysis, and architecture recommendations are explicitly in scope or explicitly out.
3. 3Ask for the deliverable format and a redacted sample.
4. 4Agree who presents it and to whom — an audit that never reaches the engineering team is a document, not a project.
5. 5Include a follow-up: a defined number of hours to answer implementation questions and validate fixes after release.

That last item is where audits become worth their price. The findings are cheap; the sustained judgement about what to do next, in your codebase and against your roadmap, is the part you cannot generate in an afternoon.