Technical SEO Audit Checklist

This is a working checklist, not a tutorial. Each item below is something to check, in a specific order, with a short note on what it means and where the deeper explanation lives if a check fails. The order matters: crawlability problems make everything downstream unreliable to diagnose, so start there rather than jumping straight to performance metrics because they’re easier to run a tool against.

How to Use This Checklist

Work through the sections in order: crawlability, then indexability, then URL hygiene, then performance, then structured data. A site failing crawlability checks will show confusing, inconsistent results on every check after it, since Google can’t evaluate content it can’t reliably reach. Re-run the full sequence, not just the sections that seemed relevant, since problems in one area often explain symptoms that show up in another.

Running through this checklist requires three things: access to the site’s Search Console property (for the Page Indexing report, Crawl Stats, Core Web Vitals, and URL Inspection), a third-party crawler tool capable of following redirects and reporting status codes (Screaming Frog and similar tools cover this), and, for JavaScript-heavy sites, a way to compare raw HTML against the fully rendered page, which URL Inspection’s live test also provides. Nothing on this list requires paid tooling beyond what’s already built into Search Console, though a dedicated crawler makes the URL hygiene section considerably faster on any site larger than a few dozen pages.

Crawlability Checks

• Robots.txt is reachable and valid. Request /robots.txt directly and confirm it returns the expected content, not a 404 or 5xx error. Check for an accidental sitewide block (a stray Disallow: /) and confirm the file is under Google’s 500 KiB size cap; a file that’s grown too large gets truncated, and anything past that point, including a Sitemap line placed near the bottom, silently stops being read. Full directive syntax, wildcard behavior, and precedence rules are covered in this site’s dedicated robots.txt guide.
• XML sitemap is submitted and error-free. Confirm the sitemap (or sitemap index) is submitted in Search Console and shows a successful, recent fetch. Verify it lists only canonical, indexable URLs (no redirects, no robots.txt-blocked URLs, no noindex’d pages), and stays under the 50,000 URL / 50MB per-file limit. Full structure and troubleshooting guidance is covered in this site’s dedicated sitemap guide.
• Crawl stats are healthy. In Search Console’s Crawl Stats report, check for a rising trend in server errors, a climbing average response time, or a crawl volume that’s flat despite site growth. This mostly matters for large or fast-changing sites; the full framework for deciding whether crawl budget is a real constraint for a given site is covered in this site’s dedicated crawl budget guide.

Indexability Checks

• Page Indexing report is clean, or at least understood. Review each exclusion-reason category (Discovered, Crawled but not indexed, duplicate-canonical issues, soft 404s, blocked URLs, server errors, redirect issues) and confirm the counts and trends make sense for the site. A climbing trend in any single category is worth investigating before it grows further. The full exclusion-reason taxonomy and fixes for each category are covered in this site’s dedicated indexing-issues guide.
• Spot-check key URLs in URL Inspection. For the site’s most important pages, run a live test (not just the cached indexed-version view) to confirm they’re indexable right now, not just as of the last crawl. This catches recent regressions that haven’t shown up in the Page Indexing report yet.
• Mobile-first rendering parity. Confirm the mobile version of key pages carries the same content, structured data, and internal links as any desktop version still in use; Google has crawled and indexed based on the mobile version of virtually all sites since completing its migration to mobile-first indexing in mid-2024, so a mobile version missing content that only exists on desktop is effectively invisible to Google. (Google began this rollout in March 2018 and confirmed the migration finished, for the small remaining set of sites still on desktop crawling, on July 5, 2024; if a source states this happened “since March 2021,” that figure is wrong and should be corrected.)
• JavaScript-dependent content is verified in the rendered view. For any page relying on client-side rendering for meaningful content, compare the raw HTML response against a live-rendered test. Content that only appears after rendering is subject to a separate, sometimes-delayed processing pass, and a site owner should know which of their pages carry that dependency rather than discovering it during a traffic investigation.

URL Hygiene Checks

• No orphaned redirect chains. Run a crawler tool and check for any URL that hops through more than one redirect before reaching its final destination. Consolidate every chain found to a single hop, source directly to final destination. Status-code selection (301 vs. 302 vs. 307 vs. 308) and full chain-detection workflow are covered in this site’s dedicated redirects guide.
• No unmanaged 404s with existing backlinks or internal links. Check server logs and a broken-link crawl for 404s that are still receiving real traffic or that the site itself still links to internally. A 404 with no reasonable live equivalent is fine left as a 404; a 404 that has a genuinely relevant destination should get a targeted redirect. Mass-redirecting every dead URL to the homepage is a pattern worth avoiding, not a shortcut. The full decision framework is covered in this site’s dedicated 404 management guide.
• Canonical tags are correct and consistent. Confirm every duplicate or near-duplicate URL cluster has an explicit, correctly-pointed canonical tag, and check for cases where Google’s selected canonical disagrees with the one declared in the page’s markup (visible in URL Inspection). Canonical mechanics across platforms, parameters, and pagination are their own topic, covered separately.
• HTTPS is fully and consistently enforced. Confirm every HTTP URL redirects to its HTTPS equivalent with a single-hop 301, that internal links and resource references (images, scripts, stylesheets) point to HTTPS URLs directly rather than relying on a redirect to get there, and that no mixed-content warnings appear on key pages. The full migration mechanics are their own topic, covered separately.

Performance Checks

• Core Web Vitals pass at the 75th percentile. Check the Core Web Vitals report in Search Console and confirm Largest Contentful Paint is under 2.5 seconds, Interaction to Next Paint is under 200 milliseconds, and Cumulative Layout Shift is under 0.1, each measured across the 75th percentile of real page loads, Google’s official thresholds for a “good” rating. The mechanics of diagnosing and fixing each metric are a substantial topic on their own, covered separately; this checklist item is a pass/fail gate, not a diagnostic.
• Mobile usability has no unresolved issues, including tap targets that meet the minimum 48-by-48 CSS pixel size Google’s mobile-friendliness testing checks for.

Structured Data Checks

• Structured data validates without errors. Run affected page types through a structured data testing tool and confirm required fields are present and correctly typed.
• No manual-action-triggering markup. Confirm structured data accurately describes visible page content; markup that misrepresents what’s actually on the page (fabricated review ratings, for instance) risks a manual action, separate from any indexing issue. Schema type selection, implementation details, and troubleshooting are their own topic, covered separately.

When to Re-Run This Audit

There’s no single official cadence Google publishes for how often a technical audit should run, so treat cadence as event-driven rather than calendar-driven: after any site migration or URL structure change, after a CMS or major platform change, after a redesign that touches templates site-wide, and any time organic traffic drops in a way that doesn’t correlate with a known algorithm update. For a stable site with no major changes, a lighter periodic pass (quarterly is a reasonable, though not Google-mandated, default) catches drift, like slowly accumulating redirect chains or a robots.txt file that’s grown past its intended scope, before it becomes a bigger problem.

A note on what this checklist deliberately leaves out: invented benchmark statistics like a “typical percentage of crawled pages that get indexed” or an “average number of internal links per page” show up often in technical SEO content without a real, citable Google source behind them. Nothing in this checklist depends on numbers like that; every threshold above (the sitemap limit, the robots.txt size cap, the Core Web Vitals thresholds, the tap-target minimum) is a number Google has actually published and this checklist cites directly rather than repeats secondhand.