Technical SEO Audit Checklist: 54 Checks

A technical SEO checklist records whether search engines can fetch, render and index the intended URLs and whether users receive stable, secure pages. Run these 54 checks by page template and record the URL, observed result, evidence, owner and priority for every failure.

Crawlability Checks

• Robots controls are understood: Request /robots.txt and record the response. A missing file generally means no robots.txt crawl restrictions; where a file exists, parse it for the relevant crawler.
• No critical pages blocked by robots.txt: Check that Disallow rules don't prevent search engines from accessing key content, CSS, or JavaScript files.
• XML sitemap exists and is valid: Verify your sitemap at yoursite.com/sitemap.xml. It should list all indexable URLs and return a 200 status.
• Sitemap discovery is verified when used: Check robots.txt references and the relevant search-engine reports for submitted and processed sitemap files.
• Sitemap URLs match canonical URLs: Every URL in the sitemap should be the canonical version — no redirects, no non-canonical variants.
• Crawl budget isn't wasted: Check for excessive parameter URLs, infinite scroll pagination, calendar pages, or faceted navigation generating thousands of crawlable URLs.
• No orphan pages: Every indexable page should be reachable through at least one internal link. Use Screaming Frog to find pages in the sitemap but not in the crawl.
• Crawl errors resolved: Check GSC's Page Indexing report for crawl errors. Fix server errors (5xx) first, then soft 404s, then redirect issues.
• JavaScript-rendered content is crawlable: If your site uses client-side rendering (React, Vue, Angular), verify that Googlebot can see the rendered content using Google's URL Inspection tool.

Indexation Checks

• Important pages are indexed: Inspect representative URLs and the Page indexing report in Google Search Console. A site: search can help discovery but its result count is not a reliable index total.
• No accidental noindex tags: Crawl your site and check for meta robots noindex tags on pages that should be indexed.
• Canonical signals are coherent: For duplicate or near-duplicate URL sets, compare redirects, rel="canonical", sitemap inclusion and internal links. Self-referencing canonicals can help, but are not mandatory on every page.
• No duplicate content issues: Check for www vs non-www, HTTP vs HTTPS, trailing slash vs non-trailing slash variants all serving the same content.
• Pagination exposes crawlable URLs: Give each component page a unique URL and link pages sequentially with ordinary <a href> links. Google no longer uses rel="next" or rel="prev" as indexing signals.
• Hreflang tags are correct (if multilingual): Each language version should reference all other versions including itself. X-default should point to the language selector or default version.
• Low-value or empty pages are reviewed by purpose: Determine whether each page completes a useful task, needs missing content, duplicates another URL or represents an intentional empty state. Keep, improve, consolidate, noindex or remove it only after that decision.

Site Architecture Checks

• Priority pages are easy to reach: Measure click depth from the crawl start URL and investigate important pages buried behind many links. Treat depth as a diagnostic value rather than a universal three-click rule.
• URL structure is logical and flat: URLs should follow a clear hierarchy (domain.com/category/page/) without unnecessary depth or parameters.
• URLs are clean and descriptive: No session IDs, excessive parameters, or meaningless strings. URLs should contain relevant keywords.
• Internal linking is strategic: Important pages should have the most internal links pointing to them. Check with Screaming Frog's inlinks report.
• Breadcrumbs are implemented: Breadcrumb navigation helps users and search engines understand your site hierarchy. Add BreadcrumbList schema.
• No unnecessary redirect chains: A link from A to B to C adds requests and can delay users and crawlers. Update internal links and redirect rules to point to the final intended URL.
• No broken internal links: Crawl your site and fix any links returning 404 status codes. These waste crawl budget and create poor user experience.
• 404 page is helpful: Your 404 page should return a proper 404 status code (not 200) and help users find what they were looking for.

Core Web Vitals Checks

