Technical SEO Audit Template: The 150-Point Checklist for 2026

A technical SEO audit is the diagnostic foundation of any serious organic search program. Without it, you’re optimizing content and building links on top of infrastructure problems that will cap your results regardless of how much work you put in. Technical issues — crawl blocks, duplicate content, Core Web Vitals failures, broken canonicals — don’t just limit performance, they actively suppress it.

This 150-point technical SEO audit checklist covers every major technical dimension affecting organic performance in 2026. Use it as a working template: go through each section, document findings, prioritize by impact, and execute fixes. The businesses that rank consistently at the top of competitive SERPs treat technical SEO as infrastructure maintenance, not a one-time project.

Section 1: Crawlability and Accessibility (30 Points)

Googlebot needs to be able to access your pages before anything else matters. Crawlability failures are binary — a blocked page can’t rank regardless of its quality.

robots.txt Audit

• ☐ robots.txt file exists and is accessible at domain root
• ☐ No critical pages or directories blocked with Disallow
• ☐ CSS and JavaScript files are not blocked (required for rendering)
• ☐ Sitemap URL is referenced in robots.txt
• ☐ Crawl-delay directives are reasonable (not set so low they starve Googlebot)
• ☐ No inadvertent blocking of entire site (Disallow: /)
• ☐ robots.txt returns 200 OK, not a redirect or error

Crawl Configuration

• ☐ All important pages are linked from the sitemap and discoverable via internal links
• ☐ No orphan pages (important pages with no internal links pointing to them)
• ☐ Crawl depth of important pages is <4 clicks from homepage
• ☐ Pagination is implemented correctly (not blocking next/prev crawl)
• ☐ Faceted navigation and filter pages are handled (blocked, canonicalized, or indexed strategically)
• ☐ Parameters that create duplicate content are handled via parameter handling or robots.txt
• ☐ JavaScript does not block Googlebot from accessing critical content
• ☐ Server response times are under 2 seconds for crawl requests

Access and Authentication

• ☐ No login walls blocking public pages that should be indexed
• ☐ Staging/dev content is blocked from crawl (different issue than production)
• ☐ Geolocation-based content blocking doesn’t affect Googlebot
• ☐ CDN or WAF is not inadvertently blocking Googlebot user-agent
• ☐ No interstitials on mobile that trigger app install prompts

Crawl Error Analysis

• ☐ Search Console Coverage report reviewed for crawl errors
• ☐ 404 errors on important URLs identified and resolved (redirect or restore)
• ☐ Server errors (5xx) identified and root causes addressed
• ☐ Redirect errors identified and chains cleaned up
• ☐ Soft 404s identified and resolved (200 response with “not found” content)
• ☐ Crawl budget analysis for large sites (confirm priority pages are being crawled)

Section 2: Indexation and Duplicate Content (25 Points)

Crawling and indexing are separate. A page can be crawled but not indexed. And indexed pages that shouldn’t be indexed dilute crawl budget and create duplicate content problems.

Index Status

• ☐ Indexed page count matches expected page count (neither drastically over nor under)
• ☐ No important pages are excluded from index with noindex directive
• ☐ No pages are indexed that should be excluded (thin content, parameter variations, duplicate pages)
• ☐ Search Console Coverage report exclusions are reviewed and understood
• ☐ “Crawled but not indexed” pages are analyzed for content quality issues
• ☐ “Discovered but not indexed” pages are analyzed for crawl budget issues

Canonical Implementation

• ☐ All pages have self-referencing canonical tags
• ☐ Canonical tags point to the correct preferred URL (HTTPS, www preference consistent)
• ☐ Paginated pages have appropriate canonical handling
• ☐ Canonical tags match the URL that is actually indexed (no canonicals pointing to redirects)
• ☐ No conflicting canonical signals (canonical tag pointing to A, but 301 redirect to B)
• ☐ Hreflang URLs for multi-language sites match canonical URLs exactly

Duplicate Content

• ☐ HTTP and HTTPS versions both tested — HTTP redirects to HTTPS
• ☐ www and non-www versions both tested — one redirects to preferred version
• ☐ Trailing slash consistency — either always present or always absent, with redirects enforced
• ☐ No duplicate content across URL parameter variations
• ☐ Syndicated content (if any) has canonical pointing to original
• ☐ Boilerplate content (shared across many pages) doesn’t trigger thin content penalties
• ☐ Mobile and desktop versions (if separate URLs) are correctly related via canonical or annotation

Section 3: Site Architecture and URL Structure (20 Points)

URL Structure

• ☐ URLs are clean, descriptive, and keyword-relevant
• ☐ No URL parameter pollution in indexed URLs
• ☐ URL length is reasonable (<115 characters)
• ☐ No uppercase letters in URLs (case sensitivity can create duplicate content)
• ☐ No special characters in URLs that aren’t URL-encoded
• ☐ Folder depth is logical and reflects site hierarchy

