Technical SEO Audit Checklist: 60 Ranking Moving Checks

Most technical SEO problems aren't dramatic. They're a robots.txt line nobody updated after a staging migration, a canonical pointing at the wrong URL variant, a Largest Contentful Paint sitting just over the threshold, a sitemap referencing pages that started 404-ing six months ago. Individually small; collectively, the reason traffic stops growing.

This is the checklist to work through to audit a site's technical health end to end.

The workflow is organized based on what causes blocks. Crawlability is addressed first. After all, if Google cannot reach your pages, nothing else matters. The next step is indexing, followed by the structural and on-page technical layer. Then we look at speed, security, mobile, and AI-search readiness. The process concludes with verification work in Google Search Console and server logs. Each item names the specific check, the tool to run it with, the failure mode that's worth knowing about, and the fix.

A few notes before the checks. First, the broader concept, what an audit is, why it matters, and how the different audit types relate, lives in our SEO Audit wiki entry; this article is the procedural companion to that. 

1. Crawlability and indexation

If Googlebot can't crawl or chooses not to index a page, nothing else on this list matters for that page. This is where audits start, and where the highest-impact fixes usually live. Concepts here are covered in detail in the wiki: crawler, crawl budget, indexing, canonical tag, noindex, orphan pages.

1.1 robots.txt is intentional, not accidental

Check: Fetch /robots.txt directly and read every Disallow: line. Cross-reference against pages you actually want indexed.

Tool: A browser, plus Search Console's URL Inspection tool for spot-checking specific URLs.

Common failure mode: Staging-environment directives surviving a migration to production. Disallow: / in production robots.txt is the high-stakes version; Disallow: /blog/ or Disallow: /products/ for entire content silos is the version that's easier to miss because the homepage still ranks fine.

Fix: Remove or narrow the rule, then submit the URL in Search Console's URL Inspection tool to confirm Googlebot now sees it as crawlable.

1.2 XML sitemap exists, is referenced, and is current

Check: Confirm a sitemap exists at the expected path (typically /sitemap.xml or a sitemap index). Verify it's referenced in robots.txt via Sitemap:. Confirm it's submitted in Search Console. Spot-check that listed URLs actually exist and return 200.

Tool: Search Console's Sitemaps report; a crawler like Screaming Frog in list mode pointed at the sitemap to validate URL status.

Common failure mode: Sitemaps that list pages which since 404'd, or that exclude entire post types because the CMS plugin generating them wasn't reconfigured after a content model change.

Fix: Regenerate the sitemap, ensure it includes only canonical, indexable, 200-responding URLs, and resubmit in Search Console.

1.3 No accidental noindex on important pages

Check: Crawl the site and filter for any URL with noindex in the meta robots tag or the X-Robots-Tag HTTP header. Compare that list to your list of pages that should rank.

Tool: Screaming Frog (Indexability column), or any crawler that surfaces meta robots and X-Robots-Tag values.

Common failure mode: A blanket noindex applied during a staging deploy that survives into production, or a CMS field set to "don't index" on a template that controls a whole content section. The X-Robots-Tag version is the silent one because it's invisible in HTML view-source, only an HTTP response inspection finds it.

Fix: Remove the tag at the template, plugin, or server-config level, then request reindexing for the affected URLs via Search Console.

1.4 Canonical tags are self-referencing or correctly cross-referencing

Check: Every indexable page should have a canonical tag. For most pages, it should point at itself (self-canonical). Where it points elsewhere, that target should be the correct preferred URL.

Tool: Crawl with canonical reporting enabled. In Search Console, check the Pages report for "Alternate page with proper canonical tag" and "Duplicate without user-selected canonical" buckets.

Common failure mode: Canonicals that point at the homepage from every page (a classic bug), or canonicals that point at the non-preferred variant (e.g. canonicalising the HTTPS version to the HTTP version after an SSL migration).

Fix: Correct the canonical at the template level. Verify with Search Console's URL Inspection, the "Google-selected canonical" should match your "User-declared canonical."

1.5 Soft 404s aren't masking dead pages

Check: Look for pages that return HTTP 200 but show empty results, "no products found," or other failure-state content. Google's own definition covers this in detail.

Tool: Search Console's Pages report, the "Soft 404" issue type lists Google's flagged cases. For proactive detection, crawl for thin pages (low word count, missing main content blocks) and review.

Common failure mode: Ecommerce out-of-stock pages, expired listings, empty search results pages that return 200 instead of either 404 or a meaningful "alternative products" experience.

Fix: Either return a proper 404/410 for genuinely gone content, redirect (301) to a relevant replacement, or rebuild the page to have real content that justifies the 200.

1.6 No orphan pages with no internal links

Check: Compare the list of URLs in your sitemap (or your CMS export) to the list of URLs reachable via internal links from a full site crawl. Anything in the first list and not the second is an orphan page.

