Technical SEO Audit Checklist: The 47-Point Check Every Site Needs

Published: April 21, 2026 | Read time: 14 min read

By Graeme Whiles

Most sites that struggle to rank do not have a content problem. They have a technical foundation that is quietly preventing search engines from crawling and evaluating what they have already built.

This is the 47-point checklist I use across every client engagement, in the order I run it.

If you want this process run on your site by a consultant rather than working through it yourself, the Technical SEO Audit covers the full 47-point process with a prioritised action plan.

Author Bio

Graeme Whiles is an independent SEO and AEO consultant at GWContent. He has worked with enterprise and SaaS brands including Originality.ai, Connecteam, 6sense, and Practice Better, growing organic traffic and AI search visibility across some of the most competitive categories in B2B. He holds content bylines with Foundr Magazine and Originality.ai, and built Three Putt Golf Clothing from a blank domain as a live proof of concept for his methodology.

Short on time? Here are the key takeaways

• A technical SEO audit reviews the infrastructure that determines whether search engines can find, crawl, index, and rank a site's content. Excellent content will not rank if the technical foundation is broken.
• The most common issues I find: index bloat, broken internal links, missing canonical tags, duplicate content, and Core Web Vitals failures on mobile.
• Fix crawlability and indexation first. Everything else builds on that foundation.
• Run a full audit at least annually, after any site migration, and immediately after any unexplained traffic drop.
• In 2026, a complete technical audit also covers AI search readiness. Most checklists still do not.

What Is a Technical SEO Audit?

A technical SEO audit is a systematic review of a website's infrastructure, the layer beneath the content, to identify issues that prevent search engines from efficiently crawling, indexing, and ranking its pages. It is sometimes called a site audit or SEO site audit and the terms are interchangeable. What matters is that it covers the entire site, not just the top-performing pages. The most damaging issues I find are almost never on the pages everyone is already watching.

It is distinct from a SEO content audit, which evaluates the content itself. Both are necessary. Technical issues undermine content performance regardless of quality: a well-researched, expertly written article on a site with crawlability problems is not going to rank.

The commercial case is straightforward. Sites with unresolved technical issues lose organic search traffic before content or backlinks are ever a factor. Technical SEO determines whether search engines can access and evaluate the site at all. In my experience, fixing the technical layer produces faster ranking improvements than any amount of new content production, because it removes the barriers suppressing what already exists.

When to run one: at minimum annually. After any site migration. After a significant drop in organic traffic or keyword rankings. At the start of any new SEO engagement. The items below are organised into seven categories, in the order I check them.

The 47-Point Technical SEO Audit Checklist

Category 1: Crawlability and Indexation (Items 1–10)

This is where every technical audit starts. If search engines cannot crawl and index a site correctly, nothing else matters. In my experience this category produces the most critical findings, and the most common ones are not obscure edge cases. They are configuration issues that have been silently suppressing SEO performance for months.

1. robots.txt file is correctly configured

The robots.txt file should be accessible at the root domain and must not block important pages from search engine crawlers. A misconfigured robots.txt is one of the most damaging issues I find because it can prevent search engines from accessing entire sections of a site with no visible symptoms. Check via Google Search Console and by directly accessing yourdomain.com/robots.txt.

2. XML sitemap submitted and clean

The sitemap file should be submitted via Google Search Console, contain only indexable URLs, and be kept up to date. Sitemaps containing noindex tags, redirect URLs, or broken pages send conflicting signals and waste crawl budget. A clean sitemap file is the clearest possible signal to major search engines about which URLs matter. This sounds basic but I regularly find sitemaps that have not been updated since a site migration two years prior.

3. No important pages blocked by noindex tags

Use the URL Inspection Tool in Google Search Console to verify that key pages are indexed. Noindex tags left accidentally on important pages after development or migration work are a consistent finding. I once audited a SaaS site where the entire blog category had been noindexed for six months without anyone noticing.

4. Crawl errors reviewed in Google Search Console

Check the Coverage report for server errors (5xx), not found errors (4xx), redirect errors, and pages blocked by robots. Server errors need immediate attention. A 5xx response tells search engine crawlers the site relies on infrastructure that is currently failing, which directly affects crawl frequency and search rankings over time.

5. Crawl budget used efficiently

For sites over a few hundred pages, verify that crawl budget is not being wasted on low-value URLs, parameter pages, or infinite scroll content. The question of how many pages on the site are actually worth indexing is one of the most useful frames for this check. If the answer is significantly fewer than the number currently indexed, that gap is costing SEO performance. Index bloat is one of the most common findings I encounter and one of the most consistently under-prioritised.

