Technical SEO audit checklist

List the hostnames, protocols, subfolders, parameter rules and page types that are in scope. Decide whether the crawl should render JavaScript, authenticate, respect robots.txt and include XML sitemaps. Record the date and configuration. Without this record, a difference between two crawls may reflect different settings rather than a website change.

Sample pages that matter to the business: home, category, product or service, article, search, pagination and error templates. A crawl is a model of a site, not the site itself. Check its results against a browser, the HTTP response and, when appropriate, a mobile-rendered view. This prevents conclusions based solely on a tool's interpretation.

• Declare included and excluded URL patterns.
• Keep a baseline URL list for critical templates.
• Capture crawl settings and any access limitations.

Review whether important pages are reachable through normal internal links and whether links resolve with intended HTTP responses. Investigate broken internal links, redirect chains, redirect loops and links that point to non-canonical variants. A redirect is not inherently bad: migrations and retired pages often need one. The question is whether the destination matches the former page's purpose and whether chains can be simplified.

Compare internally discovered URLs with sitemap URLs and the pages that should exist in your information architecture. Orphaned pages can be hard for people and crawlers to find, while endless filters or session parameters can waste crawl attention. Do not block or remove a pattern merely because it is large; first establish whether it supports a useful user journey or an intentional indexable collection.

• Test 200, 3xx, 4xx and 5xx patterns by template.
• Find orphaned and deeply linked important pages.
• Review parameter, faceted-navigation and pagination behaviour.

For each important URL type, inspect robots meta tags, X-Robots-Tag headers, canonical elements and the final response after redirects. A canonical is a hint for preferred consolidation, not a way to repair every duplicate problem. It should point to an accessible, indexable page that represents the same or very similar content, and it must fit the site's internal-linking and sitemap choices.

Use Search Console URL Inspection and indexing reports as one source of evidence for verified properties. They can reveal Google's selected canonical or a reason a URL is not indexed, but they are not a real-time audit of every URL. When a page is intentionally excluded, document why. When it is unexpectedly excluded, check the page's status, directives, canonical, links and rendered content before changing anything.

• Confirm robots.txt does not conflict with intended crawling.
• Check noindex, canonicals and headers on live pages.
• Keep XML sitemaps limited to canonical URLs you want indexed.

Check that each key page has a specific job and a coherent title, main heading and visible content. Duplicated titles can point to template issues, but uniqueness alone is not quality. Look at the search result, the page's audience and what it actually offers. Use descriptive anchor text and meaningful image alternatives where images convey information; neither is a substitute for a useful page.

Validate structured data against the visible page and the relevant vocabulary. Markup is a way to describe content, not a promise of rich results. Avoid generating unsupported properties or using schema to conceal missing information. After template changes, inspect representative rendered pages and validate JSON-LD syntax, then watch for errors in the appropriate Search Console enhancement reports where available.

• Compare title, H1 and visible purpose rather than counting keywords.
• Check duplicate, thin and unintentionally empty templates.
• Validate markup against Schema.org vocabulary and visible content.

Use field data to understand experienced performance and lab tools to investigate likely causes. Core Web Vitals focus on loading, responsiveness and visual stability, but performance is also shaped by devices, networks, caches and user paths. A favourable lab score from one location does not prove that a template is healthy for all visitors; an unfavourable run is a prompt to investigate, not a verdict.

Review the asset and delivery patterns behind slow pages: render-blocking resources, oversized images, unused JavaScript, third-party tags, server response and layout shifts from late-loading elements. Test representative templates rather than only the homepage. Coordinate changes with developers because caching, image processing and script loading can have functional, privacy and measurement trade-offs.

• Separate field observations from lab diagnostics.
• Test meaningful page templates and device conditions.
• Retest after deployment without promising a ranking outcome.

For a multilingual site, make every variant useful in its own language and keep language switching accessible to people. Use hreflang only where pages are equivalent alternatives, return valid URLs and form reciprocal relationships including a self-reference. A generic language selector or country redirect should not prevent crawlers and users from reaching the intended variant.

Swiss German content needs the same editorial care as any other locale: write naturally for the audience, preserve locale-specific contact and legal information where relevant, and do not rely on machine substitution alone. Validate hreflang clusters at page level after releases. A broken single return link can make a cluster unreliable, so test representative product, editorial and utility pages.

• Use ISO language and optional region codes correctly.
• Ensure alternate URLs are crawlable and canonically consistent.
• Test reciprocal hreflang links and language-switch paths.