Internal Linking and Site Structure

• ☐ Internal link analysis: most important pages have the most internal links pointing to them
• ☐ No broken internal links (404 on linked URLs)
• ☐ Navigation links are in crawlable HTML, not generated entirely by JavaScript
• ☐ Breadcrumbs implemented with correct hierarchy and BreadcrumbList schema
• ☐ Footer links are not over-optimized (not dozens of keyword-rich footer links)
• ☐ Anchor text for internal links is descriptive and varied
• ☐ No redirect chains in internal links (links point directly to final URLs)

XML Sitemaps

• ☐ XML sitemap exists and is submitted to Search Console
• ☐ Sitemap includes all important indexable pages
• ☐ Sitemap excludes noindex pages, paginated pages (where appropriate), and parameter URLs
• ☐ Lastmod dates are accurate (reflecting actual last modification, not today’s date)
• ☐ Sitemap index used for sites with >50,000 URLs
• ☐ Video and image sitemaps used where relevant

Section 4: Core Web Vitals and Performance (25 Points)

Core Web Vitals are a confirmed Google ranking factor and a user experience imperative. Poor CWV directly impacts both rankings and conversion rates.

Largest Contentful Paint (LCP)

• ☐ LCP measured for key landing pages — target: <2.5 seconds
• ☐ LCP element identified (hero image, H1 text, or key content block)
• ☐ Hero images have fetchpriority=”high” attribute
• ☐ LCP images are not lazy-loaded
• ☐ Critical render path resources are preloaded
• ☐ Server Time to First Byte (TTFB) is under 800ms
• ☐ LCP measured in field data (CrUX), not just lab data (Lighthouse)

Cumulative Layout Shift (CLS)

• ☐ CLS measured for key landing pages — target: <0.1
• ☐ All images have explicit width and height attributes
• ☐ No ads or embeds without reserved space
• ☐ Web fonts don’t cause layout shift (font-display configured correctly)
• ☐ No dynamic content injected above existing content

Interaction to Next Paint (INP)

• ☐ INP measured for interactive pages — target: <200ms
• ☐ Main thread blocking JavaScript identified and deferred
• ☐ Third-party scripts audited for INP impact
• ☐ JavaScript bundle size audited (code splitting implemented)

General Performance

• ☐ Images served in WebP or AVIF format
• ☐ Images are appropriately sized (not serving 3000px images in 300px containers)
• ☐ Caching headers configured correctly (static assets with long TTL)
• ☐ Gzip or Brotli compression enabled on the server
• ☐ CDN implemented for global audiences

Section 5: Structured Data and Schema Markup (20 Points)

Structured data doesn’t directly boost rankings but enables rich results, improves click-through rates, and provides Google with explicit content signals that improve understanding.

Schema Implementation

• ☐ Organization or LocalBusiness schema on homepage
• ☐ BreadcrumbList schema on all non-homepage pages
• ☐ Article schema on blog posts and news content
• ☐ Product schema (with price, availability, ratings) on product pages
• ☐ FAQPage schema on FAQ and support pages
• ☐ HowTo schema on instructional content
• ☐ LocalBusiness schema for location-based businesses (with NAP data)
• ☐ Review schema implemented correctly (entity reviews, not self-review spam)

Schema Validation

• ☐ All schema validated with Google’s Rich Results Test
• ☐ No schema validation errors in Search Console Enhancements report
• ☐ Schema output in rendered HTML (not buried in JavaScript bundles)
• ☐ No schema for content that doesn’t appear on the page
• ☐ Consistent NAP data (name, address, phone) across schema and visible content

Section 6: Security, HTTPS, and Technical Infrastructure (20 Points)

HTTPS and Security

• ☐ SSL certificate valid and not expiring within 30 days
• ☐ All pages served over HTTPS (no mixed content warnings)
• ☐ HTTP Strict Transport Security (HSTS) header implemented
• ☐ No insecure (HTTP) resources loaded on HTTPS pages
• ☐ Security headers present (X-Content-Type-Options, X-Frame-Options)

Mobile and International

• ☐ Mobile-friendly test passes for all key pages
• ☐ Viewport meta tag present on all pages
• ☐ Touch targets are appropriately sized (buttons, links)
• ☐ Hreflang implemented correctly for multi-language/multi-region sites
• ☐ Hreflang values use correct BCP 47 language codes
• ☐ x-default hreflang assigned to the fallback URL

Server Configuration

• ☐ 301 redirects used (not 302) for permanent URL changes
• ☐ No redirect chains longer than 2 hops
• ☐ Server returns correct HTTP status codes (404 for missing pages, not 200)
• ☐ Custom 404 page exists and provides navigation options
• ☐ Server handles trailing slash consistently (redirect or accept, not serve both)