6. Orphan pages identified

Any page with no internal links pointing to it is invisible to search engine crawlers navigating the site structure. A Screaming Frog crawl compared against the XML sitemap surfaces orphan pages systematically. On most sites I audit, there are more orphan pages than anyone on the team is aware of.

7. Canonical tags correctly implemented

Every page should have a self-referencing canonical tag. Where duplicate content exists across multiple URLs, the canonical should point to the preferred version. Conflicting canonical signals are particularly common on e-commerce sites with faceted navigation and on sites that have been migrated without a canonical audit.

8. URL parameters handled correctly

Faceted navigation, tracking parameters, and session IDs create multiple URLs for the same content. These generate duplicate content issues and waste crawl budget. Handle via canonical tags, parameter handling in Google Search Console, or noindex depending on the specific case.

9. Pagination handled correctly

Paginated series should either self-canonicalise to the first page or use appropriate markup. Paginated pages without clear signals dilute authority across multiple URLs, which is particularly damaging for category and archive pages on content-heavy sites.

10. Critical content server-rendered, not client-side only

JavaScript-heavy sites need specific attention here. Verify that critical content, headings, body copy, internal links, is present in the initial HTML before JavaScript executes. AI crawlers including GPTBot and PerplexityBot typically cannot execute JavaScript. If important content requires JavaScript to render, it may be invisible to AI tools even when it displays correctly in a browser.

Category 2: Site Architecture and Internal Linking (Items 11–18)

Site structure determines how efficiently search engines navigate the site and how authority flows between pages. This category consistently reveals both quick wins and the kind of structural problems that have been quietly suppressing search visibility for longer than anyone realised.

11. All key pages reachable within three clicks from the homepage

Pages buried more than three clicks deep receive less crawl budget and link equity. A logical site architecture ensures important pages are accessible quickly. Map the click depth of highest-priority pages via Screaming Frog.

12. No broken internal links

Broken internal links waste crawl budget and damage user experience for site visitors. They are more common than most sites realise, particularly on sites with a long content archive. A Screaming Frog crawl surfaces all broken internal links in one pass. Fixing them is a quick win with immediate crawl efficiency benefits.

13. Internal linking reflects topical cluster architecture

Hub pages should link to all cluster pages. Cluster pages should link back to the hub. Related cluster pages should link to each other where the connection is natural. This is the internal linking structure that builds topical authority. The content cluster strategy guide covers this architecture in detail. In audits, I almost always find that the internal linking structure does not reflect the intended topic clusters at all.

14. Descriptive anchor text used throughout

Internal link anchor text should describe the destination page accurately. Both users and search engines benefit from descriptive anchor text. It helps site visitors navigate more confidently and helps search engines understand topical relationships between relevant pages.

15. No redirect chains in internal links

Internal links should point directly to the final destination URL. Redirect chains waste link equity and add latency. After site migrations in particular, internal links are often left pointing to redirect chains rather than updated to point directly to the new URL.

16. Breadcrumbs implemented and marked up

Breadcrumbs improve user navigation and reinforce site structure signals for search engines. BreadcrumbList schema makes them eligible for rich results. On most B2B sites, implementing breadcrumbs with schema is a low-effort, high-signal improvement.

17. Navigation links reflect commercial priorities

Site navigation is the highest-authority internal linking signal on most sites. Ensure primary navigation links to the most commercially important pages. Footer links should include key evergreen pages, not function as a link dump for low-priority content.

18. All URL variants redirect to a single canonical version

Trailing slash versus no trailing slash, www versus non-www, and HTTPS versus HTTP should each resolve to a single consistent version. Any variation that returns a 200 status rather than redirecting creates a duplicate URL and splits link equity across multiple pages.

Category 3: Page Speed and Core Web Vitals (Items 19–26)

Core Web Vitals are a direct ranking factor and a proxy for user experience quality. The 2026 thresholds: LCP under 2.5 seconds, INP under 200ms, CLS under 0.1. Mobile and desktop are measured separately. Google uses the mobile version for indexing and ranking, which means Core Web Vitals failures on mobile pages are a direct ranking factor regardless of how the desktop site performs. This is the category where I most commonly find issues that are well known internally but have never been formally prioritised.

19. Largest Contentful Paint (LCP) under 2.5 seconds

