A technical SEO audit should explain what is blocked, why it matters, and what to fix first
A technical SEO audit should show which valuable page groups search engines cannot reliably discover, render, understand, or select for indexing. Before buying one, agree on the business journeys in scope, the templates that generate them, the environments and data the auditor can access, and the decisions the report must support. The useful output is not a score. It is reproducible evidence, affected URL patterns, business impact, an owner, a fix, and a test that proves the fix worked.
Ask the provider to separate confirmed faults from risks and opportunities. A blocked product template is a fault. A hypothesis that changing title patterns may improve clicks is an opportunity. Mixing both into a list of 200 warnings makes the report look thorough while leaving the delivery team to perform the diagnosis again.
Scope the audit around page groups and decisions, not a crawler limit
The first scope document should inventory page types: homepage, category, product or service, editorial, location, account, search, filter, campaign, and any international variants. For each type, name its job, how URLs are created, whether it should be indexed, and which conversion or user task it supports. Add known releases, migrations, traffic changes, and technical constraints. This turns a website SEO audit into an investigation of a system rather than a tour of isolated URLs.
Access changes the quality of the work. Search Console can reveal indexing patterns, selected canonicals, crawl findings, Core Web Vitals groups, and structured data issues. Analytics can show which landing pages and journeys matter. Server or CDN logs can show what bots requested. The CMS and repository explain how one defect becomes ten thousand URLs. An audit with no access can still test public behavior, but its conclusions should state that limit.
Sampling should follow templates and risk. Crawling every parameter combination can create noise or load. Testing only the homepage misses systemic faults. A credible proposal explains its URL sources, exclusions, crawl controls, representative samples, and how it will investigate patterns discovered during the first pass.
Test the full path from discovery to the indexed canonical
Google describes Search as a sequence that includes crawling, rendering, and indexing. A technical SEO audit should therefore trace representative URLs through that sequence. Check discoverable links, robots rules, HTTP status, redirect behavior, sitemap membership, initial HTML, rendered HTML, robots metadata, canonical signals, and the result reported by URL Inspection. A page returning 200 in a browser is only the start of the test.
Google Search Central's JavaScript SEO guidance says Googlebot queues pages for rendering and uses rendered HTML for indexing. It also warns that a `noindex` in the original response may cause rendering to be skipped, so removing it later with JavaScript may not work as intended. The audit must compare what the server sends with what the application produces after execution.
Use evidence that another person can reproduce: request and response headers, the exact URL, timestamp, rendered excerpt, screenshot when visual state matters, and the relevant Search Console result. "JavaScript issue" is not a finding. "Service pages return an empty app shell until an API request that fails for the rendered test" is a finding a developer can investigate.
Audit canonical and internal-link rules at the template level
Canonical problems are often rules problems. Facets, tracking parameters, pagination, translations, duplicate collections, and preview hosts can each produce several URLs for similar content. Google treats canonical declarations as signals rather than commands, so the audit should compare redirects, canonical elements, sitemap entries, internal links, and Google's selected canonical instead of celebrating that a tag exists.
The canonicalization documentation recommends consistent internal links to the preferred URL and notes that redirects, `rel="canonical"`, and sitemap inclusion have different strength. That creates a useful test: for each page group, do the server, HTML, sitemap, navigation, and index all point toward the same destination?
Consider a hypothetical marketplace with region and campaign parameters. A crawler may report thousands of duplicate titles, but the root cause could be one routing rule that exposes every parameter combination and a navigation component that links to them. Fixing titles one by one would be theatre. Correcting URL generation, canonical policy, and internal links addresses the system.
Treat performance as a user diagnosis, not a single Lighthouse number
Performance work needs field and lab evidence. Field data describes what real visits experienced across devices and networks. Lab tests make a controlled problem reproducible and expose likely causes. web.dev's Core Web Vitals workflow recommends starting with real-user data where available, then using diagnostics to understand LCP, INP, CLS, TTFB, and related causes. A green desktop run does not cancel a poor mobile page group in the field.
Prioritize performance findings by journey and shared cause. A late hero image on one campaign page differs from a client-side navigation pattern that delays every product view. The report should identify the affected template, resource or interaction, the likely bottleneck, the user consequence, and how the team will measure the change after release.
Performance is adjacent to, but not a substitute for, accessibility. If the audit uncovers keyboard traps, unreadable states, missing names, or other barriers, route them into a proper website accessibility audit with manual testing. One automated SEO crawl cannot establish accessibility conformance.
Turn the audit into a release plan with acceptance tests
Every prioritized issue should contain seven fields: evidence, affected pattern, consequence, recommendation, owner, dependency, and verification. Severity should combine reach, business importance, certainty, and effort, not merely inherit a tool's default label. A missing meta description on a low-value archive may be less urgent than a canonical rule excluding a revenue-driving category, even if the crawler colors both red.
Group work into immediate containment, template fixes, platform changes, and experiments. Then write acceptance tests before implementation. Examples include: all indexable service pages return meaningful HTML and a self-referencing canonical; removed URLs redirect once to the mapped replacement; the sitemap contains only canonical 200 URLs; or the affected mobile page group improves in field data without breaking conversion.
If a redesign or CMS migration is approaching, connect the audit to the website redesign strategy. Google recommends mapping old URLs to new ones, updating internal links and canonicals, testing redirects, submitting a new sitemap, and monitoring the move. Those tasks need owners and a rollback path before launch, not a post-launch slide labeled SEO.
The most convincing audit mistakes are the ones with the most data
Common failures include exporting every crawler warning, treating all URLs as equally valuable, using one lab run as real-user evidence, diagnosing from status codes without rendering, recommending schema that does not match visible content, and promising rankings after technical fixes. Google's own SEO starter guidance says there are no secrets that automatically rank a site first. Technical quality removes obstacles; it does not create demand, useful content, authority, or a compelling offer by itself.
Tool findings also need verification. A crawler can flag intentional exclusions, fail behind authentication, miss client states, or infer a problem from an incomplete sample. Search Console data is specific to Google and can lag. Field performance may be unavailable for low-traffic URLs. A responsible auditor records these limits and proposes the next observation instead of upgrading uncertainty into a defect.
An audit is not finished when the PDF is delivered. Reserve time for a technical walkthrough, questions from implementers, review of the proposed tickets, and a focused retest. If the provider cannot explain how findings become verified releases, the buyer is purchasing diagnosis without treatment.
Technical SEO audit buying checklist
- Name the business journeys, page groups, countries, devices, and environments in scope.
- List available Search Console, analytics, log, CMS, repository, and release-history access.
- Require separate evidence for crawl, render, index, canonical, performance, and migration findings.
- Ask how samples are chosen, how crawler load is controlled, and how template patterns are confirmed.
- Require severity based on reach, value, certainty, and effort, with an owner and acceptance test.
- Include an implementation walkthrough, ticket review, retest window, and explicit audit limitations.
Before requesting proposals, prepare a one-page brief with the important journeys, page types, known changes, current evidence, and the decision date. A short product discovery workshop can help when the real question is broader than search. For a focused technical SEO audit, send the brief to Seuil Digital and ask us to define the smallest investigation that can change the release plan.