Technical SEO Audit: The 12-Point Checklist

A technical SEO audit is only useful if it produces a prioritized repair list. Running a crawler and exporting four hundred warnings is not an audit; it is a data dump. The twelve checks below cover the areas where genuine problems hide, and each one ends with the question that decides whether an issue deserves a sprint ticket or a note in the backlog. The order below is deliberate: access before content, evidence before opinion, and structural repairs before cosmetic ones. An audit that starts with meta descriptions and ends with crawl budget has its priorities upside down.

Start with crawl access. Review robots.txt for rules that block CSS, JavaScript, or entire sections that should be indexed, and confirm the file returns a valid response rather than a soft error. The follow-up question is whether any blocked path contains pages that appear in search or earn links. If it does, the block is costing visibility, and removing it should be tested before it is deployed to production.

The second check is XML sitemap health. A sitemap should list canonical, indexable, 200-status URLs and nothing else. Sitemaps that include redirects, noindexed pages, or non-canonical duplicates send mixed signals and waste crawl attention. Compare the sitemap against the indexable page list monthly; the difference between those two sets is usually where indexation problems begin.

Third, review index coverage in Search Console. The Page Indexing report groups URLs by status, and the counts matter less than the examples. Sample the largest excluded groups and confirm the reason is intentional. Pages excluded because of correct canonical tags or deliberate noindex directives are healthy. Pages excluded as duplicates or crawled-not-indexed are candidates for consolidation, improvement, or removal.

Fourth, examine the canonical strategy. Every indexable page should declare a canonical that matches its primary URL, and canonical tags should never point to a redirect, a 404, or a page with a different intent. Common bugs include CMS templates that canonicalize everything to the homepage, http/https mismatches, and tracking parameters that create separate canonical versions of the same content. A quick verification is to crawl the site and group pages by their declared canonical; if one target collects hundreds of pages that are not true duplicates, the template logic is too aggressive.

Fifth, walk the redirect graph. Look for chains longer than one hop, loops, and redirects that end at soft 404s. Then check that redirects are permanent where the move is permanent and temporary where content is returning. Sixth, audit HTTP status codes across the whole site, including images, scripts, and stylesheets — broken resources delay rendering and can distort how search engines evaluate the page.

Seventh, inspect URL parameters and duplicate paths. Faceted navigation, sorting options, session identifiers, and uppercase variants can multiply a single page into dozens of crawlable URLs. Decide the canonical version of each pattern, then prevent crawlable duplicates with consistent internal links, parameter handling, and canonical tags rather than letting the index absorb the noise.

Eighth, verify rendering. Fetch key templates with JavaScript disabled and confirm the main content, links, and metadata are present in the raw HTML. If content only appears after client-side hydration, work through Google's JavaScript SEO guidance and fix the rendering path before adding more content. Ninth, measure Core Web Vitals using field data, not lab scores alone, and fix the specific element or interaction responsible for a failing metric. Record the tool, the setting, and the date for each render check, because "it looked fine on my machine" is not reproducible when the problem returns.

Tenth, validate structured data. Confirm that JSON-LD parses without errors, that required properties are present, and that the markup describes content visible on the page. Eleventh, review redirects and status codes at scale by cross-checking server logs against the Crawl Stats report: which URLs does Googlebot actually request, how often, and what does it receive? Log evidence turns speculation about crawl budget into a factual discussion.

The twelfth check is internal linking, which is technical and editorial at once. Crawl the site and list pages with few or no internal links, then compare that list against pages the business cares about. If commercial pages are buried while blog tags receive hundreds of links, the internal link graph is misaligned. Fix the architecture, and several other findings in the audit tend to resolve themselves. A simple map of hub, child, and supporting pages is usually enough to expose content that belongs in navigation but was never added.

Document every finding with three fields: what is wrong, what it affects, and the evidence. A canonical conflict that splits signals across two URLs is more urgent than a missing meta description. Order the repair list by impact and effort, fix in batches, and re-crawl after each batch. An audit that ends in a spreadsheet and never closes the loop is just an expensive snapshot.