LCP measures how quickly the largest visible content element loads. The most common causes of poor LCP are slow server response time, render-blocking resources, and unoptimised images. Check via Google PageSpeed Insights and Google Search Console's Core Web Vitals report.

20. Interaction to Next Paint (INP) under 200ms

INP replaced FID as a Core Web Vital in 2024 and measures responsiveness throughout the entire page session. Heavy JavaScript execution is the most common cause of poor INP and is particularly prevalent on sites using multiple third-party scripts.

21. Cumulative Layout Shift (CLS) under 0.1

CLS measures visual stability during page load. Common causes: images without defined dimensions, dynamically injected content, and web fonts causing layout shifts before they load. CLS issues are often invisible on fast connections but severe on mobile devices.

22. Server response time under 200ms

Slow Time to First Byte undermines every other page speed metric. Check TTFB via PageSpeed Insights and investigate hosting quality, server-side caching, and CDN implementation. This is one of the fastest wins available when the issue is hosting rather than code.

23. Images optimised and compressed

Large uncompressed images are the single most common cause of slow page loading across the sites I audit. All images should be compressed, served in WebP format, sized to their display dimensions, and lazy-loaded below the fold.

24. Render-blocking resources minimised

JavaScript and CSS files that block the main thread delay First Contentful Paint. Defer non-critical JavaScript and inline critical CSS above the fold. This requires developer involvement but the ranking impact of fixing render-blocking resources is consistently significant.

25. Text compression enabled

Gzip or Brotli compression should be enabled server-side to reduce the size of CSS, HTML, and JavaScript files transferred to the browser. This is a server configuration check that takes minutes to verify and minutes to fix.

26. Core Web Vitals assessed on mobile specifically

Mobile Core Web Vitals data in Google Search Console frequently shows significantly worse performance than desktop, particularly for INP and LCP. Given that Google uses the mobile version for ranking, mobile CWV failures have a direct ranking consequence that desktop-only checks will miss entirely.

Category 4: Mobile and HTTPS (Items 27–32)

27. Site passes mobile usability checks

Verify mobile usability via Google Search Console's Mobile Usability report. Mobile devices now account for around 62 to 64% of all online traffic. Designing for mobile users first is not a preference, it is a search ranking requirement. Common failures: tap targets too small, text too small to read without zooming, content wider than the screen.

28. Mobile version contains the same content as desktop

Google indexes the mobile version. If mobile pages show less content, fewer internal links, or truncated headings compared to the desktop site, rankings will reflect the mobile version. This is particularly common on older sites that implemented a separate mobile site rather than responsive design.

29. HTTPS implemented across the entire site

All pages should be served over HTTPS. Search engines favour secure sites and users are more likely to trust a website displaying a secure padlock in the browser. Any HTTP page accessible without redirecting should be treated as an immediate fix.

30. No mixed content warnings

Pages served over HTTPS that reference HTTP resources generate mixed content warnings in browsers. Check via browser developer tools or Screaming Frog. Mixed content is a common post-migration finding when internal assets have not had their URLs updated to HTTPS.

31. Valid SSL certificate with no imminent expiry

An expired SSL certificate blocks site access entirely for users and signals untrustworthiness to search engines. Set a calendar reminder 60 days before the certificate expiry date. SSL expiry is an embarrassingly simple issue but it has affected client sites I have audited.

32. HTTP to HTTPS redirect is a 301, not a 302

The redirect from HTTP to HTTPS should be a permanent 301 redirect to pass full link equity to the HTTPS version. A temporary 302 redirect does not pass link equity and should be corrected immediately.

Category 5: Duplicate Content and URL Hygiene (Items 33–39)

33. No duplicate title tags or meta descriptions

Title tags and meta descriptions are the first signals both users and search engines encounter in search results. Duplicate title tags across multiple pages dilute topical signals and reduce click-through rate simultaneously. Google Search Console's Page Experience report surfaces title tag duplication. The free SEO tools include a meta description checker that flags duplication across the site. Google Analytics and Google Search Console together surface which pages have the worst CTR, which often maps directly to title tag and meta description quality problems.

34. Duplicate content identified and resolved

Duplicate pages created by the same content appearing across multiple URLs is one of the most common causes of stalled search engine rankings on e-commerce and CMS-heavy sites. The question is whether search engines understand which version to rank, not whether the content is technically identical. Canonical tags are the most scalable solution for parameter-based duplication. Content-based duplication usually requires consolidation.

35. Thin content pages identified

