Technical SEO Audit Checklist

Technical SEO is the plumbing of search visibility: invisible when it works, catastrophic when it doesn’t. The best content on the web earns nothing if crawlers can’t reach it, renderers can’t see it, or duplicate signals scatter its authority across five URLs. A proper audit walks the same pipeline a search engine does — discover, fetch, render, index, rank — and checks each stage for leaks. This checklist is organized in that order, because sequence matters: there is no point optimizing page speed on pages that are accidentally noindexed. Run it quarterly for large or frequently changed sites, at minimum annually for stable small ones, and always after migrations and redesigns.

Stage one: crawl access

Robots.txt sanity

Read your robots.txt file line by line. Confirm it doesn’t block CSS or JavaScript directories (engines must render pages as users see them), doesn’t disallow sections you want indexed, and does reference your sitemap. Check for the classic disasters: a leftover staging-wide Disallow: /, rules copied from another site, or blocks on parameters that also catch real pages. Decide deliberately which AI crawlers you permit — those directives now carry visibility consequences beyond classic search.

Server responses and crawl errors

Pull the crawl stats and indexing reports in Search Console: spikes in 404s, soft 404s (thin pages returning 200 that Google treats as errors), 5xx server errors, and DNS issues all throttle crawling. Verify your site returns proper status codes — real 404s for gone content (or 410 when permanent), 301s for moves, no redirect chains longer than a hop or two, and no redirect loops. Every chain wastes crawl budget and leaks link equity.

Sitemap integrity

The XML sitemap should contain only canonical, indexable, 200-status URLs — no redirects, no noindexed pages, no duplicates — and should update automatically when content changes. Compare sitemap URL counts against actual indexed counts; large gaps in either direction are diagnostic gold. Oversized sites need segmented sitemaps so you can localize indexation problems by section.

Stage two: indexation control

What’s in the index that shouldn’t be

Audit for index bloat: parameter variations, internal search results, tag archives, staging subdomains, printer versions, paginated duplicates. Each junk URL dilutes crawl attention and quality averages. Remove with the right tool for each case — noindex for pages users need but engines don’t, canonical tags for legitimate variants, robots blocks only for sections that should never be fetched (remembering a blocked page can’t pass its noindex).

What’s out that should be in

The inverse audit: pull your money pages and confirm each is indexed. Common silent killers found here: stray noindex tags surviving from development, canonicals pointing at the wrong page, pages orphaned from internal links, and JavaScript-dependent content the renderer never saw. Search Console’s URL inspection shows exactly how Google last processed any page — the single most useful diagnostic in a technical SEO toolbox.

Canonicalization coherence

Every page should declare one canonical URL, and all your signals should agree with it: internal links, sitemap entries, redirects, and hreflang should all reference the canonical form. Check protocol and host consolidation (one of http/https and www/non-www should 301 to the other), trailing-slash consistency, and case sensitivity. Mixed signals force engines to guess, and they don’t always guess your way.

Stage three: rendering and JavaScript

Compare source, rendered, and indexed

For template types that depend on JavaScript, compare the raw HTML, the rendered DOM, and what the URL inspection tool shows as indexed. Content, links, or metadata that exist only post-render arrive late or inconsistently; content that never renders for the bot simply doesn’t exist. Critical content and navigation belong in server-delivered HTML — via SSR, static generation, or hydration strategies that put substance in the initial response.

Watch for render-blocking traps

Lazy-loaded content that requires scrolling or interaction to appear, cookie walls and interstitials that gate the bot, and geo/device cloaking all create a gap between what users and crawlers experience. Render the page as Googlebot and look at what’s actually there — assumptions are the enemy in this stage.

Stage four: architecture and internal linking

Depth and orphan analysis

Crawl your site with a desktop crawler and examine click depth: important pages buried more than three or four clicks from the homepage receive proportionally weaker crawling and authority. Find orphans — indexed or sitemap-listed pages with zero internal links — and either integrate or retire them. The link graph is your statement of what matters; make it match your business priorities.

Navigation, breadcrumbs, and anchor quality

