How do you audit technical SEO with a website SEO checklist?

A technical SEO audit is a structured assessment of the technical factors that affect how search engines crawl, render, index and rank a website. A practical website SEO checklist should take you from crawl access and indexation through to site architecture, mobile usability, performance, structured data, canonicalisation, redirects and internal linking, while separating issues that affect search visibility from those that are purely cosmetic.

Start by defining the scope of the audit. Decide whether you are reviewing the whole domain, a subfolder, a template type or a recent site migration. Record the date of the audit, the areas covered and any known changes, such as a redesign, platform migration or change to URL structure. This gives you a reliable comparison point when you re-audit the site and helps prevent unrelated issues from being mixed together.

Check that important pages can be crawled. Search engine crawlers need to reach a page through a permitted, functional path before they can assess its content. Review the robots.txt file for rules that unintentionally block important folders, templates, resources or entire sections of the site. Blocking a page in robots.txt does not reliably remove it from search results; it mainly restricts crawling. Use the appropriate indexing directive when a page should be crawled but excluded from the index.

• Confirm that the robots.txt file is available at the correct domain and protocol.
• Check that important CSS, JavaScript and image resources are not blocked when they are needed to render the page.
• Look for broad disallow rules left over from development or staging.
• Make sure the XML sitemap contains the canonical, indexable versions of important URLs.
• Remove redirected, blocked, duplicate or error URLs from the sitemap unless there is a specific technical reason to retain them.

Review indexation controls. Inspect the robots meta tag and any equivalent HTTP header on key templates. Pages intended to appear in organic search should not carry a noindex directive, while private, duplicate, filtered or utility pages may need one. Check for conflicting instructions, such as a page being included in an XML sitemap while also marked noindex, or a canonical pointing to a different URL without a clear reason.

Compare the pages you expect to be indexed with the pages search engines have discovered and processed. A gap can indicate weak internal linking, accidental noindex directives, crawl barriers, duplicate content, poor-quality URL variations or problems introduced by a content management system. Review representative pages rather than relying only on an aggregate index report, because a single report can group together URLs with very different causes.

Assess URL structure and canonicalisation. Each important page should have a stable, descriptive and consistently formatted URL. Test how the site handles trailing slashes, capital letters, parameters, alternative protocols and different hostnames. Where several URL versions show substantially the same content, select one preferred canonical URL and make the other signals support that choice.

• Use self-referencing canonical tags on indexable pages where appropriate.
• Point duplicate or near-duplicate pages towards the preferred version when consolidation is intended.
• Ensure canonical URLs use the correct protocol, hostname and path.
• Do not canonicalise unrelated pages merely to suppress them from search.
• Check that internal links, XML sitemaps and redirects use the preferred URL format.

Canonical tags are hints rather than absolute commands. Search engines may choose a different canonical if the page is blocked, weakly linked, substantially different from the declared target or inconsistent with other signals. Treat canonicalisation as part of a wider consistency check rather than as a replacement for removing unnecessary duplicates.

Map the site architecture and internal links. A sound architecture groups related pages into clear topical and functional sections. Important pages should be reachable through ordinary HTML links, not only through internal search, filters, scripts or an XML sitemap. Review click depth, orphan pages, excessive folder nesting and links that point to redirected or non-canonical URLs.

Check that navigation supports users and search engines without creating an uncontrolled number of URL combinations. Faceted navigation, sorting parameters, internal search results and session URLs can generate large amounts of duplicate or low-value content. Establish which variations need to be crawlable, which should consolidate to a preferred page and which should remain outside the index. Preserve useful pathways to commercially or editorially important pages.

Crawl the site as a search engine would. Use a crawler configured to follow the site’s actual directives and record status codes, indexability, canonicals, titles, headings, links and resource references. Analyse the results by template and directory, not just as a single list of errors. A repeated problem on a product, service or article template can have a greater effect than an isolated issue on a low-value page.

• Identify broken internal links and links returning unexpected status codes.
• Find redirect chains, redirect loops and redirects to irrelevant destinations.
• Locate orphan URLs and pages receiving very few internal links.
• Review duplicate titles, missing titles and titles that do not describe the page.
• Check for missing, duplicated or poorly structured heading elements.
• Detect duplicate, thin or near-empty pages created by templates or URL parameters.
• Compare crawlable URLs with the URLs listed in the XML sitemap and analytics records.

