Technical SEO: The 12-Point Audit Checklist for 2026

Great content cannot rank if Google cannot reach it, understand it or decide which version to show. That is what technical SEO covers. This technical SEO audit checklist, our technical SEO checklist 2026 edition, is the short version of our full technical SEO audit playbook: twelve checks, in priority order, that you can run with free tools and a crawler. For the content and on-page side of an audit, use our SEO audit checklist for business websites.

How to do a technical SEO audit: the tools you need

• Google Search Console — Google’s own crawl, index and Core Web Vitals data. See our Search Console for technical SEO guide.
• A crawler — Screaming Frog or Sitebulb on desktop, or the Semrush or Ahrefs site audit in the cloud.
• PageSpeed Insights and Lighthouse — field and lab performance data.
• Rich Results Test and the Schema Markup Validator — structured data checks.
• Server access logs — for log file analysis on larger sites.

The 12 checks at a glance

1. Robots.txt and crawlability

Check: open /robots.txt and confirm nothing important is disallowed: product, category, service or blog paths, and never the CSS and JavaScript Google needs to render pages. Confirm the file includes a Sitemap: line.

Good looks like: only genuinely private or useless areas are blocked, such as admin paths, internal search results or cart pages. Crawl stats show no robots.txt fetch errors.

Fix: remove broad disallow rules added during development. Staging sites are the classic cause: a Disallow: / copied to production can stop crawling of an entire site.

2. Indexability: noindex, X-Robots-Tag and status

Check: crawl the site and list every URL with a noindex meta tag or an X-Robots-Tag header. Compare it with the Page indexing report’s “Excluded by noindex” list.

Good looks like: only pages you intend to hide, such as thank-you pages, filters and internal search, carry noindex.

Fix: remove stray noindex tags, especially from templates. Do not combine noindex with a robots.txt block; Google cannot see a tag on a page it cannot crawl.

3. XML sitemaps

XML sitemap best practices are simple: list only canonical, indexable URLs that return 200; keep each file under 50,000 URLs and 50 MB uncompressed; use a sitemap index for larger sites; and keep lastmod accurate. Submit the sitemap in Search Console and reference it in robots.txt.

Warning signs: redirects, 404s or noindex URLs inside the sitemap, or a discovered count wildly different from the number of pages you want indexed.

4. Site architecture and internal linking

Check: in your crawler, look at click depth (how many clicks from the homepage) and the internal link count for each important page. Find orphan pages: URLs in your sitemap or analytics that no internal link points to.

Good looks like: key pages within about three clicks of the homepage, linked from relevant pages with descriptive anchor text, and grouped into logical sections. Our guide to content clusters and topical authority shows how to structure this.

Fix: add contextual links from strong pages, build hub pages for each topic, and link every orphan page or remove it.

5. HTTP status codes and redirects

Check: crawl for 3xx, 4xx and 5xx responses and for redirect chains (A→B→C) and loops.

• Permanent moves should use a 301 redirect (or 308), pointing straight to the final URL.
• Pages that are gone should return 404 or 410, or redirect to a genuinely close replacement. See our 404 errors and SEO guide.
• Watch for any soft 404: an empty or error-like page that still returns 200.
• Recurring 5xx errors are urgent; they slow crawling and can drop pages.

Fix: collapse chains to one hop, update internal links to the final URLs, and fix server errors at the source.

6. Canonical tags and duplicate content

Check: every indexable page should have a self-referencing canonical tag, and duplicates should point to the preferred version. Test the common duplicate patterns: http vs https, www vs non-www, trailing slash vs none, upper vs lower case, and URL parameters from tracking, sorting or filtering.

Good looks like: one accessible version of each page, enforced by redirects, with canonicals, internal links, sitemaps and hreflang all agreeing. In URL Inspection, the Google-selected canonical matches yours.

Fix: redirect protocol and host variants, canonicalise parameter URLs, and stop linking internally to duplicate versions.

7. Core Web Vitals and page speed

Google’s Core Web Vitals measure real-user experience at the 75th percentile:

• Largest Contentful Paint (LCP) 2.5 seconds or less.
• Interaction to Next Paint (INP) 200 milliseconds or less. INP replaced FID in March 2024.
• Cumulative Layout Shift (CLS) 0.1 or less.

Common fixes: serve right-sized, modern images (WebP or AVIF) with srcset; give the main hero image high fetch priority and never lazy-load it; set width and height on images to prevent layout shift; defer non-critical JavaScript; and break up long tasks that block interaction. Page experience is a ranking consideration but rarely outweighs relevance, so fix the worst templates first. Our Core Web Vitals and INP guide goes deeper.

