Technical SEO audit: a prioritised checklist for websites

A useful technical SEO audit turns evidence into an ordered queue of work. It separates conditions that can block discovery or indexation, defects that affect an entire template and items that are merely untidy. That distinction makes the audit actionable.

Define the decisions before the first crawl

SEO tools observe different parts of the same system. A crawler can map internal links and response codes. Google Search Console adds evidence from Google’s systems, but its Performance reports can omit anonymised queries, retain only the most significant rows and update with a delay. Log files show requests made to the server, while browser tests reveal what a person can actually use after scripts run.

No single score can reconcile those views. Before collecting data, define the questions the audit must answer:

• Which page types support the organisation’s most important journeys?
• Which technical conditions can prevent those pages being discovered, rendered or selected for indexing?
• Is a finding isolated, or produced by a rule shared across hundreds of URLs?
• What evidence will show that a fix has worked?

This framing also protects the development backlog. A red warning is not automatically urgent, and an apparently small template defect can be critical when it reaches every service or product page.

Build an audit inventory

Record the systems and boundaries before the first crawl. Include the production domains, subdomains, language folders, content delivery layers and third-party services in scope. Decide how to treat PDFs, campaign pages, internal search, parameters and logged-in areas. If a staging environment is part of the review, describe how it is protected.

Then create a short inventory of page types. A service page, product detail page, location page and editorial guide may share a header, but they have different purposes and indexation rules. Select representative URLs for every template and add known edge cases. This sample will be used repeatedly during rendering, structured-data and performance checks.

Capture baseline indicators at the same time: organic landing pages, clicks and impressions, important query groups, index coverage by page type, organic conversions and current field performance where it is available. These values are context, not proof that a technical change caused a later movement.

Trace the route from discovery to indexation

A URL that is absent from search results may be undiscovered, blocked from crawling, marked as non-indexable, treated as a duplicate, not selected for indexing, or indexed without meaningful visibility. An audit should preserve those states rather than labelling all of them “not indexed”.

Discovery and crawl access

Review internal links, XML sitemaps and other deliberate discovery paths. Important pages should not rely on an XML sitemap alone. They need contextual internal links that both people and crawlers can follow.

Check robots.txt alongside meta robots directives, X-Robots-Tag headers, authentication and firewall behaviour. These controls do different jobs. Blocking a URL in robots.txt does not reliably remove it from search, while a noindex instruction cannot be processed if the crawler is prevented from reading the page.

Indexable signals

For each indexable template, compare the final response, robots directives, canonical target, inclusion in the XML sitemap and internal links. Conflicting signals are often more revealing than any one tag. A page should not be linked as the preferred version while redirecting elsewhere or declaring another URL as canonical.

Use Search Console URL inspection for a focused sample of valuable and problematic pages. It should complement, not replace, the crawl. Differences between the declared canonical and Google-selected canonical deserve investigation at template level.

Read status codes in context

A response code says what happened to a request, not how much it matters. Prioritise affected URLs by their role, internal links, external links and organic demand.

The audit should identify:

• internal links to redirects, errors and unavailable servers;
• redirect chains, loops and inconsistent protocol or host rules;
• temporary redirects used for permanent moves;
• irrelevant redirects that may be understood as soft 404s;
• deleted pages without a considered destination or status;
• multiple live URL variants serving substantially the same page.

Do not turn every missing URL into a homepage redirect. If there is no close replacement, an honest not-found or gone response can be clearer for users and search engines. If there is an equivalent destination, update the internal link as well as applying the redirect.

Test canonicalisation as a system

The presence of a canonical element is not enough. Test whether the target is reachable, indexable and genuinely represents the same content. Then confirm that redirects, sitemaps, navigation and alternate-language annotations reinforce the same preferred URL.

Parameter combinations, filtered categories, print views and tracking links are common sources of duplication. The right treatment depends on whether a variant provides a distinct user task. Canonicalisation is not a substitute for deciding which pages should exist and how people should reach them.

Compare raw and rendered content

For JavaScript-driven templates, inspect both the initial HTML and the rendered document. Check whether primary content, navigation, links, titles and structured information appear without requiring a click or a delayed client-side request that fails for crawlers.

Run this comparison on representative templates rather than only the homepage. If a product grid renders correctly but pagination links do not, the homepage test will miss the actual discovery problem. Record failed resources, browser errors and dependencies on consent or geolocation.

Investigate performance by cause and reach

Laboratory tests are controlled diagnostics; field data reflects real visits across devices and connections. Use both. A performance score by itself cannot show whether the issue is common or confined to one unusual page.

Group findings by likely cause: slow server response, oversized media, render-blocking resources, unstable layout, long main-thread tasks or third-party scripts. Then map each cause to page types. Fixing a shared component may improve thousands of visits, whereas hand-optimising one low-value page may barely be noticed.

Performance recommendations should include a test condition. For example: the hero image is delivered in an appropriate format and size at each breakpoint; the element that becomes the largest contentful paint candidate is preloaded only when needed; and the template is re-tested in both lab and field monitoring after release.

Audit the architecture people actually use

Technical SEO includes the way the site communicates priority and relationships. Examine click depth, orphaned pages, navigation patterns, breadcrumb behaviour and anchor text. A page may return 200 and be indexable while still receiving little context or internal importance.

Follow several high-value journeys manually. Can someone move from an informational entry page to a relevant service, product or contact path without using site search? Are related pages linked because they help the next decision, or only because a generic widget repeats the same links everywhere?

For multilingual sites, verify that language alternatives are real equivalents, return successfully, remain indexable and point back to the complete language set. Language navigation should not silently send visitors to a homepage when the matching page exists.

Turn findings into an implementation queue

A practical priority model uses four dimensions:

1. Impact: can the issue block discovery, indexation, usability or measurement?
2. Reach: does it affect one URL, a template or the whole platform?
3. Confidence: is the cause demonstrated, or is further testing required?
4. Effort and dependency: which team must implement, review and deploy it?

High-impact, broad and well-evidenced issues normally rise to the top. A speculative idea with limited reach should become an experiment or investigation, not an emergency ticket.

Each task needs an example URL, the affected rule, the intended outcome and an acceptance test. “Fix broken canonicals” is not enough. A developer should be able to see which template condition changes, while an SEO reviewer should be able to verify the result without interpreting the ticket again.

Close the audit with a re-crawl

After implementation, re-crawl the affected templates, repeat the chosen browser tests and check that redirects, canonicals and internal links now agree. Confirm that the release has not created a new issue elsewhere. Indexation-related changes then need observation time; immediate ranking improvement is not a sensible acceptance criterion.

When the review spans several templates, languages or a planned migration, a structured SEO audit can bring crawl data, search evidence and development constraints into one implementation plan. The useful deliverable is the queue of verified decisions—not the number of warnings collected.

Handover checklist

• Scope, page types and baseline indicators are recorded.
• Discovery, crawl access, indexability and visibility are treated separately.
• Redirects, canonicals, sitemaps and internal links support the same preferred URLs.
• Raw and rendered output has been sampled across important templates.
• Every issue includes impact, reach, owner and an acceptance test.
• A focused re-crawl and post-release monitoring period are scheduled.

If those six points are present, the audit can survive the handover from SEO to development. That is a better quality test than any single health score.