Tool: Screaming Frog has a dedicated orphan URLs report when you combine crawl data with sitemap and analytics data.

Common failure mode: Older blog posts no longer linked from category or related-post modules; landing pages built for campaigns that ended; pages migrated from old CMS structures that didn't get added back into navigation.

Fix: Either add internal links from relevant existing pages, or if the orphan isn't worth keeping, redirect or 410 it.

1.7 JavaScript-rendered content is actually visible to crawlers

Check: For any page that relies on client-side rendering (React, Vue, Angular, or any framework that hydrates content after page load), compare the raw HTML response to what Googlebot sees after rendering.

Tool: Search Console's URL Inspection → "Test Live URL" → "View Tested Page" → "HTML" tab. Compare against view-source. Google's JavaScript SEO documentation covers what to expect.

Common failure mode: Product descriptions, prices, or category content that's empty in the raw HTML and only populates after a fetch call. Search engines may render it, but rendering is queued and inconsistent; AI crawlers in particular often don't execute JS at all.

Fix: Move critical content into the initial server response via SSR (server-side rendering) or static generation. For interactive elements, progressive enhancement is the safer pattern.

1.8 Faceted navigation doesn't generate infinite duplicate URLs

Check: On any site with filters or facets (most ecommerce, many SaaS pricing pages, job boards), see what URL variants get generated when filters are applied. Confirm Googlebot isn't being invited to crawl every permutation.

Tool: Manual exploration of category pages; cross-check by searching site:yourdomain.com inurl:? in Google to see what's been indexed.

Common failure mode: A filterable product listing where every combination of filters creates a new crawlable URL with thin content, eating crawl budget. Faceted nav is one of the more common crawl budget sinks on large sites.

Fix: Use a combination of robots.txt Disallow patterns, nofollow on filter links you don't want crawled, canonical tags pointing back to the unfiltered category, and parameter handling in Search Console. Pick the combination that matches your CMS.

1.9 Important pages are indexed

Check: Pull your list of "money pages" (homepage, top category pages, top blog posts, key landing pages) and confirm each is indexed.

Tool: Search Console URL Inspection for individual URLs. For bulk, the Pages report's "Indexed" tab.

Common failure mode: An important page sitting in "Crawled, currently not indexed" or "Discovered, currently not indexed." Google has decided the page isn't worth indexing, usually because of perceived low value, duplicate content, or thin content relative to existing indexed pages.

Fix: This isn't a "request reindexing" fix, that won't change Google's quality assessment. The fix is to improve the page substantially: more unique content, better internal links pointing to it, removal of near-duplicates competing with it.

2. Site architecture and internal linking

7 checks

How pages connect to each other tells search engines which pages matter and how topics relate. Concepts: internal links, anchor text, breadcrumb, dead link.

2.1 Click depth from homepage is reasonable

Check: Important pages should be reachable within three clicks from the homepage. Pages buried deeper get crawled less often and tend to rank worse.

Tool: Screaming Frog's "Crawl Depth" report, or any crawler with depth visualisation.

Common failure mode: Money pages sitting at click depth 5+ because navigation prioritises recency over importance, or because category structures nest too deeply.

Fix: Add direct links from the homepage, primary navigation, or hub pages. Restructure navigation if multiple important pages are too deep.

2.2 No internal links pointing at broken pages

Check: Every internal link should resolve to a 200-status page. Internal links to 404s are wasted, for users and for crawlers.

Tool: Full crawl with status-code reporting. Filter for any internal link with a non-200 destination.

Common failure mode: Blog posts referencing old URLs that were since restructured; navigation items linking to discontinued products; hardcoded footer links to defunct pages.

Fix: Update the links to point at the current URL, remove them, or ensure the destination 301-redirects to the right place.

2.3 Internal anchor text is descriptive

Check: Internal links should use anchor text that describes the destination. "Click here," "learn more," "read more" pass weaker signals.

Tool: Screaming Frog's "Inlinks" report shows anchor text per destination URL.

Common failure mode: "Read more" links from blog post previews, "click here" calls-to-action everywhere, generic anchor text from related-post modules. Our SEO Page Checker flags generic anchor text per URL.

Fix: Update template-level link text where possible; rewrite individual links where the template isn't the issue. Keep anchor text natural, no need to over-optimise with exact-match keywords.

2.4 Breadcrumb navigation is implemented and marked up

Check: Pages have visible breadcrumb navigation and the breadcrumbs are marked up with BreadcrumbList structured data.

Tool: Google's Rich Results Test validates the schema.

Common failure mode: Breadcrumbs that look right visually but use incorrect schema, or that show a hierarchy that doesn't match the URL structure.

Fix: Implement BreadcrumbList JSON-LD, validate with Rich Results Test, and check that the breadcrumb hierarchy actually mirrors the site's information architecture.

2.5 No redirect chains longer than one hop

