Here's a thing that surprises people: AI hasn't made technical SEO less important. It's made it more important.
Search engines now use large language models to help decide what's worth crawling and indexing. AI Overviews and chat-based search assistants pull from a smaller pool of sources than traditional search, which means the pages that get read at all need to be technically sound just to be in the running. If a crawler can't render your page, can't find it, or gets a confusing signal about whether to index it, none of your content quality matters. It never gets read.
A technical SEO audit checklist exists to catch these problems before they quietly drain your traffic. Not the glamorous stuff — nobody brags about fixing their XML sitemap at a conference. But a site with clean technical foundations ranks more of its good content, and a site with broken foundations leaves rankings on the table no matter how good the writing is.
This is a long post, because a real audit is a long process. I've organized it into the order you should actually run it in: crawlability first, then architecture, then on-page technical signals, then performance, then security. Fixing performance on a page Google can't find is wasted effort — so we go in dependency order, not importance order.
One more thing worth saying up front. A technical audit is not a content audit. This checklist won't tell you if your writing is thin or your keyword targeting is off. It answers a narrower, more mechanical question: is anything about your site's plumbing stopping content that deserves to rank from ever getting evaluated? Those are two separate jobs, and running them out of order — say, rewriting a page's content before checking whether the page is even crawlable — wastes effort.
Crawlability & Indexability Checks
Before anything else, you need to know whether search engines can actually reach your pages and whether you're telling them to index the right ones. This is the foundation everything else sits on.
Robots.txt isn't blocking anything important
Open yoursite.com/robots.txt and read it line by line. It's a plain text file, and it's shockingly easy to accidentally disallow an entire section of your site with one careless rule during a migration or a redesign. Check that your CSS and JavaScript files aren't blocked either — Google needs to render your page to evaluate it properly, and blocked resources can prevent that.
Remember that robots.txt controls crawling, not indexing. A page disallowed in robots.txt can still show up in search results as a bare URL with no snippet if other sites link to it. If your goal is to keep a page out of the index entirely, robots.txt is the wrong tool — use a noindex tag instead, and don't combine the two, because a robots.txt block prevents Google from ever seeing the noindex tag on that page.
Your XML sitemap only contains pages you want indexed
Your sitemap should be a clean list of canonical, indexable, 200-status URLs. Nothing else. If it contains redirected URLs, 404s, or pages you've marked noindex, you're sending Google a confused signal about what actually matters on your site. Check your sitemap index for multiple sitemap files if your site is large, and confirm each one is referenced correctly in robots.txt and submitted in Search Console.
Noindex tags are only on pages that should be excluded
Do a sitewide crawl and pull every URL with a noindex directive. Then look at that list with fresh eyes and ask: should all of these really be hidden? It's common to find a noindex tag left over from a staging deployment, or applied broadly by a plugin default that nobody reviewed. A noindex tag on the wrong page is one of the most common ways sites accidentally lose rankings overnight.
Crawl budget is spent on pages that matter
Pull your Crawl Stats report in Google Search Console — it shows how many pages Googlebot crawled per day, what response codes it hit, and what file types it requested. If a meaningful chunk of crawl requests are hitting 404s, that's wasted budget. For larger sites, cross-reference your server logs against your sitemap to see whether Googlebot is spending its time on faceted navigation, session parameters, or internal search result pages instead of the content you actually want ranked.
Check for crawl traps
Faceted navigation, calendar pages, and infinite pagination can generate a near-infinite number of URL variations from a handful of real pages. If your ecommerce filters create a new URL for every combination of size, color, and price range, you may be handing crawlers millions of low-value URLs to chew through. Use robots.txt, parameter handling, or noindex tags to keep these under control.
Site Architecture Checks
Once you know your pages are reachable, the next question is whether your site's structure helps or hurts search engines understanding what matters.
No orphan pages
An orphan page has no internal links pointing to it. If a page isn't linked from anywhere else on your site, crawlers may struggle to find it (or find it only through the sitemap, which is a weaker discovery signal), and it gets essentially no internal link equity. Crawl your site and cross-reference against your full URL list to find pages nothing links to.
Reasonable click depth
Ideally your most important pages are reachable within 3-4 clicks from the homepage. Pages buried 8 or 10 clicks deep get crawled less frequently and rank worse, all else equal, because both users and crawlers treat depth as a signal of importance.
Clean, descriptive URL structure
URLs like /category/product-name-here beat /p?id=48213&cat=7. Keep URLs lowercase, use hyphens rather than underscores, and avoid unnecessary parameters. This isn't just a preference thing — messy parameter-based URLs create duplicate content risk and make crawl patterns harder to reason about.
Internal linking supports your priority pages
Look at which pages get the most internal links pointed at them. If your highest-priority commercial pages have fewer internal links than a random blog post from three years ago, that's a mismatch between what you want to rank and what your site structure is telling search engines to prioritize.
Pagination is implemented correctly
If you use paginated series (page 2, page 3, and so on), make sure each page is self-canonical (not all pointing back to page 1, which used to be a common but incorrect pattern) and that they're crawlable and indexable if they contain unique content worth surfacing.
On-Page Technical Checks
This is where a lot of subtle, high-impact mistakes live — the kind of thing that looks fine to a human visitor but sends a bad signal to a crawler.
Canonical tags point to the right version
Every page should have a canonical tag, and in most cases it should be self-referencing (pointing to itself). Check for canonical chains, where page A canonicalizes to page B, which canonicalizes to page C — search engines may not follow the whole chain. Also check that your canonical tags aren't accidentally pointing to a different page entirely due to a templating bug, which happens more often than you'd think, especially after a CMS migration.
Canonical and noindex are never combined on the same page
If a page has both a canonical tag pointing elsewhere and a noindex directive, you're sending a contradictory signal. Google has said it will generally prioritize the noindex and drop the page from the index, losing whatever link equity the canonical was trying to consolidate. Pick one goal — consolidate with canonical, or remove with noindex — not both.
Hreflang tags are reciprocal and correctly coded
If you run a multilingual or multi-regional site, every hreflang annotation needs a matching return tag. If your English page points to your German page, the German page must point back to the English page. Broken reciprocity is one of the most common hreflang errors, and when Google finds malformed or non-reciprocal hreflang, it ignores the whole cluster and falls back to its own language detection — which gets it wrong more often than you'd like. Double-check your region codes too; it's en-GB, not en-UK, and this typo shows up constantly.
Canonical and hreflang don't contradict each other
If your Spanish page's canonical tag points to your English page, you've just told Google the Spanish page is a duplicate — which undermines the entire point of having a Spanish version. Canonicals on localized pages should point to that locale's own preferred URL, not a "master" version.
Structured data validates and matches visible content
Run your key templates through Google's Rich Results Test. Beyond just passing validation, check that every claim in your schema markup is actually visible somewhere on the page. Markup that describes content the page doesn't show is called schema drift, and at best it just doesn't help; at worst it risks a manual action for structured data that misrepresents the page.
Title tags and meta descriptions are unique per page
Duplicate titles and descriptions across many pages is a signal of thin or templated content, and it wastes an opportunity to differentiate each page in the SERP. Pull a sitewide export and sort for duplicates.
Performance Checks
Speed and usability aren't secondary concerns anymore — they're baked into how Google measures page experience, and users bounce from slow pages regardless of what Google thinks.
Core Web Vitals pass at the 75th percentile, using field data
Check the Core Web Vitals report in Search Console, which is built on real Chrome User Experience Report (CrUX) data, not lab scores. The three metrics: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. A Lighthouse score of 95 on your laptop means very little if real users on mid-range phones over 4G are seeing something worse — always check field data over lab data before declaring victory.
LCP bottlenecks are addressed at the template level
The most common fix is the hero image: convert to a modern format like WebP, set explicit width and height attributes, and consider fetchpriority="high" for the above-the-fold image. The other common culprit is render-blocking CSS or fonts loading in the head — split critical CSS out or defer non-critical stylesheets.
Layout shift is controlled
Set explicit dimensions on every image, embed, and ad slot so the browser reserves space before content loads. Late-loading web fonts and dynamically injected content (cookie banners, promo bars) are common causes of shift that show up after initial load and get missed in a quick manual check.
Mobile usability has no unresolved issues
Check the Mobile Usability report in Search Console for things like text too small to read, clickable elements too close together, and content wider than the screen. With mobile-first indexing, Google is evaluating your mobile experience as the primary version of your site, not a secondary one.
Server response time (TTFB) is reasonable
A slow server response time drags down every other performance metric downstream of it, since nothing on the page can start rendering until the server responds. If TTFB is consistently above 600-800ms, look at your hosting, caching layer, and database query performance before touching anything else on the page.
JavaScript rendering doesn't hide content or links
If critical content or internal links only appear after client-side JavaScript executes, some crawlers may miss them or process them with a delay. Test with Google's URL Inspection tool to see the rendered HTML as Googlebot sees it, and compare it against what a user sees in a browser.
Security & Accessibility Checks
These get lumped into "not really SEO" by a lot of people, but a security problem or an accessibility failure both directly affect whether people find and trust your site.
HTTPS is enforced sitewide with no mixed content
Every page should serve over HTTPS, with HTTP requests redirecting properly, and no mixed content warnings from resources loaded insecurely on an otherwise secure page. Browsers now flag non-HTTPS pages as "not secure," which is a trust signal that affects both users and, indirectly, engagement metrics.
No security warnings in Search Console
Check the Security Issues report for flags like malware, hacked content, or deceptive pages. These can trigger warning interstitials in Chrome that tank your traffic overnight, and they're sometimes the result of a compromised plugin nobody noticed.
Basic accessibility standards are met
Alt text on meaningful images, sufficient color contrast, keyboard-navigable menus, and proper heading hierarchy (one H1 per page, headings in logical order) all matter for accessibility and overlap significantly with what search engines use to understand your content structure.
AI crawlers can access your content
This one's new territory for a lot of teams. Check whether your robots.txt is blocking crawlers like GPTBot, ClaudeBot, or Google-Extended. Unless you have a specific, deliberate reason to keep your content out of AI training or retrieval — some publishers do, for licensing reasons — blocking these by default just removes you from a growing discovery channel. If being cited by AI search assistants matters to your traffic strategy, this is worth checking explicitly rather than assuming your existing robots.txt handles it correctly, since many of these directives were added defensively without much thought.
The Full Checklist
Here's the complete list, organized by section, for you to work through or hand to whoever's running the audit.
Crawlability & indexability
- Robots.txt doesn't block important pages, CSS, or JS
- XML sitemap contains only 200-status, canonical, indexable URLs
- Sitemap is submitted and error-free in Search Console
- Noindex tags are only on pages meant to be excluded
- No robots.txt block + noindex combination on the same page
- Crawl Stats report shows healthy response code distribution
- Server logs show crawl budget going to priority pages
- Faceted navigation and parameter URLs are controlled
- No crawl traps from infinite pagination or calendars
- 404 and soft-404 pages are cleaned up or redirected
Site architecture 11. No orphan pages with zero internal links 12. Priority pages are within 3-4 clicks of the homepage 13. URLs are clean, lowercase, and descriptive 14. Internal linking prioritizes commercially important pages 15. Paginated series are self-canonical and crawlable 16. Breadcrumb navigation is implemented and marked up 17. Site search results pages are noindexed if low-value
On-page technical 18. Every page has a canonical tag, ideally self-referencing 19. No canonical chains longer than one hop 20. Canonical and noindex are never combined 21. Hreflang tags are reciprocal across all variants 22. Hreflang region and language codes are valid ISO codes 23. Canonicals on localized pages point to that locale's URL 24. Structured data validates in the Rich Results Test 25. Structured data matches visible on-page content 26. Title tags are unique across the site 27. Meta descriptions are unique and non-boilerplate 28. Heading hierarchy is logical, one H1 per page
Performance 29. LCP passes at 2.5s or better using field data 30. INP passes at 200ms or better using field data 31. CLS passes at 0.1 or better using field data 32. Hero images are optimized and sized explicitly 33. Render-blocking CSS/fonts are minimized 34. Mobile Usability report shows no unresolved issues 35. Server response time (TTFB) is under 600-800ms 36. Critical content isn't hidden behind client-side JS rendering
Security & accessibility 37. HTTPS is enforced sitewide with no mixed content 38. No active Security Issues flagged in Search Console 39. Images have descriptive alt text 40. Color contrast meets accessibility standards 41. Site is fully keyboard-navigable 42. SSL certificate is valid and not near expiration 43. AI crawlers (GPTBot, ClaudeBot, Google-Extended) aren't blocked unintentionally
That's 43 checks. Some sites will need more depth in a specific area — international sites need deeper hreflang scrutiny, ecommerce sites need more attention on faceted navigation — but this covers the core of what every site should check on a recurring basis.
A Prioritization Framework
Finding 42 issues is easy. Knowing which ones to fix first is the actual skill.
Start with anything that blocks crawling or indexing entirely. If Googlebot can't reach a page, nothing else about that page matters, so a robots.txt misconfiguration or an accidental sitewide noindex outranks everything else on this list. Fix these first, always, no exceptions.
Next, fix anything affecting a large number of pages through a shared template. A canonical bug in your product page template affects every product on your site at once. That's a bigger lever than a one-off fix on a single landing page, even if the single page gets more traffic today.
Then move to Core Web Vitals failures on your highest-traffic templates. Speed fixes compound — improving LCP on your blog template helps every post you've ever published and every one you publish going forward.
After that, clean up structured data and duplicate metadata issues, since these are typically quick, low-risk fixes with a clear payoff in SERP appearance.
Security issues jump the queue regardless of where they'd otherwise rank, because they can trigger warning interstitials that block traffic entirely, not just reduce it.
Everything else — accessibility polish, minor architecture cleanup, orphan pages with low individual value — gets worked through on an ongoing basis rather than in a single sprint. A technical audit isn't a one-time event. Sites drift out of compliance constantly through new templates, plugin updates, and content additions, which is why an increasing number of teams run these checks on a recurring, automated cadence rather than once a year.
FAQ
How often should I run a technical SEO audit?
A full audit at least twice a year, with lighter automated monitoring running continuously in between for the highest-risk items — crawl errors, noindex changes, and Core Web Vitals regressions. Sites that publish frequently or ship code changes often should monitor more continuously, since a single bad deploy can introduce a sitewide issue overnight.
What tools do I need to run this checklist?
The core toolkit is Google Search Console for crawl stats, coverage, and Core Web Vitals field data; a crawler like Screaming Frog for a full-site technical crawl, redirect chains, and canonical/hreflang auditing; PageSpeed Insights or Lighthouse for performance diagnostics; and the Rich Results Test for structured data validation. For large sites, server log analysis adds a layer that Search Console alone can't show you.
Does technical SEO still matter with AI search and AI Overviews?
Yes, arguably more than before. AI-driven search surfaces pull from a smaller set of sources than traditional search results, and they still depend on crawling and rendering your content correctly first. A technically broken page is invisible to an AI answer engine just as it's invisible to classic search — the content quality never even gets evaluated if the crawler can't reach or parse the page.
Should I fix everything on this checklist before doing anything else?
No. Fix crawlability and indexing blockers first, since those affect whether a page can be evaluated at all. After that, prioritize by how many pages a fix touches and how much traffic those pages carry, rather than working through the list in order.
How is a technical audit different from a content audit?
A technical audit looks at infrastructure — crawling, indexing, speed, security, structured data. A content audit looks at quality, relevance, and topical coverage — thin content, keyword targeting, content gaps versus competitors. They're separate processes, and technical issues should generally be resolved first, since they can mask or distort what a content audit finds if pages aren't even being crawled properly.
Can I run this audit myself, or do I need a developer?
Most of the diagnostic work — checking Search Console, running a crawler, reviewing the Rich Results Test — doesn't require code. Implementing the fixes often does, especially anything involving templates, server configuration, canonical logic, or performance optimization. Plan to hand off a prioritized list to a developer rather than trying to fix template-level issues manually one page at a time.