Pages with insufficient content to satisfy user intent rank poorly and can suppress overall site quality signals. The SEO performance impact of thin content accumulates across the entire site, not just on the individual pages that are thin. Google assesses site quality holistically, which means a cluster of low-value pages drags down the search visibility of every other page. The SEO content audit process covers the decision framework for what to do with each thin page.

36. www and non-www resolve to a single version

Both versions should not return a 200 status. One should 301 redirect to the other. The preferred version should be consistent across all internal links and the Google Search Console property.

37. No soft 404 errors

A soft 404 is a page that returns a 200 status code but delivers error content or a blank page. Search engines index these as valid pages. They provide no value and waste crawl budget. Google Search Console's Coverage report surfaces them.

38. URL structure is clean and descriptive

URLs should be short, lowercase, hyphenated, and reflective of page content. Avoid dynamic parameters, session IDs, and irrelevant string patterns in permanent page URLs. URL structure is a minor ranking factor but a significant factor in click-through rate from search results.

39. No unnecessary redirect chains

Every redirect hop adds latency and loses a fraction of link equity. After site migrations, redirect chains of three or four hops are common and should be consolidated to single-step 301s. Screaming Frog's redirect report surfaces all chains in one crawl.

Category 6: Structured Data and Schema (Items 40–44)

Schema markup is increasingly important for both traditional rich results in search engine results pages and AI search visibility. Pages with FAQPage schema are significantly more likely to appear in Google AI Overviews. Structured data markup is the primary mechanism by which you help search engines understand what each page is about beyond its text content. Without it, pages tend to miss rich result eligibility entirely and are passed over by competitors who have implemented it correctly. This is the category most often treated as optional in audits I review. In 2026 it is not optional.

40. Article or BlogPosting schema on all content pages

Article schema should include headline, author, datePublished, dateModified, image, and publisher at minimum. This validates authorship and freshness signals for both traditional search and AI tools. Validate via Google's Rich Results Test.

41. FAQPage schema on pages with FAQ sections

FAQPage schema makes content eligible for rich results and significantly improves the likelihood of being cited in Google AI Overviews. Every page with a FAQ section in this cluster has FAQPage schema for exactly this reason.

42. BreadcrumbList schema on key pages

Breadcrumb schema supports rich results and provides additional site structure signal to search engines. Implement alongside visible breadcrumb navigation, not as a standalone invisible addition.

43. Organization schema at site level

Organization schema defines the brand, its contact information, and its social profiles. It is foundational for entity recognition by both Google and AI tools. Without it, search engines and AI systems have no structured signal about who the site belongs to.

44. Structured data markup validated and error-free

All schema should be validated via Google's Rich Results Test and monitored in Search Console's Rich Results report. Errors in structured data markup can prevent rich results from appearing and, in some cases, generate manual actions.

Category 7: AI Search Readiness (Items 45–47)

Most technical SEO audit checklists still do not cover these three items. I added them because in 2026, AI search visibility is a commercial outcome in its own right. The answer engine optimisation guide covers the content and structural dimension. These three items cover the technical layer.

45. robots.txt does not block AI crawlers

GPTBot, PerplexityBot, ClaudeBot, and Google's AI crawler should be explicitly permitted in the robots.txt file if AI search visibility matters. Blocking AI crawlers is sometimes done deliberately to prevent training data scraping, but it simultaneously prevents these tools from citing the site in AI search responses. The distinction between preventing training scraping and preventing search visibility is not yet standardised, so review the robots.txt file explicitly with this in mind.

46. Critical content is server-rendered

AI crawlers typically cannot execute JavaScript to the same degree as Googlebot. Headings, body copy, structured data, and internal links should all be present in the initial HTML before JavaScript executes. If critical content is loaded client-side only, it may be visible in the browser but invisible to AI crawlers and to Googlebot's first-pass crawl.

47. llms.txt file present where relevant

The llms.txt standard signals to AI crawlers which content is available and how it should be interpreted. For brands actively managing AI search visibility, this is now a technical SEO consideration alongside the XML sitemap and robots.txt. It is not yet universal, but it is the direction the technical layer is heading.

What the Audit Produces in Practice

For Connecteam, a technical audit at the start of the engagement identified cannibalisation, broken internal linking, and AI crawler accessibility issues that were suppressing content already performing well in traditional search. Addressing those structural issues before scaling the content programme contributed to a 62.6% increase in organic traffic and 79.4% growth in AI Overview visibility. The fastest SEO wins I produce for clients consistently come from fixing what already exists rather than creating more content on top of a broken foundation. Read the Connecteam case study.