Prioritizing Audit Findings: The Impact/Effort Matrix

A 150-point audit will surface dozens of issues. Not all issues deserve equal attention. Use an impact/effort matrix to prioritize:

Quadrant 1 — Fix immediately (high impact, low effort): robots.txt blocking critical content, noindex on important pages, missing canonical tags, HTTP→HTTPS redirects. These are binary — they’re either blocking performance or they’re not.

Quadrant 2 — Plan and prioritize (high impact, high effort): Core Web Vitals improvements on high-traffic pages, duplicate content resolution across a large URL base, comprehensive schema implementation. These require development resources and project planning.

Quadrant 3 — Do when convenient (low impact, low effort): Minor URL cleanup, meta description optimization on low-traffic pages, image compression on rarely visited pages.

Quadrant 4 — Deprioritize (low impact, high effort): Cosmetic URL restructures that would break existing links, comprehensive hreflang implementation on low-traffic international pages. Don’t let perfect be the enemy of the important.

Our technical SEO practice uses this framework to ensure audit findings translate into ranked, resourced improvement plans — not spreadsheets that sit untouched.

Audit Tooling: What You Need for 2026

The tool landscape has evolved. The 2026 technical SEO toolkit:

• Screaming Frog SEO Spider or Sitebulb: Full site crawl, redirect analysis, canonical audit, internal link analysis, schema extraction
• Google Search Console: Index coverage, Core Web Vitals field data, rich results status, manual actions, security issues
• PageSpeed Insights / Lighthouse: CWV lab data, performance diagnostics, accessibility checks
• WebPageTest: Waterfall analysis, third-party script impact, performance across real devices
• Ahrefs or Semrush: Backlink audit, keyword tracking, competitor benchmarking
• Chrome DevTools: JavaScript rendering analysis, network requests, coverage report for unused code
• Schema.org Validator / Google Rich Results Test: Structured data validation

For enterprise sites, layer in log file analysis (Cloudflare Logs, server logs) to understand actual Googlebot crawl behavior — what it’s accessing, at what frequency, and where it’s hitting errors that tools don’t surface.

Frequently Asked Questions

How long does a technical SEO audit take?

For a small site (under 500 pages), a thorough technical SEO audit takes 8–16 hours. Medium sites (500–10,000 pages) require 2–5 days. Large enterprise sites (100,000+ pages) can require 2–4 weeks for a comprehensive audit. Automated crawl tools accelerate data collection significantly, but expert interpretation of findings and prioritization is where time is actually spent.

What tools do you need for a technical SEO audit?

Core toolkit: Screaming Frog or Sitebulb for crawl analysis, Google Search Console for index coverage and Core Web Vitals field data, PageSpeed Insights for performance diagnostics, and a structured data testing tool for schema validation. Ahrefs or Semrush add backlink and keyword performance dimensions. Google Search Console is non-negotiable — every other tool is optional depending on budget and scope.

What are the most impactful technical SEO issues to fix first?

Prioritize crawl blocks above everything — a robots.txt disallow on critical pages or noindex on pages that should rank are binary issues with immediate impact. After crawl/indexation issues, focus on Core Web Vitals failures on high-traffic pages (direct ranking factor), duplicate content with missing or broken canonicals (dilutes ranking signals), and broken internal links on key navigation paths.

How often should you run a technical SEO audit?

A full technical SEO audit at minimum annually, and after any major site change — redesign, platform migration, CMS change, URL restructure. For active sites, automated weekly crawls with alerting for critical issues (crawl errors, index drops, CWV regressions) are best practice. Think of technical SEO as infrastructure monitoring, not a one-time project.

What is the difference between a technical SEO audit and an on-page SEO audit?

Technical SEO audits examine infrastructure: crawlability, indexation, performance, schema, security, and server configuration. On-page SEO audits examine content: keyword optimization, title tags, meta descriptions, heading structure, content depth, and internal linking. Both are required for a complete assessment. Technical issues create a performance ceiling — you can’t out-optimize content or links on a technically broken site.

Do I need a technical SEO audit if my site is relatively new?

Yes — especially then. New sites often launch with technical debt from development: staging-era noindex directives left in place, robots.txt not updated for production, canonical tags pointing to development URLs, missing sitemap submissions. A technical audit within the first 30 days of launch catches these early, before ranking positions compound on a broken foundation. Catching a robots.txt blocking issue at launch is a 10-minute fix; catching it 6 months later means 6 months of lost ranking opportunity.

If your team needs support executing on audit findings — from implementation to validation — our SEO services are built to bridge the gap between audit findings and measurable organic performance improvements.