The technical faults that turn up most in audits aren’t exotic — they’re a robots.txt line accidentally blocking a section of the site, a page with two conflicting canonical signals, or Core Web Vitals that pass on desktop and fail on the mobile connection most visitors actually use. None of these show up by just reading the page. This is the checklist I actually run before trusting that a site is technically sound — not a copy-paste list, but the specific items that, in practice, are the ones most often silently broken.
Where Each Item Sits in the Pipeline
Technical SEO is a pipeline, not a flat list — a page has to be crawled before it can be indexed, and indexed before ranking factors like speed or schema matter at all. That order is why this checklist is grouped the way it is.
Crawlability & Indexing
- robots.txt isn’t blocking anything it shouldn’t. A single misplaced
Disallowline — often left over from a staging site — can quietly deindex an entire section. Worth checking after every major site migration or theme change, not just once at launch. This matters even more now that AI crawlers read this file too. - XML sitemap exists, is submitted in Search Console, and lists only canonical, indexable URLs. A sitemap padded with redirected, noindexed, or duplicate URLs doesn’t help Google — it wastes crawl attention on pages that were never going to rank.
- Every real page is reachable through internal links, not just the sitemap. A page only a sitemap knows about is a weak signal to Google that it matters; a page with genuine internal links pointing to it is a strong one.
- Search Console’s coverage report is reviewed regularly, not checked once and forgotten. “Excluded” and “Error” pages accumulate quietly, and by the time someone notices organic traffic dropped, the cause is often weeks old.
- Every page has exactly one canonical URL, and it’s self-referencing unless there’s a deliberate reason to point elsewhere.
- Canonical, sitemap, and internal links all agree with each other. A page canonicalized to one URL while the sitemap or internal links point to a different version sends Google contradictory signals — and contradictory signals are usually resolved in Google’s favor, not yours.
- Parameter-based URLs — filters, sort order, tracking tags — aren’t creating separate indexable pages. Left unhandled, an e-commerce category page can spawn dozens of near-duplicate URLs that dilute the ranking signal of the page that actually matters.
- LCP, INP, and CLS pass on real mobile devices, not just desktop. A site that scores well in a desktop browser test can still fail badly on the mid-range Android phone and patchy connection most visitors are actually using — see why site speed is a ranking factor for what’s actually being measured.
- Images are compressed, appropriately sized, and served in a modern format (WebP/AVIF). Oversized images are consistently the single biggest cause of a failing LCP score.
- The site passes mobile-friendliness — no overlapping tap targets, text too small to read without zooming, or content wider than the viewport.
- Content that matters doesn’t depend on JavaScript Google might not render in time. Googlebot does render JavaScript, but on a delay and a budget — critical content injected client-side is a real risk, not a theoretical one, on heavier frameworks.
- HTTPS is enforced sitewide, with no mixed-content warnings from images, scripts, or embeds still loading over HTTP.
- Redirect chains are flattened to a single 301, not stacked three or four deep. Each extra hop adds load time and, at some point, Google simply stops following the chain.
- No broken internal links or orphaned 404s left behind after a page is deleted, renamed, or moved. These accumulate fastest right after a site redesign or content cleanup.
- Schema markup is present where it’s genuinely relevant — FAQ, Article, LocalBusiness, Product — and validates without errors. Schema doesn’t directly boost rankings, but it’s what determines whether a page is even eligible for the rich result (FAQ dropdowns, star ratings) that wins the click.
Canonical Tags & Duplicate Content
Technical SEO is the plumbing. Nobody notices it’s there until it’s broken — but nothing else on the site works if it is.
Site Speed & Core Web Vitals
Mobile & Rendering
Security & Redirects
Structured Data
The One Item Worth Repeating
If only one part of this list gets checked, make it items 1–4. A page with a slow LCP or missing schema still has a real shot at ranking once it’s fixed — those are optimization problems on a page Google can already see. A page blocked in robots.txt, missing from the sitemap, or excluded in Search Console doesn’t have a ranking problem at all; it has an existence problem. No amount of speed optimization or schema markup helps a page Google never crawled in the first place.
Frequently Asked Questions
Do I need a technical SEO checklist if my on-page SEO is already solid?
Yes — they check different things. On-page SEO covers what’s written on a page that’s already crawlable and indexable. Technical SEO covers whether Google can find, crawl, and render that page at all. A perfectly optimized page nobody can crawl never gets the chance to rank.
How often should I run a technical SEO audit?
Quarterly for a stable site, and immediately after any major change — a redesign, a migration, a new plugin, or a hosting switch. Most technical issues are introduced by a change, not by neglect.
What’s the difference between this checklist and the on-page SEO checklist?
This one covers whether a page can be crawled, indexed, and rendered correctly — the infrastructure layer. The on-page checklist covers the content and metadata on a page that’s already passed all of that.
Want a site audited against this exact checklist? Request a free technical review.