The Technical SEO Audit Checklist We Use on Every Client Site

A technical audit that produces a 200-item spreadsheet isn't useful to anyone — it just gets ignored. This documents the order we actually check things in: crawlability and indexation first, since nothing else matters if pages aren't indexed; Core Web Vitals second, because speed and stability affect both rankings and conversion; structured data and internal linking third; and migration-specific checks only when relevant. The goal is a short list of fixes with real ranking impact, not an audit for the sake of an audit.

Step 1: Crawlability and Indexation

Nothing downstream matters if a page can't be crawled or indexed, which is why this comes first every time. We check:

  • Robots.txt directives — confirming nothing important is accidentally disallowed, especially after a redesign or platform migration.
  • Noindex tags — cross-checked against a full crawl, since a noindex tag left on a page after launch is one of the most common accidental-deindexing causes we see.
  • Canonical tag accuracy — every canonical should point to the version of the URL that's actually meant to rank, and match how the domain itself resolves at the server level, not just what the tag claims.
  • XML sitemap accuracy — every indexable URL present, no noindex or redirected URLs included, and the sitemap actually referenced in robots.txt.
  • Orphaned pages — pages with no internal links pointing to them, found only through a sitemap or direct URL, which crawlers deprioritize.

Step 2: Core Web Vitals Thresholds That Actually Correlate With Impact

Speed and stability affect both how a page ranks and how well it converts once a visitor lands on it. We benchmark against Google's published thresholds — Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200ms, Cumulative Layout Shift under 0.1 — but the priority is always the pages carrying the most organic traffic or the most commercial intent, not every page on the site equally. A slow blog post costs less than a slow service page a prospect is deciding on.

Step 3: Structured Data and Schema Markup

Schema markup doesn't guarantee a ranking boost on its own, but it does make eligibility for rich results and AI-generated answers possible in the first place. We prioritize schema types that map directly to how the business gets found — Organization and LocalBusiness for entity recognition, BreadcrumbList for navigation context, FAQPage and Article for content that answers direct questions — and validate every implementation against Google's structured data testing tools rather than assuming the markup is correct because it's present.

Step 4: Site Architecture and Internal Linking

Site architecture problems are quiet — they don't throw errors, they just quietly cap how much authority flows to the pages that need it. Common red flags include:

  • Important pages buried too deep — more than three or four clicks from the homepage, which both crawlers and users deprioritize.
  • Thin or duplicate category structures — especially common on e-commerce and multi-location sites where templates get reused without enough unique content.
  • Weak internal linking to priority pages — a page with strong content but almost no internal links pointing to it rarely outranks a well-linked competitor, regardless of content quality.
  • Inconsistent URL structure — mixed patterns across sections of the site that make the architecture harder for both crawlers and users to predict.

Step 5: Migration-Specific Checks

When the audit is tied to a migration — a redesign, a domain change, or a platform switch — we add a dedicated pass: a full 301 redirect map from every old URL to its new equivalent, confirmation that canonical tags on the new site match the new URL structure rather than leftover references to the old one, and a post-launch crawl comparing indexed URL counts before and after. Migrations are the single most common source of sudden, sitewide indexing problems, and almost all of them trace back to a gap in this step.

Turning Findings Into a Fix List a Developer Can Act On

An audit that ends at a list of issues hasn't finished the job. Each finding needs three things attached before it goes to a developer: the specific page or template affected, the estimated impact if fixed, and a plain-language description of the fix — not just a tool's raw error message. Sorted by impact against effort, this turns a 200-item report into a short, actionable list, which is the difference between an audit that gets acted on and one that gets filed away. We coordinate this handoff directly through web dev coordination when the client doesn't have in-house development capacity.

Frequently Asked Questions

Have a site that needs this today? Our technical SEO service runs this exact audit, and we can coordinate the fixes too through web dev coordination.

Book a Strategy Call ← Back to Blog