Check: Every redirect should go directly to its final destination. Chains of two or more redirects waste crawl budget and slow page loads.

Tool: Screaming Frog's "Redirect Chains" report; Search Console's Page Indexing report sometimes flags this too.

Common failure mode: Old URLs that have been migrated multiple times, URL A → URL B (from one migration) → URL C (from a later migration), without updating the original A→C shortcut.

Fix: Update redirects so the original URL goes straight to the final destination. Update internal links to point at the final URL too, so the redirect isn't needed at all.

2.6 Pagination is correctly implemented

Check: Paginated content (category pages, blog index, search results) should be discoverable. Each paginated URL should be a unique URL, not a fragment.

Tool: Manual inspection of paginated sections. Google's pagination guidance covers patterns.

Common failure mode: Infinite scroll that loads new content via AJAX without updating the URL, so additional content is invisible to crawlers. Or "Load more" buttons with no underlying paginated URLs.

Fix: Ensure each paginated state has its own crawlable URL (e.g. /category/page/2/). Infinite scroll should be paired with crawlable paginated URLs as a fallback.

2.7 No excessive outgoing internal links per page

Check: Pages with several hundred internal links dilute the value each link passes. Mega-menus are the usual culprit.

Tool: Crawler "outlinks per page" report.

Common failure mode: A 400-item mega-menu on every page, meaning every page in the site links to 400+ other pages, regardless of relevance.

Fix: Reduce the menu, use contextual links instead, or move secondary navigation behind a click. The number isn't a hard limit; the question is whether the links are useful enough to justify their presence.

3. On-page technical elements

These overlap with on-page SEO but get verified during a technical audit because they're structural rather than editorial. Concepts: meta title, meta description, heading tag, hreflang, JSON-LD, Open Graph.

Most of the checks in this section can be run on a single URL with our SEO Page Checker in about ten seconds, useful for spot-checking specific pages during the audit. For site-wide passes, a full crawl is the right tool.

3.1 Title tags are present, unique, and within length budget

Check: Every page has a title tag. No duplicates across important pages. Length should fit within roughly 580px on desktop and 540px on mobile, pixel width matters more than character count, because some characters are wider than others.

Tool: Crawler with title-length reporting; single URLs in the Seonio SEO Page Checker (which reports pixel widths against desktop and mobile targets).

Common failure mode: CMS-generated titles like "Untitled" on certain templates; duplicate titles across paginated pages or filtered category variants; titles cut off at the ellipsis on mobile because they only fit desktop width budgets. Industry studies suggest title tag issues are widespread, a frequently cited Raven Tools analysis found around 22% of pages have duplicate titles.

Fix: Write unique titles for every important page. Lead with the keyword, keep brand at the end, fit within mobile pixel budget.

3.2 Meta descriptions are present and within length budget

Check: Each important page has a meta description that fits within roughly 920px desktop / 680px mobile. Google will often rewrite them, but a present, on-target description still influences click-through and gives you control when Google does use yours.

Tool: Crawler or SEO Page Checker. The same Raven Tools study reported around 34% of pages had no meta description at all, an unusually easy fix on most sites.

Common failure mode: CMS field left blank, meaning Google generates the description from on-page text (often poorly). Or descriptions copy-pasted across multiple pages.

Fix: Write unique descriptions for top pages; for tail pages, a templated description filling in dynamic fields (product name, category) is acceptable.

3.3 Exactly one H1 per page, matching the page topic

Check: Each page has one H1, and it describes what the page is about. Subheadings use H2–H6 in logical order without skipping levels.

Tool: Crawler or SEO Page Checker (which flags multiple H1s, empty H1s, and level skips).

Common failure mode: Site logo wrapped in an H1 on every page, so the H1 is "Brand Name" instead of the page topic; multiple H1s from theme components; empty H1s used purely for styling.

Fix: Restructure template so the H1 is the page title proper. Demote redundant H1s to H2 or H3 as appropriate.

3.4 hreflang annotations are valid and reciprocal (multilingual/multi-region sites)

Check: For sites with multiple language or regional variants, every page in the cluster references every other, including itself, with the correct language and region codes. There's a self-referencing tag. There's an x-default pointing somewhere sensible.

Tool: Search Console's International Targeting report (legacy but still useful), Aleyda Solís's hreflang generator, or any crawler with hreflang validation.

