A technical SEO audit explains how a website’s delivery system affects search discovery, rendering, indexing and user access. It should identify causes, affected templates, business impact and a testable response. A crawl export with thousands of warnings is evidence collection, not the finished audit.

The most useful audit is proportional to the site’s risk and operating model.

Define scope and questions

Record:

  • production domains, protocols and environments;
  • countries, languages and search surfaces;
  • critical page types and journeys;
  • content systems, frameworks and rendering patterns;
  • recent migrations, redesigns and incidents;
  • analytics and Search Console properties;
  • known business priorities;
  • access limitations and assumptions.

Turn concerns into questions. “JavaScript” is not an audit issue. “Are primary product details and internal links present in the rendered HTML at canonical URLs?” is testable.

Build a representative page sample

Large sites cannot be understood from the homepage. Select examples across:

  • high-value and high-traffic pages;
  • new and old content;
  • indexable and intentionally excluded pages;
  • categories, products, articles, tools and support;
  • parameters, pagination and filters;
  • localized pages;
  • redirects, errors and retired content;
  • mobile and desktop experiences;
  • pages generated by each platform or template.

Use a full crawl where appropriate, but keep the sample for deeper manual testing. Template-level causes matter more than isolated symptoms.

Map how URLs are discovered

Compare several sources:

  • internal crawl;
  • XML sitemaps;
  • analytics landing pages;
  • Search Console pages;
  • server logs where available;
  • CMS and database exports;
  • backlink or external URL data;
  • redirect registries.

Differences reveal orphaned pages, obsolete URLs, crawl traps and indexable surfaces absent from navigation. No single source contains the complete website.

Test status and redirect behavior

Every important URL should return behavior that matches its state:

  • successful canonical page: 200;
  • permanently moved equivalent: 301;
  • temporary move only when it is truly temporary;
  • missing page: 404 or, in selected permanent-removal cases, 410;
  • server failure: a real 5xx, not a branded page with 200.

Check chains, loops, mixed protocols, host variants, trailing slashes, case and legacy file extensions. Redirects should point to the closest true equivalent, not the homepage by default.

Verify robots and index controls

Separate crawling from indexing:

  • robots.txt controls crawler access;
  • robots meta and HTTP directives can request noindex when the page is crawlable;
  • canonical signals a preferred duplicate URL;
  • authentication prevents public access;
  • sitemaps support discovery but do not control indexability.

Audit conflicting signals. A page blocked in robots.txt may prevent a crawler from seeing its noindex directive. A noindexed page should not be the only destination of important internal links or remain in an indexable sitemap without an explicit reason.

Inspect rendering

Compare initial HTML, rendered HTML and the visible page. Test:

  • primary text and headings;
  • canonical, robots and alternate-language tags;
  • internal links as standard anchors;
  • structured data;
  • images and alternatives;
  • content loaded after interaction;
  • error and empty states;
  • consent behavior;
  • mobile output.

Google’s JavaScript SEO basics describes its crawl-render-index process and recommends server-side or pre-rendering as a strong approach. The audit should still consider other crawlers and users that may not execute JavaScript.

Review canonicalization and duplication

Identify duplicate routes created by:

  • parameters and facets;
  • tracking codes;
  • print or share versions;
  • host and protocol variants;
  • trailing-slash and case differences;
  • copied product or location templates;
  • paginated or sorted views;
  • separate mobile or application routes.

Canonical tags should be consistent with redirects, internal links and sitemap URLs. Google’s canonical guidance treats redirects and rel="canonical" as strong signals and sitemap inclusion as weaker. Align the system rather than relying on one tag.

Evaluate site architecture

Measure whether priority pages are reachable through meaningful crawlable paths. Inspect:

  • top-level navigation;
  • category and parent-child relationships;
  • contextual links;
  • breadcrumbs;
  • related-content logic;
  • pagination;
  • orphan and dead-end pages;
  • anchor language;
  • depth by page type and business importance.

Click depth is a diagnostic, not a universal score. The question is whether the architecture reflects user tasks and organisational priorities.

Validate sitemaps and modification dates

XML sitemaps should contain canonical, indexable, successful URLs. Modification dates should reflect meaningful page changes, not every deployment. Split large or multi-market sites when segmentation makes monitoring easier.

Google’s sitemap documentation explains protocol limits and supported formats. Validate syntax, URL count, response behavior and consistency with the indexable inventory.

Inspect metadata and structured data at scale

Check unique titles, descriptions, headings, canonicals, language declarations and social previews by template. Duplicates can reveal system gaps even when they are not direct penalties.

Structured data must match visible content and use the correct page type. Validate syntax, eligibility requirements and the source fields that generate it. Do not treat a testing tool’s successful result as a guarantee of a rich result.

Include performance and accessibility where they affect access

Use field data and representative lab tests to find issues that block or delay meaningful use. Do not turn the audit into a list of performance scores without identifying the responsible resource, template and user effect.

Technical SEO and accessibility overlap in semantic structure, link clarity, alternatives and reliable interaction. Include critical access failures and route them to the appropriate accessibility process.

Prioritize by mechanism and risk

For each finding, record:

  • evidence and reproduction steps;
  • affected template or URL set;
  • search and user mechanism;
  • business or service impact;
  • confidence;
  • required owner and dependency;
  • recommended response;
  • acceptance test;
  • rollback or monitoring requirement.

Group symptoms under causes. Five thousand pages with a missing canonical are one template control problem, not five thousand separate recommendations.

Prioritization should consider impact, reach, confidence, effort, time to effect and risk. A widespread rendering failure on revenue pages normally deserves attention before minor title-length variance.

Deliver an implementation system

The audit handoff should contain:

  • an executive summary of material risk;
  • a technical evidence appendix;
  • a prioritized action register;
  • exact acceptance criteria;
  • representative test URLs;
  • owners and dependencies;
  • monitoring and release annotations;
  • unresolved questions.

Review findings with the teams that will implement them. Developers often reveal system constraints that change the recommendation; content owners reveal publication behavior a crawler cannot explain.

Re-test after release. A ticket marked complete is not proof that rendered behavior changed. The audit is successful when it improves the website’s operating controls, not when it produces the longest list of issues.