For Originality.ai, understanding the technical baseline before scaling the content programme made the growth sustainable rather than fragile. The audit identified which existing pages had the strongest authority signals, which needed consolidation, and which technical barriers were preventing new content from compounding correctly. Organic traffic grew from 278,000 to 1.18 million sessions, a 324.7% increase, while referral domains grew from 1,098 to 9,942. Read the Originality.ai case study.

The pattern is consistent. The sites that compound their organic growth are almost never the ones that need more content. They are the ones who have removed the technical barriers, suppressing what they already have.

How Often to Run a Technical SEO Audit

A full 47-point technical audit should be run at a minimum annually. High-output sites publishing new content regularly benefit from quarterly audits. An SEO audit checklist approach to monthly monitoring, using Google Search Console to check for new crawl errors and search console alerts rather than running a full site audit tool crawl, keeps technical health manageable without requiring a full audit every month.

Trigger-based audits should run immediately after any site migration, any significant drop in organic traffic, and following any major Google algorithm update that affects performance. The most expensive technical SEO problems are almost always ones that have been present for months without anyone on the team knowing.

The Bottom Line

Technical SEO problems are invisible until they cost rankings. By the time they show up in a traffic report, they have usually been suppressing performance for months.

The 47 items above are the checklist I run on every site I audit. Start with crawlability and indexation. Fix the foundation before scaling content production. The brands that compound their organic growth are almost never the ones that need more content. They are the ones who have removed the technical barriers holding back what they already have.

If you want this process run on your site with a prioritised action plan, the Technical SEO Audit is where to start.

For a high-level view of where your site currently stands before committing to a full audit, get a free SEO audit, and I will tell you where the most urgent issues are.

Frequently Asked Questions About Technical SEO Audits

What is a technical SEO audit?

A technical SEO audit is a structured review of a website's infrastructure to identify issues that prevent search engines from crawling, indexing, and ranking its pages. It covers crawlability, site architecture, page speed, Core Web Vitals, mobile performance, HTTPS, structured data, and internal linking. It is distinct from a content audit, which evaluates the content itself. Both are necessary components of a complete SEO strategy.

How long does a technical SEO audit take?

A full 47-point audit of a mid-sized site typically takes one to two days of specialist time. Enterprise sites with thousands of pages take longer. The audit itself is only part of the time commitment: translating findings into a prioritised action plan and working through implementation adds further resources. If you want an audit with a documented action plan rather than a list of issues, the Technical SEO Audit service covers the full process.

What tools do you need for a technical SEO audit?

The core toolset: Google Search Console for indexation, crawl errors, and Core Web Vitals data; Screaming Frog for full site crawls, broken link identification, and redirect mapping; Google PageSpeed Insights for performance analysis; and Google's Rich Results Test for schema validation. For larger or more complex sites, Screaming Frog Log File Analyser adds the server log dimension that separates thorough audits from surface-level ones.

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

A technical SEO audit reviews the infrastructure layer: whether search engines can find, access, and evaluate the site correctly. An SEO content audit reviews what is on the pages: whether the content matches search intent, whether pages are cannibalising each other, and whether existing content needs refreshing or consolidating. Technical issues are fixed before content issues because a broken technical foundation undermines content performance regardless of quality.

What is the most important thing to fix in a technical SEO audit?

Start with crawlability and indexation. If search engines cannot reach and index important pages correctly, no other optimisation can produce its full potential return. In practice, this means checking robots.txt, sitemap health, crawl errors, and canonical tag implementation before anything else. The three issues I find most consistently are index bloat, broken internal links, and Core Web Vitals failures on mobile.

How does a technical SEO audit affect AI search visibility?

The same technical foundations that help Google crawl and evaluate a site also determine whether AI tools like ChatGPT, Perplexity, and Google AI Overviews can access and cite it. Schema markup is increasingly how AI search systems identify what to cite. robots.txt controls whether AI crawlers can access the site at all. Server-rendered content ensures AI bots see the same page as human visitors. Items 45 to 47 in this checklist address the AI-specific technical layer specifically.

How much does a technical SEO audit cost?

A professional technical SEO audit from an experienced consultant typically ranges from £500 for a focused review of a small site to several thousand pounds for a comprehensive audit with full implementation guidance. The GWContent Technical SEO Audit covers the full 47-point process with a prioritised action plan and starts at £797.