• LCP within 2.5 seconds: Check 75th-percentile field data where available and use a lab trace to identify the LCP element and subparts.
• INP at most 200 milliseconds: Use field attribution and interaction traces to separate input delay, processing and presentation delay.
• CLS at most 0.1: Inspect shift clusters and responsible elements; reserve space or adjust font and dynamic-content behaviour according to the evidence.
• Field data passes in GSC: Lab data (Lighthouse) is simulated. Check real-user data in GSC's Core Web Vitals report for actual pass/fail status.
• Render-blocking resources are traced: Identify CSS or scripts that delay the measured render, then test safe delivery changes against later states and interactions.
• Images are optimised: Use modern formats (WebP/AVIF), appropriate sizing, lazy loading for below-fold images, and responsive srcset attributes.

Mobile Checks

• Viewport meta tag is set: Every page needs <meta name="viewport" content="width=device-width, initial-scale=1">.
• Text is readable and adaptable: Test the chosen font size, spacing and measure on representative devices and at zoom. A 16px base and 1.5 line height can be useful design starting points, but WCAG does not prescribe those values for all text.
• Tap targets have sufficient size or spacing: For WCAG 2.2 AA, test the 24 by 24 CSS pixel target-size rule and its spacing and inline exceptions. Larger controls can still improve touch usability.
• Reflow is tested: At the WCAG 2.2 AA reflow conditions, check for loss of content or function and avoid two-dimensional scrolling except for parts that require a two-dimensional layout for meaning or use.
• Mobile menu works correctly: Navigation should be accessible and usable on mobile devices. Test on actual devices, not just browser emulation.
• Interstitials preserve access: Check mobile pages against Google's intrusive-interstitial guidance and verify that required notices do not obscure more content than necessary.
• Mobile page speed is fast: Test mobile-specific speed in PageSpeed Insights. Mobile often has different issues than desktop (network latency, CPU constraints).

Security Checks

• HTTPS is enforced: All HTTP URLs should 301 redirect to HTTPS. No mixed content warnings.
• SSL certificate is valid: Check expiration date, certificate chain, and protocol versions with SSL Labs.
• HSTS is evaluated: Enable it only after required hosts and subdomains support HTTPS. Choose duration, subdomain scope and preload through security change control.
• Security headers are configured: Check Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy with securityheaders.com.
• No mixed content: All resources (images, scripts, stylesheets, fonts) must load over HTTPS when the page is served over HTTPS.

Structured Data Checks

• Relevant structured data is implemented: Use a Google-supported type only where it describes the visible content. There is no minimum set that every site or page must carry.
• Structured data is validated with the right tool: Use Google's Rich Results Test for Google-supported search features and Schema.org's validator for general vocabulary. Interpret errors and warnings against the applicable feature and visible content.
• BreadcrumbList schema matches visible breadcrumbs: The structured data should mirror what users see on the page.
• Product structured data matches products: Add supported properties only when the page and business model meet Google's eligibility rules. Markup enables eligibility and does not guarantee a rich result.
• FAQ markup is assessed against current eligibility: Google normally limits FAQ rich results to authoritative government and health sites. Do not add FAQPage solely to seek a search enhancement.
• No spammy or misleading schema: Only mark up content that's actually visible on the page. Don't add review schema for self-reviews or FAQ schema for content that isn't in Q&A format.

Server and Hosting Checks

• Server response time is measured in context: Compare TTFB across target locations and cached and uncached requests. Use the result to separate network delay from origin processing rather than treating 600ms as a universal pass line.
• Gzip/Brotli compression is enabled: Text-based resources should be compressed. Check with PageSpeed Insights or browser DevTools Network tab.
• Browser caching is configured: Static assets should have Cache-Control headers with appropriate max-age values. Check with Lighthouse.
• Edge delivery is evaluated where relevant: Compare latency, cache behaviour and origin load by audience location. A CDN is useful for some traffic and asset patterns, not a universal requirement.
• Server returns correct status codes: 200 for found pages, 301 for permanent redirects, 404 for missing pages. No soft 404s (404 content with 200 status).
• Error pages return proper status codes: Your custom 404 page must return HTTP 404, not 200. Your server error page should return 503 during maintenance.

Google documents the current crawling and indexing topics, Core Web Vitals thresholds and structured data rules. Use this checklist with our technical audit guide and retain dated exports or screenshots as evidence.