Verify navigation is crawlable HTML, breadcrumbs exist and carry BreadcrumbList markup, and internal anchor text describes destinations. Audit for mass-duplicated boilerplate links crowding out contextual ones, and for broken internal links accumulated through content churn — each is both a user dead-end and wasted crawl.

Pagination and faceted navigation

Category pagination should be crawlable and self-canonicalizing per page; faceted filters (color, size, price) need a deliberate strategy — typically indexing only the facets with real search demand and controlling the combinatorial explosion of the rest. Unmanaged facets are the leading cause of crawl-budget hemorrhage on commerce sites.

Stage five: performance and page experience

Core Web Vitals triage

Review field data (not just lab scores) for the three vitals: loading (LCP), interactivity (INP), and visual stability (CLS). Diagnose by template, not by page — a product-template problem is one fix across thousands of URLs. Usual suspects: oversized unoptimized images, render-blocking scripts, late-loading fonts shifting layout, and third-party tags competing for the main thread.

The practical speed stack

Modern image formats and responsive sizing, compression and caching headers, CDN delivery, deferred non-critical JavaScript, and ruthless third-party tag audits (every marketing pixel is a performance tax — inventory them annually and delete the zombies). Mobile throttled testing is the honest benchmark, because that’s where your marginal visitor lives.

HTTPS and security hygiene

Valid certificate, no mixed-content warnings, HSTS where appropriate, and no security warnings in Search Console. Security flags destroy trust — user and algorithmic — faster than almost any other technical failure.

Stage six: structured data, mobile, and international

Structured data validation

Validate each template’s schema output: correct types, required properties present, values matching visible content, no deprecated types still shipping. Check Search Console’s enhancement reports for errors by type, and confirm your entity markup (Organization, author Persons) stays consistent sitewide.

Mobile parity

With mobile-first indexing, the mobile rendering is the site. Confirm content, internal links, metadata, and structured data parity between desktop and mobile renderings — “we hide that section on mobile” means “that section barely exists” for indexing purposes. Test tap targets, viewport configuration, and intrusive-interstitial compliance.

Hreflang and international targeting

For multilingual or multi-regional sites: hreflang annotations must be bidirectional (every page references all alternates including itself), use correct language-region codes, and point at indexable canonical URLs. Broken hreflang silently feeds users the wrong-language result — a conversion leak invisible in rank reports.

Turning the audit into outcomes

Prioritize by blockage, then by scale

Score findings on two axes: how completely the issue blocks visibility (a noindexed money page outranks every speed tweak) and how many URLs it affects (template-level fixes beat page-level ones). The deliverable is a ranked fix list with effort estimates and named owners — engineering for code, content ops for metadata, infrastructure for servers — not a hundred-page PDF that ages in a drive.

Verify fixes land

Every fix gets a verification step: recrawl the affected URLs, confirm in URL inspection, watch the relevant Search Console report trend. Technical fixes fail silently in deployment more often than anyone admits; the audit isn’t done until the index reflects it.

Monitor between audits

Standing guardrails catch regressions early: Search Console checked weekly, automated crawl diffs after releases, uptime and vitals monitoring, and a pre-launch SEO checklist wired into your deployment process (the cheapest audit is the one the bug never reaches). Technical health also underwrites everything else you do — the content you publish and promote across social channels (on whatever cadence your scheduler, such as SocialBlaze, maintains) only converts attention into rankings when the pipeline behind it is clean.

Run the stages in order, fix upstream before downstream, verify in the index, and automate the recurring checks. Technical SEO rarely wins applause — it just quietly stops you from losing everything the rest of your marketing earns.

For sites facing a migration or replatforming — the events that cause most catastrophic technical regressions — extend this checklist into a before-and-after protocol: crawl and archive the old site completely (URLs, titles, rankings, analytics baselines), map every old URL to its new home before launch, stage the redirects for testing, and re-run the full audit within days of cutover with the archived baseline as your comparison. The majority of “the migration killed our traffic” stories trace to a handful of preventable failures — unmapped URLs, forgotten subdomains, a robots block carried over from staging, or canonicals pointing at the dead domain — every one of which this protocol catches while it’s still cheap. Migrations don’t inherently lose rankings; unaudited migrations do.