Test redirects and error handling. Permanent URL changes should resolve directly to the most relevant current destination. Avoid routing many old URLs to the homepage when a more specific replacement exists, as this can create a poor user experience and weaken the clarity of the redirect. Remove unnecessary chains so that old URLs reach their final destination in a single meaningful step where possible.

Check that genuinely unavailable pages return an appropriate not-found response rather than a successful response containing an error message. A so-called soft error page can make it harder to distinguish valid content from removed content. Custom error pages should provide useful navigation, but they should not return a successful status for a URL that does not exist.

Review mobile usability and rendering. The mobile version should contain the same essential content, links, metadata and structured data as the desktop version. Check responsive layouts at different viewport sizes, including navigation, forms, tables, images, menus and interactive elements. Look for content hidden in a way that prevents access, horizontal scrolling, overlapping controls and tap targets that are difficult to use.

Check the rendered page rather than relying solely on the raw HTML. Important content or links that appear only after complex client-side processing may not be reliably available to crawlers or users with limited browser capability. Ensure that key text, internal links, canonical information and structured data are present in the rendered output and that critical functionality does not depend on blocked or failed resources.

Measure technical performance. Page speed should be assessed by template, device type and page purpose. Review loading behaviour, responsiveness and visual stability rather than focusing only on a single overall score. Identify large images, unnecessary scripts, render-blocking resources, excessive third-party requests, inefficient fonts, poor caching and server delays.

• Serve appropriately sized, compressed images and provide useful alternative text where images convey information.
• Load non-essential scripts only when they are needed.
• Reduce unused code and avoid loading functionality across templates that do not use it.
• Use caching and suitable content delivery arrangements where they improve delivery.
• Investigate slow server responses separately from front-end rendering issues.
• Retest important templates after changes on both mobile and desktop connections.

Performance improvements should be prioritised by the number and importance of affected pages, the severity of the delay and the feasibility of the fix. Do not remove useful functionality solely to improve a laboratory test if it damages accessibility or conversion paths. A balanced audit considers real user experience, crawlability and business purpose together.

Validate structured data. Structured data should accurately describe the visible content on the page and follow the relevant technical requirements for its type. Check that required properties are present, values are valid and markup is not duplicated or applied to content that users cannot see. Remove outdated markup when a template changes, and review structured data across every template rather than checking only one example.

Structured data can help search engines interpret a page, but it does not guarantee enhanced search presentation or higher rankings. Treat it as a supporting signal. The underlying page still needs accessible content, clear information architecture and appropriate indexation.

Check on-page technical signals. Technical auditing overlaps with on-page SEO where page elements affect discoverability or interpretation. Review title elements, meta descriptions, headings, image attributes, language declarations and duplicate content at template level. Titles should be unique and accurately reflect the page. Meta descriptions should describe the page clearly, although search engines may choose alternative snippets.

Confirm that each page uses the correct language and regional signals where relevant, particularly on multilingual or multi-regional websites. Check alternate language annotations for reciprocal references, valid destination URLs and consistent indexing rules. Review pagination, archive pages and content feeds according to the site’s purpose rather than applying blanket rules.

Inspect security and availability. The site should use secure connections consistently, with no mixed-content warnings or insecure assets on important pages. Check certificate coverage, protocol redirects, hostname consistency and whether essential pages remain available during deployments. Review staging, test and preview environments to ensure they cannot be indexed or exposed as duplicate versions of the live site.

Also check uptime patterns, server errors and changes in response codes. Short-lived faults can still affect crawling if they occur during a major release or affect a large group of URLs. Keep deployment controls, redirects, robots.txt rules and indexation settings under review whenever the platform or hosting environment changes.

Prioritise and document the findings. An audit is most useful when every issue has a clear example, affected template or URL group, likely cause, recommended action and validation method. Prioritise issues that block crawling or indexation, affect important page groups, create widespread duplication or prevent users from accessing core content.

• Critical: issues that make important content unavailable, unindexable or inaccessible, such as broad crawl blocks, accidental noindex rules or major server failures.
• High: widespread problems that dilute signals or damage usability, such as redirect chains, incorrect canonicals, broken internal links or severe template performance issues.
• Routine: isolated metadata gaps, minor structural inconsistencies and improvements that should be addressed during normal optimisation work.

After implementation, recrawl the affected sections and confirm the response codes, indexation directives, canonicals, internal links and rendered content. Monitor organic landing pages, crawl patterns and server errors for unexpected changes. Repeating the checklist after major releases, migrations and template changes helps catch regressions before they affect a wider portion of the site.