8. Mobile-first parity

Google now crawls and indexes sites with its smartphone crawler. Mobile-first indexing means that if content, links, structured data or images exist only on desktop, Google may not see them.

Check: crawl with a mobile user agent and compare it with a desktop crawl: page text, internal links, headings, schema and image alt text should match. Confirm the viewport meta tag is set and tap targets are usable.

Fix: stop hiding content or navigation on mobile templates, and make sure collapsed sections (tabs, accordions) are still present in the HTML.

9. JavaScript rendering

Google renders JavaScript, but rendering can be delayed, and other crawlers and many AI systems render little or none. For JavaScript SEO:

• Compare raw HTML with rendered HTML (URL Inspection → View crawled page, or a rendered crawl).
• Make sure main content, links and metadata exist in the rendered output, and ideally in the server HTML.
• Use real <a href> links, not click handlers, for navigation.
• Prefer server-side rendering or static generation for important pages.

10. Structured data and schema markup

Check: run key templates through the Rich Results Test and review the Enhancements reports in Search Console. Make sure each page’s schema markup matches what is visible on the page, uses its own IDs, and has no errors.

Good looks like: Organization and WebSite on the homepage, BreadcrumbList across the site, and the right type per template: Article or BlogPosting, Product, LocalBusiness, Service or FAQPage where it genuinely fits. Structured data also helps AI systems understand your entities. See our schema markup services and ecommerce schema guide.

11. HTTPS and security

Check: every URL loads over HTTPS with a valid certificate; HTTP redirects to HTTPS in one hop; there is no mixed content (HTTP images or scripts on HTTPS pages); and the HTTPS and Security issues reports in Search Console are clear.

Fix: update hard-coded HTTP asset links and canonicals, add HSTS once HTTPS is stable, and keep CMS plugins patched. Hacked sites can lose rankings overnight.

12. Hreflang and international setup

If you serve several languages or countries, hreflang tells Google which version to show to which audience. Each version must link to all the others (return tags), use valid language-region codes such as en-gb or en-au, point to canonical URLs, and ideally include an x-default. Choose a consistent structure: country domains, subdomains or subfolders. If you only serve one market, mark this check “not applicable” and move on. Our international SEO services cover multi-market setups.

Bonus checks for larger sites: logs and crawl budget

For sites with tens of thousands of URLs, add log file analysis: your server logs show exactly which URLs Googlebot requests and how often. If crawling is spent on parameters, filters or old URLs while new pages wait, you have a crawl budget problem. Fix it by blocking or canonicalising junk URLs, improving server speed, and strengthening internal links to new pages. Our guide to faceted navigation SEO covers the most common cause on ecommerce sites.

How often to run a technical SEO audit

• Monthly: a light check in Search Console (indexing, crawl stats, CWV, enhancements).
• Quarterly: a full website technical audit against all 12 checks.
• Before and after every migration, redesign or CMS change: a full audit, plus weekly monitoring for two months.

Technical SEO audit cost, and when to hire help

Technical SEO audit cost depends on the size of the site, its platform, whether JavaScript rendering or international setups are involved, and whether the audit includes implementation support. Be cautious of audits that are just an exported tool report with hundreds of “issues”. A useful audit from a technical SEO agency or technical SEO consultant ranks fixes by impact and effort, explains each one in plain language for your developers, and confirms them in Search Console afterwards. That is how our technical SEO services work. Our SEO pricing page explains how we scope it.

How to prioritise what you find

A crawler will report hundreds of “issues”. Most do not matter. Sort every finding on two questions: how many important pages does it affect? and how hard is it to fix?

This impact/effort matrix is the heart of technical SEO prioritisation: it keeps developers focused on fixes that move traffic, and stops technical debt piling up on templates that matter.

Platform notes: WordPress, Shopify, Wix and headless

• WordPress technical SEO: watch for indexable tag, author and attachment pages, plugin bloat that slows pages, and conflicting SEO plugins.
• Shopify technical SEO: product URLs exist under both /products/ and /collections/…/products/; make sure internal links and canonicals point to one version, and check filter URLs.
• Wix technical SEO: modern Wix handles many basics, but check custom URL structures, redirects after redesigns and image weight.
• Headless CMS SEO and JavaScript frameworks: confirm server-side rendering or static generation for indexable pages, and that metadata and canonicals are rendered in the HTML.

Planning a redesign or platform move? Use it as your site migration checklist, twice: once on the old site to record the baseline, and once on staging before launch. Every old URL needs a one-hop redirect to its closest new equivalent.

Technical SEO checklist: frequently asked questions