Common failure mode: Non-reciprocal hreflang (page A links to B with hreflang but B doesn't link back), wrong region codes (using en-UK instead of en-GB, only GB is valid per ISO 3166-1 alpha-2), missing self-referencing tag.

Fix: Generate hreflang from a single source of truth (a CMS field or sitemap-based approach), validate after deployment.

3.5 Canonical URL variants resolve consistently

Check: One canonical URL variant per page across these dimensions: www vs non-www, HTTP vs HTTPS, trailing slash vs no trailing slash, uppercase vs lowercase. Every other variant should redirect to the canonical one.

Tool: Manual tests on a handful of URLs (try all four variants of each); crawler verification across the site.

Common failure mode: Both https://example.com/page and https://example.com/page/ returning 200 with identical content, creating duplicate-content competition with themselves.

Fix: Configure server-level redirects (Apache .htaccess, Nginx config, or CDN-level rules) to enforce one variant.

3.6 Structured data is valid and matches visible content

Check: Any schema markup on the page validates without errors. The data in the schema matches what's actually visible on the page (no inflated review counts, no prices that differ from displayed prices).

Tool: Google's Rich Results Test for validation and eligibility; Schema.org's validator for raw schema checks. The Seonio SEO Page Checker flags presence and detects invalid JSON-LD blocks.

Common failure mode: Product schema with stale prices because the schema is hardcoded in a template rather than pulled from the same source as the displayed price; FAQ schema where the schema includes questions not visible on the page.

Fix: Generate schema from the same data source as the visible content. Validate every schema type currently in use. Remove schema for content types that no longer apply.

3.7 Open Graph and X (Twitter) Card tags are complete

Check: Each important page has og:title, og:description, og:image, og:type, and an X card variant. Images respect the 1.91:1 aspect ratio target for OG.

Tool: SEO Page Checker, or Facebook's Sharing Debugger and X's Card Validator (where still available).

Common failure mode: Missing OG image, leading to social shares with no preview. OG image at the wrong aspect ratio, leading to crops that cut off important content.

Fix: Set template defaults; allow per-page overrides for the homepage and major landing pages.

3.8 URL structure is clean

Check: URLs are readable, lowercase, hyphen-separated, free of session IDs, free of unnecessary parameters. No ?utm_ parameters indexed.

Tool: Crawler URL audit; site:yourdomain.com inurl:utm Google search to find indexed tracking parameters.

Common failure mode: Old CMS exposing internal IDs in URLs (/page.php?id=4827); marketing URLs with tracking parameters getting indexed; inconsistent trailing slash behaviour.

Fix: Configure URL rewriting at the CMS or server level. Strip tracking parameters from canonical references. Add rel="canonical" on parameterised URLs pointing to the clean version.

3.9 Viewport, html lang, and favicon are set

Check: Every page has a <meta name="viewport" content="width=device-width, initial-scale=1"> tag, a lang attribute on <html>, and a favicon.

Tool: Manual view-source or SEO Page Checker.

Common failure mode: Missing viewport tag causes mobile rendering issues that affect both UX and mobile-first indexing signals. Missing lang attribute reduces accessibility and weakens language signals.

Fix: Add at template level. These are one-line changes with site-wide impact.

4. Core Web Vitals and page speed

Speed is a confirmed ranking signal, but more importantly it's a conversion factor that's easier to measure than to argue about. Concepts: Core Web Vitals, Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint, page speed.

The threshold to know: Google's official Core Web Vitals thresholds are LCP under 2.5s, INP under 200ms, CLS under 0.1. Industry research from Screaming Frog's CWV study has consistently shown only around 12–15% of mobile pages pass all three thresholds, meaning if you do, you're already in the minority.

4.1 LCP under 2.5 seconds on key page templates

Check: Run your top page templates (homepage, top category, top product, top blog post) through speed testing. LCP should be under 2.5s on mobile.

Tool: PageSpeed Insights for both field data and lab data; Search Console's Core Web Vitals report for site-wide field data; our page speed test for quick checks on individual URLs.

Common failure mode: Hero image too large or not optimised, slow server response time (TTFB), render-blocking JavaScript above the fold, web fonts loading late.

Fix: Optimise the LCP element specifically, usually a hero image. Serve in WebP or AVIF, size appropriately, preload it. Address TTFB at the server or CDN layer.

4.2 INP under 200ms on interactive pages

Check: Pages with forms, filters, accordions, or interactive elements should respond to interaction in under 200ms. Google's INP guide covers the metric in detail.

Tool: PageSpeed Insights field data; Chrome DevTools Performance panel for diagnosis.

Common failure mode: Heavy JavaScript bundles, third-party analytics or tag-management scripts blocking the main thread on interaction, expensive React re-renders.

Fix: Defer non-critical JavaScript, break up long tasks, move heavy work into web workers where appropriate. Audit third-party scripts, chat widgets and tag managers are common offenders.

4.3 CLS under 0.1 across the site

Check: Visible page elements shouldn't shift after initial render. CLS measures the cumulative shift; the threshold is 0.1.

Tool: PageSpeed Insights; the Web Vitals Chrome extension shows CLS live as you scroll.

Common failure mode: Images without width and height attributes; ads or embeds that load late and push content down; web fonts swapping in after page render (FOIT/FOUT); cookie banners that appear after a delay.

Fix: Add explicit dimensions to every image and embed. Reserve space for ads and embeds. Use font-display: swap with appropriately matched fallback fonts.

4.4 Images use modern formats and correct sizing

Check: Images served in WebP or AVIF where the browser supports them, with appropriate fallbacks. No images larger than their displayed size. Lazy loading on below-the-fold images.

Tool: SEO Page Checker flags missing modern-format usage and missing dimensions. PageSpeed Insights flags oversized images.

Common failure mode: 3000px-wide source images displayed at 600px width, costing megabytes of unnecessary download per page. Original-format JPEGs and PNGs being served when WebP would be smaller. Lazy-loading the hero image (which hurts LCP).

Fix: Implement an image pipeline that generates appropriate sizes and modern formats. Use <picture> elements with srcset for responsive sizing. loading="lazy" on below-the-fold images only.

4.5 Caching headers are set on static assets

Check: CSS, JavaScript, fonts, and images are served with Cache-Control headers that allow long-term caching with proper versioning.

Tool: Browser DevTools Network panel → check response headers on static assets.

Common failure mode: Static assets served with no cache headers or no-cache, forcing browsers to re-download on every visit.

Fix: Configure server or CDN to send Cache-Control: public, max-age=31536000, immutable on fingerprinted static assets, with shorter cache windows on HTML.

4.6 Render-blocking resources are minimised

Check: CSS and JavaScript files loaded in the document <head> block rendering until they finish. Critical CSS should be inline; non-critical CSS deferred; JavaScript deferred or async unless it's specifically needed before render.

Tool: PageSpeed Insights flags render-blocking resources explicitly.

Common failure mode: Multiple synchronous <script> tags in the head; large CSS files loaded entirely upfront when most is below-the-fold; Google Fonts loaded synchronously without preconnect.

Fix: Inline critical CSS for above-the-fold content. Defer the rest. Add async or defer to non-essential scripts. Preconnect to third-party origins early.

4.7 CDN is serving from edge locations

Check: Static assets are actually being served from CDN edge nodes near your users, not from origin every time.

Tool: Check response headers for CDN-specific headers (Cloudflare's cf-cache-status, Fastly's x-cache, etc.); test from multiple geographic locations.

Common failure mode: CDN configured but cache rules excluding most paths; CDN cache being invalidated more often than necessary; cacheable HTML not actually being cached.

Fix: Audit cache rules at the CDN. Ensure static assets have appropriate cache lifetimes. Consider caching HTML at the edge for high-traffic pages.

5. HTTPS, security, and status codes

The boring section that quietly breaks sites. Concepts: HTTPS, HTTP status codes.

5.1 SSL certificate is valid, current, and covers all subdomains

Check: Certificate isn't expired or expiring within 30 days. Certificate chain is valid. Certificate covers every subdomain that serves traffic, including ones used for images or static assets.

Tool: SSL Labs' server test gives a comprehensive grade.

Common failure mode: Certificate expired on a subdomain (e.g. img.example.com) while the main domain stays valid. Browsers warn, users notice, aggregate analytics rarely flag it cleanly. Certificate chain issues that work on desktop but fail on mobile.

Fix: Automate renewal via Let's Encrypt or your CA. Ensure certificates are wildcard or explicitly cover every subdomain. Monitor with an external check.

5.2 All HTTP URLs redirect to HTTPS

Check: Crawl the site starting from http:// URLs. Every page should 301-redirect to its HTTPS equivalent.

Tool: Screaming Frog or any crawler, starting list from HTTP URLs.

Common failure mode: Some pages redirect but others don't; redirects go to homepage instead of the matching HTTPS page.

Fix: Server-level 301 redirect rule for all HTTP traffic to the equivalent HTTPS URL.

5.3 No mixed content on HTTPS pages

Check: HTTPS pages don't load resources (images, scripts, stylesheets, fonts) over HTTP.

Tool: Browser DevTools Console shows mixed-content warnings; the SEO Page Checker flags mixed content per URL.

Common failure mode: Old blog posts with hardcoded HTTP image URLs; third-party embeds that default to HTTP; CDN URLs not updated after an HTTPS migration.

Fix: Update hardcoded URLs to HTTPS. Use // protocol-relative URLs or HTTPS-only embed codes. Add a Content-Security-Policy: upgrade-insecure-requests header as a safety net.

5.4 HTTP status codes are correct site-wide

Check: Live pages return 200. Permanently moved pages return 301. Temporarily moved pages return 302. Truly removed pages return 404 (or 410 for gone-forever). Server errors are rare and investigated.

Tool: Crawler status code report; Search Console's Pages report for indexability statuses.

Common failure mode: Old pages 302-redirected when they should 301 (preserving the temporary signal forever); 200-status soft 404s; intermittent 5xx errors under load that don't show up in normal testing.

Fix: Convert permanent moves to 301. Fix soft 404s as discussed in section 1. Investigate 5xx errors at the server log level, they may indicate capacity, application bugs, or specific URL patterns failing.

5.5 Redirects preserve link equity where it matters

Check: When pages are removed or moved, they redirect to relevant replacement pages rather than the homepage.

Tool: Manual audit of recently retired URLs; analytics review of historic landing pages to identify high-value targets.

Common failure mode: Blanket "redirect everything to homepage" after a migration, wasting all the topical relevance of the old URLs.

Fix: Map old URLs to closest-relevant new URLs. Only redirect to homepage when there's genuinely no better target, and consider whether 410 is more honest in those cases.

5.6 HSTS is enabled

Check: The site sends a Strict-Transport-Security header instructing browsers to use HTTPS by default. Optionally preloaded via the HSTS preload list.

Tool: Browser DevTools Network panel; SSL Labs server test reports HSTS status.

Common failure mode: HSTS not set, leaving a window where users typing http:// can be MITM'd before the redirect.

Fix: Add Strict-Transport-Security: max-age=31536000; includeSubDomains. Test thoroughly before enabling preload, it's effectively irreversible for the duration of max-age.

6. Mobile and mobile-first indexing

Google indexes the mobile version of pages by default. If your mobile experience is broken, that's the version Google sees. Concepts: mobile-first indexing, mobile optimization.

6.1 Mobile and desktop content match

Check: Important content visible on desktop is also visible on mobile. Internal links available on desktop are available on mobile (even if behind a hamburger menu). Structured data is consistent across both.

Tool: Compare desktop and mobile rendered HTML in Search Console URL Inspection.

Common failure mode: Mobile version hides large content sections behind tabs or accordions that ship collapsed; mobile navigation omits items that exist on desktop; mobile templates skip schema markup that's present on desktop.

Fix: Use responsive design rather than separate mobile templates. If using dynamic serving or separate URLs, audit the differences explicitly.

6.2 Viewport configured for mobile

Check: Each page has <meta name="viewport" content="width=device-width, initial-scale=1">. (Covered in section 3.9 above; repeated here because it's a mobile-specific failure when absent.)

6.3 Touch targets meet minimum size guidance

Check: Interactive elements (buttons, links) are at least 48×48 CSS pixels with adequate spacing per Google's accessible tap targets guidance.

Tool: PageSpeed Insights' Accessibility audit flags touch target issues.

Common failure mode: Inline text links packed close together; small social-share icons; dense table-based navigation.

Fix: Increase touch target size or padding around clickable areas.

6.4 No intrusive interstitials on mobile

Check: Pages don't show full-screen popups, app-install banners covering main content, or interstitials before the user can read the page. Google's interstitial guidance details what's penalised.

Tool: Manual mobile testing; field reports from real users.

Common failure mode: Email signup popup triggered on page load; cookie banner that occupies more than half the screen and can't be dismissed easily; aggressive app-install prompts.

Fix: Time interstitials based on engagement (scroll depth, time on page). Keep cookie banners constrained to bottom or top edge, not full-screen.

6.5 Mobile page speed specifically

Check: Run PageSpeed Insights with the mobile profile specifically. Mobile typically lags desktop, the gap matters because mobile is what's indexed.

Tool: PageSpeed Insights mobile tab; Search Console Core Web Vitals report (separates mobile and desktop).

Common failure mode: Desktop CWV in the green, mobile in the red. Indicates desktop-optimised testing that didn't account for slower mobile hardware and networks.

Fix: Optimise specifically for mobile. The performance budget for mobile should be tighter than for desktop because users have less hardware and worse connections on average.

7. AI search readiness

Most technical SEO checklists don't yet address this, but accessibility to AI crawlers is increasingly part of the technical layer. Concepts in the wiki: AI Overviews, Generative Engine Optimization (GEO), Answer Engine Optimization (AEO), AI Visibility.

7.1 AI crawler access in robots.txt is intentional

Check: Decide explicitly whether to allow or block each major AI crawler, OpenAI's GPTBot, Anthropic's ClaudeBot and Claude-Web, Perplexity's PerplexityBot, Google's Google-Extended, Common Crawl's CCBot. The decision is a business call; not making one means defaulting to whatever your current robots.txt happens to permit.

Tool: Direct inspection of robots.txt. Reference: OpenAI's GPTBot documentation, Anthropic's crawler documentation, Perplexity's bots documentation.

Common failure mode: No explicit directive for AI crawlers, leading to ambiguous default behaviour. Or blanket-blocking all AI bots without considering that this also excludes you from answer engine citations.

Fix: Add per-bot rules. Most sites that care about being cited in AI answers should allow these bots; those concerned about training-data use can allow access-for-search bots while blocking training-data bots where the distinction exists.

7.2 Content is available in raw HTML, not just rendered JavaScript

Check: Most AI crawlers don't execute JavaScript. View the page source (Ctrl+U), if the main content isn't in the raw HTML, AI crawlers can't see it.

Tool: View-source on the page; curl for the raw response.

Common failure mode: Single-page-application sites where everything is JS-hydrated. Googlebot eventually renders it; AI bots typically don't.

Fix: Server-side render or pre-render key content. The fix overlaps with check 1.7 above, but the consequences for AI search are stricter.

7.3 Content structure is extractable

Check: Pages use clear heading hierarchy, semantic HTML (proper lists, tables, paragraphs), and discrete answers to discrete questions. AI engines often extract specific passages; structure that makes passages extractable helps.

Tool: SEO Page Checker flags heading hierarchy issues; manual review of how cleanly answers are isolated in the markup.

Common failure mode: Long flowing prose without clear question/answer breakpoints; key information buried in paragraphs without subheadings.

Fix: Structure content so each substantive question is answered in a self-contained section under a descriptive H2 or H3. FAQ-style structuring is particularly effective for AI extraction.

7.4 Structured data signals content type to AI systems

Check: Use appropriate schema types (Article, FAQPage, HowTo, Product, Recipe, Review) so both search and AI systems can identify content type and extract relevant fields.

Tool: Google's Rich Results Test; Schema.org validator.

Common failure mode: No schema markup, leaving AI systems to infer content type from prose alone.

Fix: Add JSON-LD structured data matching the content type. Validate. Keep data in schema consistent with visible content.

7.5 Author and publisher signals are explicit

Check: Content has visible author attribution and publication date. Schema markup (Article, NewsArticle) names the author and publisher entities.

Tool: Visual page review; schema validation.

Common failure mode: Anonymous content; missing dates; author bylines that aren't linked to author pages.

Fix: Add author bylines linked to dedicated author pages with biographical detail. Add visible publication and updated dates. Mark up in schema.

7.6 llms.txt for documentation-rich sites (optional)

Check: Sites with extensive documentation may benefit from an llms.txt file, an emerging convention for summarising site structure to LLMs in a more efficient form than crawling everything.

Tool: Manual creation; the spec is still emerging, adoption is partial.

Common failure mode: Not directly applicable to most content sites yet, but worth tracking as adoption develops.

Fix: If your site has a documentation portal or API reference, consider adding an llms.txt. For typical content sites, this is low priority compared to checks 7.1–7.5.

8. Search Console and log file verification

The verification layer: using first-party crawl data to confirm what's actually happening, rather than what you think is happening.

8.1 Search Console is set up for every domain property

Check: Domain property set up in Search Console (not just URL prefix property, domain property covers all subdomains and protocols).

Tool: Search Console itself.

Common failure mode: Only the https://www.example.com property exists, missing the data for https://example.com, http:// variants, or subdomains.

Fix: Add domain property via DNS verification. It aggregates data across all variants.

8.2 Pages report indexability buckets are reviewed

Check: In Search Console → Indexing → Pages, review each "Why pages aren't indexed" category. Sort by impressions or impact, you want to recover the highest-traffic potential pages first.

Tool: Search Console Pages report.

Common failure mode: Hundreds of pages in "Crawled, currently not indexed" being ignored; treating "Discovered, currently not indexed" as a temporary state when it usually isn't.

Fix: For each category, identify the underlying cause and fix at template or content level. Don't just "request indexing" on a long list of URLs; that doesn't change quality assessment.

8.3 Core Web Vitals report shows mobile + desktop status

Check: Search Console → Experience → Core Web Vitals. Both mobile and desktop sections should show majority Good URLs.

Tool: Search Console Core Web Vitals report.

Common failure mode: "Needs improvement" or "Poor" status on representative URL groups, indicating systematic template-level performance issues.

Fix: Address at template level. One slow template often affects thousands of URLs.

8.4 Manual actions and security issues are clear

Check: Search Console → Security & Manual Actions. Both should be empty.

Tool: Search Console.

Common failure mode: Unaddressed manual actions blocking ranking; security issues from hacked content that wasn't fully cleaned up.

Fix: Address the issue per Search Console's specific guidance, then request review.

8.5 Sitemap submission status is current

Check: Sitemaps submitted in Search Console → Sitemaps. Status is "Success." URL counts match expectations.

Tool: Search Console Sitemaps report.

Common failure mode: Sitemap submitted years ago, never resubmitted after URL changes, now showing "Couldn't fetch" or significantly fewer indexed URLs than submitted.

Fix: Resubmit the current sitemap. Investigate the gap between submitted and indexed counts as part of section 8.2.

8.6 Server log analysis on large sites

Check: For sites of more than a few thousand pages, analyse server access logs to see exactly which URLs Googlebot is crawling and how often. This is the only way to verify crawl-budget assumptions.

Tool: Screaming Frog's Log File Analyser or equivalent.

Common failure mode: Crawl budget being spent on faceted nav URLs, paginated archives, or low-value parameterised URLs while important pages are crawled infrequently.

Fix: Apply the crawl-budget fixes from section 1.8. Re-analyse logs a few weeks later to confirm changes are reflected in actual crawl behaviour.

9. How to prioritise what you've found

A full audit will surface dozens or hundreds of issues. Prioritising them matters more than fixing every one.

Fix indexability blockers first. An accidental noindex on key templates, robots.txt blocking entire content sections, or a canonical pointing at the wrong URL variant, these can make every other fix moot. Anything in section 1 of this checklist that affects important pages is priority zero.

Fix things that affect many URLs at once next. Template-level issues (missing meta descriptions across a content type, missing OG images site-wide, no LCP optimisation on a category template) scale: one fix, thousands of pages improved. Spend dev time here before chasing per-URL fixes.

Fix things that affect top pages by traffic next. Pull a Search Console report of pages by impressions or clicks. Address per-URL issues on these specifically, even if the same issue exists on long-tail pages, the impact concentration is on the top pages.

Defer cosmetic and edge-case issues. Missing Open Graph image on a deprecated category page, INP slightly over threshold on a low-traffic legacy template, hreflang mismatch on a regional variant that gets 30 visits a month, these are real but they're not where the ranking gains are.

This sequencing follows naturally from the structure of the checklist itself: section 1 first, then section 4 (speed at the template level), then sections 2–3 and 5–7 in whatever order matches your highest-traffic content types.

FAQ

What to look for in a technical SEO audit?

A technical audit looks at how well search engines can crawl, render, index, and rank your pages, separate from the editorial quality of the content itself. The main areas: crawlability (robots.txt, sitemaps, crawl errors), indexation (canonical tags, noindex directives, duplicate content handling), site architecture and internal linking, on-page technical elements (titles, meta tags, structured data, hreflang), site speed and Core Web Vitals, HTTPS and security, mobile-first indexing, and increasingly AI crawler accessibility. Each of these is covered as its own section in this checklist.

What is a technical SEO checklist?

A technical SEO checklist is a structured list of checks you run against a website to identify technical issues that may be limiting its search visibility. Unlike on-page SEO checks (which focus on content quality and keyword targeting), technical checks focus on infrastructure: can crawlers reach your pages, can they understand what those pages are about, do those pages load fast enough, do they meet Google's technical requirements for indexing. A good checklist groups checks by category, names the specific tool for each check, and prioritises which fixes have the largest ranking impact. The 60 checks in this article are organised exactly that way.

What to include in an SEO audit?

A comprehensive SEO audit includes technical checks (the focus of this article), on-page content review, off-page backlink analysis, and competitive context. Technical components specifically: XML sitemaps and robots.txt review, status code audit across the site, canonical tag review, indexation analysis via Search Console, mobile usability check, Core Web Vitals review, structured data validation, hreflang implementation (for international sites), security and HTTPS configuration, and increasingly AI crawler accessibility. For the broader context of SEO audits as a category, including on-page and off-page components, our SEO Audit wiki entry covers the full scope.

What tools do you use for technical SEO audits?

The standard technical SEO stack centres on a few core tools used together. For crawling: Screaming Frog SEO Spider or Sitebulb. For indexation and search visibility data: Google Search Console (essential, free). For performance: PageSpeed Insights and the web.dev documentation. For structured data: Google's Rich Results Test. For SSL: SSL Labs server test. For backlink data: Ahrefs, Semrush, Moz, or our own URL backlink checker. 

For single-URL on-page audits we use our SEO Page Checker, which reports meta tags, headings, structured data, image and link issues in a single graded report.

How is a technical SEO audit different from an SEO audit?

A technical SEO audit is one component of a broader SEO audit. The broader audit also covers content quality and keyword targeting (on-page SEO), backlink profile and external authority signals (off-page SEO), and sometimes local SEO factors for geographic businesses. A technical audit zooms in on the infrastructure layer specifically: crawlability, indexability, speed, security, mobile, and structural elements. Our wiki entry on SEO Audit covers how the audit types fit together and when each one is most relevant.

How often should you run a technical SEO audit?

For most sites, a comprehensive technical audit once per quarter is reasonable. Larger sites or those with frequent code deployments should consider monthly spot-checks of the highest-impact areas (indexability buckets in Search Console, Core Web Vitals trends, crawl errors). Always run a focused technical audit after major changes: site migrations, redesigns, CMS upgrades, structural URL changes, or large-scale content reorganisations. The window between a problem being introduced and showing up in rankings can be weeks; the window for noticing it and recovering is much shorter if you have a baseline to compare against.

This checklist is the procedural counterpart to our SEO Audit reference entry, which covers the broader concept and the different audit types. For single-URL on-page audits while working through this list, our SEO Page Checker covers meta tags, headings, social preview cards, structured data, images, and links in one report.