Technical SEO Checklist: A 2026 UK Guide

A technical SEO checklist is the implementation list: the things that need to be true about your website before content and links can do anything for you. It is not the same as an audit, and confusing the two is why a lot of technical work gets paid for twice. Below is the checklist in the order the work depends on, with the thresholds Google publishes and the free tools that test each item.

Checklist or audit: which one you actually need

An audit diagnoses an existing site. You run one when something has gone wrong, when traffic has dropped, or before and after a relaunch, and the output is a list of defects specific to that site. A technical SEO checklist is the other direction: a standing list of conditions you work through and keep true, whether or not anything is currently broken. You use the checklist to build and maintain. You use the audit to investigate. A technical SEO audit checklist is simply this list run against a live site, with every failure written down and ranked.

If your question is "what is wrong with my site", start with our website audit checklist, which covers the diagnostic pass including the technical, structural and content items. If your question is "what should be true about any site we ship", you are in the right place. In practice most UK businesses need both, in that order, and then the checklist becomes the thing you re-run quarterly.

What is technical SEO?

Technical SEO is everything that determines whether a search engine can reach your pages, understand them and serve them, as distinct from whether they deserve to rank. It is a hygiene layer. It very rarely wins you a competitive term on its own, and it routinely stops you from winning one. That asymmetry is the whole argument for having a checklist: the upside is capped, the downside is not, and the failures are silent. If you want the crawl, index and rank pipeline explained from the start, our guide to how SEO works covers it.

The other thing worth saying plainly is that most of it is boring and most of it is cheap. On the majority of UK small business sites we look at, the technical problems are a handful of misconfigurations that take an afternoon, not a rebuild.

It also now covers AI search. Google's guide to optimising for its generative AI features says the way Google Search finds and processes your pages remains the core of how its AI systems access your content, and that existing technical SEO best practices continue to be worthwhile. There is no second list for AI Overviews and AI Mode. This is the list.

The six technical areas that matter

Everything in the detailed list below belongs to one of these. They are in dependency order: there is no point optimising a page that cannot be crawled.

Crawlability

Can a search engine reach every page you care about, without hitting a blocked path, an infinite parameter loop, a firewall rule or a chain of redirects that gives up before it arrives.

Indexation control

Are the right pages indexed and the wrong ones not. Thin tag archives, filtered listing views and staging copies are the usual offenders, and they dilute everything around them.

Site architecture

How many clicks from the homepage to your money pages, whether internal links point where the value should flow, and whether the URL structure reflects how the site is actually organised.

Page experience: speed, mobile and HTTPS

Measured on real devices on real connections, not on a desktop on office wifi. Google's "good" thresholds are a Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less, plus a mobile version that carries the full page.

Structured data

Machine readable markup that tells search engines what a page is, and makes it eligible for rich results such as breadcrumbs and product details. Google says it is not required for its AI features and there is no special markup for them, so treat it as eligibility, not a ranking lever.

Duplication and canonicals

One canonical URL per piece of content, consistently. Trailing slashes, www and non www, HTTP and HTTPS, and print views all quietly create duplicates.

The technical SEO checklist, in order

Before you start, verify the site in Google Search Console and Bing Webmaster Tools. Almost every check below reads from one of them, and neither costs anything.

1. Crawlability

• Fetch your robots.txt and read it line by line. Confirm nothing important is disallowed. A blanket disallow left over from a staging build is the single most destructive item on this list. Search Console's robots.txt report shows the version Google last fetched and any parsing problems.
• While you are in robots.txt, check what it says to AI crawlers and that it says what you intend. OAI-SearchBot, PerplexityBot and Claude-SearchBot fetch pages for AI search answers, while GPTBot and ClaudeBot collect training data, so blocking one family is not the same as blocking the other. Google-Extended is a robots.txt token rather than a separate crawler, and Google's crawler documentation says it does not affect inclusion in Google Search.
• Check that your CDN, firewall or hosting bot protection is not turning crawlers away. Google lists this alongside robots.txt, and it is the failure robots.txt cannot show you: the file says "allow" while a security setting serves a challenge page instead.
• Confirm an XML sitemap exists, is listed in robots.txt or submitted in Search Console, and contains only indexable canonical URLs. A sitemap full of redirects and noindexed pages sends mixed signals about which URLs you actually want in the index.
• Check for redirect chains and loops. Every hop is a chance to lose the request, and chains of three or more are common after a site has been through two rebuilds.
• Confirm your 404 page returns an actual 404 status code, not a 200 with an apology on it. Google's documentation on how HTTP status codes affect its crawlers explains that an error page served with a 200 shows up in Search Console as a soft 404.
• Read the Crawl stats report in Search Console for server errors and response time. A site that is fast when you test it and slow at 7pm has a hosting problem, not an optimisation problem.

One thing you can usually stop worrying about is crawl budget. Google's crawl budget guide is written for large sites, roughly a million or more unique pages changing weekly, or 10,000 or more changing daily. On a typical small business site the problem is rarely how much Google crawls. It is whether the pages it crawls are the right ones.

2. Indexation

• Compare the number of pages you want indexed with the number the Page indexing report in Search Console shows as indexed. A large gap in either direction is the finding.
• Noindex thin archives: author pages on a single author site, empty tag archives, date archives, internal search results.
• Confirm no page carries both a noindex directive and a canonical pointing elsewhere. The combination sends contradictory instructions and the resolution is unpredictable.
• Give each paginated page its own self referencing canonical. Google's pagination guidance says not to use the first page of a sequence as the canonical page, so a category whose page two onwards all point at page one is hiding whatever is only listed deeper.
• Run URL Inspection on your three most important pages and check that Google's chosen canonical matches the one you declared. When they differ, Google has decided another URL is the real version of your page.
• If your site relies on JavaScript to show content or links, compare the raw HTML with the rendered page in URL Inspection's live test. Google processes JavaScript in three phases (crawling, rendering and indexing), and anything that only appears after rendering depends on that second phase working.
• Search for your staging domain in Google. Finding it there is more common than anyone admits.

3. Architecture and internal linking

• Map the click depth from your homepage to your most commercially important pages. Three clicks or fewer is the working target.
• Find orphan pages, meaning pages with no internal links pointing at them at all. They are usually old landing pages that still convert.
• Check that your navigation links to the pages that make money, not just to the pages that are easy to categorise.
• Use descriptive anchor text. "Click here" tells a search engine nothing about the destination.
• Give every page a clear heading outline: one H1 that names the page, then H2 and H3 headings in order. Google can cope with imperfect markup, but readers, screen readers and parsers all navigate a long page by its headings.
• On sites more than two levels deep, add breadcrumb navigation with BreadcrumbList markup. It gives visitors and search engines the same path back up the hierarchy.

4. Page experience: speed, mobile and HTTPS

• Measure with field data from real users where you have it, not only with a lab test. Search Console's Core Web Vitals report and PageSpeed Insights both show field data when your site has enough traffic.
• Work to Google's published thresholds for a good experience, measured at the 75th percentile of page loads: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less.
• Fix Largest Contentful Paint first. On most WordPress sites the culprit is an unoptimised hero image or a render blocking font.
• Serve images in a modern format at the size they are displayed, not at the size they were uploaded.
• Reserve space for images, embeds, adverts and cookie banners so the layout does not jump as they load. That one habit fixes most layout shift problems.
• Audit plugins for what they load on every page. A slider plugin used on the homepage should not be loading its assets on every blog post. Our WordPress speed optimisation guide covers the plugin and caching side in detail.
• Confirm caching is actually active in production, and that your test is not being served a cached page while your customers are not.
• Check that the mobile version carries the same content, headings, structured data and internal links as desktop. Google uses the mobile version of a site, crawled with its smartphone agent, for indexing and ranking, so anything you hide on mobile is effectively hidden from Google.
• Remove pop-ups that cover the main content on arrival. Google's guidance on intrusive interstitials and dialogs recommends unobtrusive banners instead.
• Serve every page over HTTPS, redirect HTTP in a single hop, and clear any mixed content warnings where a secure page still loads an insecure image or script. Search Console has an HTTPS report for exactly this.

5. Structured data

• Organisation markup on the site, with consistent name and contact details.
• Article markup on editorial content, Product on products, LocalBusiness where you serve a place, BreadcrumbList on deep pages, and FAQPage only where the questions and answers are visible on the page. Note that Google stopped showing FAQ rich results on 7 May 2026, so FAQ markup now helps machines read the page rather than earning a search feature.
• Validate it with the Rich Results Test or the Schema Markup Validator, then validate the rendered page rather than the source. Markup that is correct in the template and broken after a plugin filters it is a common and invisible failure.
• Never mark up content that is not visible to the reader.
• Do not add markup in the hope of AI visibility. Google's generative AI guide says structured data is not required for its AI features and that there is no special schema.org markup to add. Its value is rich result eligibility, which is reason enough.

6. Duplication and canonicals

• Pick one host, one protocol and one trailing slash convention, and redirect everything else to it in a single hop.
• Confirm every page has a self referencing canonical unless there is a deliberate reason otherwise.
• Check that URL parameters from filters and tracking are not generating indexable duplicates.
• If you run any near duplicate location or service pages, either make them genuinely different or consolidate them.

A one-page technical SEO checklist you can copy

If you want a technical SEO checklist template for a spreadsheet, this is it: one row per check, the free tool that tests it, and how often to re-run it. Work down the rows in order, because each one assumes the rows above it already pass.

The five technical problems we find most often

These recur across UK small business sites regardless of sector or platform, and between them they account for most of the recoverable loss we see. The content and strategy equivalents are in our guide to common SEO mistakes.

• A staging directive still live in production. Either a blanket robots.txt disallow or a site wide noindex left switched on after launch. It is rare, it is catastrophic, and it is a ten second check.
• A sitemap that lists redirects and noindexed URLs. Usually a plugin generating from the wrong source after a slug change. It does not break anything visibly, it just tells search engines a less accurate story about which pages matter.
• Redirect chains from successive rebuilds. Three hops from an old URL to the current one, each added by a different agency, each individually sensible. Collapse them to a single hop.
• Images uploaded at camera resolution. A four megabyte hero image scaled down in CSS is still a four megabyte download, and it is usually the entire Largest Contentful Paint problem on its own.
• Orphan pages that used to convert. An old landing page that no longer appears in navigation, still ranks, still gets enquiries, and receives no internal links at all. Re-linking it costs nothing.

Free tools that cover most of the checklist

You do not need a paid suite to work through this list on a small or medium site. These cover almost every row of the table above:

• Google Search Console: the Page indexing, URL Inspection, Sitemaps, robots.txt, Core Web Vitals, HTTPS and Crawl stats reports. Google's generative AI guide also points site owners to its Generative AI performance report for how pages perform in AI Overviews and AI Mode.
• Bing Webmaster Tools: the equivalent view of how Bing crawls and indexes the site.
• PageSpeed Insights: field data from real Chrome users where your site has enough traffic, plus a Lighthouse lab test that points at the specific resources slowing the page down.
• Rich Results Test and Schema Markup Validator: the first tells you which Google rich results a page is eligible for, the second checks the markup against schema.org generally.
• A desktop crawler: for redirect chains, orphan pages, click depth and duplicate titles. Free versions usually cap the number of URLs per crawl, which is still enough for most small business sites.

AI assistants are useful for interpreting what these tools find, explaining a robots.txt rule or drafting a redirect map. They cannot see your Search Console data or your server, and Google states that no third-party tool has access to its internal ranking or AI systems. Use them to read findings, not to generate them.

Technical SEO and AI search results

Google's position is that there is nothing extra to do for its AI features. Its documentation on AI features says there are no additional requirements to appear in AI Overviews or AI Mode, and the generative AI guide adds that a page must be indexed and eligible to show with a snippet. So every crawlability and indexation item above is also an AI visibility item, and a page that fails one of them is invisible to both.

The same guide is blunt about what you can skip for Google: llms.txt files and other "special" markup, which Google Search ignores; breaking content into small "chunks"; and adding structured data in the belief that AI features need it. Our llms.txt guide covers where those files might still matter for other services, and our AI search optimisation playbook covers the content side.

What does carry over is clarity. A sensible heading hierarchy, the answer close to the heading it belongs to, and content that is present on the page rather than hidden behind a click help readers and parsers alike. Google can process JavaScript as long as it is not blocked, but the crawler documentation from OpenAI, Perplexity and Anthropic says nothing about rendering, so treat the raw HTML as the baseline every crawler sees. That is also why the structured data section says to validate the rendered page rather than the template: a plugin that strips your markup at output is a problem you cannot see in the source and cannot detect by reading the theme.

What needs a developer and what does not

This matters more than the list itself, because the usual failure mode is a business owner working through a technical checklist, reaching item four, and stopping for six months waiting for a developer.

You can do without help: reading robots.txt, checking indexed page counts, finding redirect chains with a free crawler, resizing images, auditing plugins, noindexing thin archives through your SEO plugin, and writing better internal links. That is most of the list and most of the value. On WordPress, most of it happens inside your SEO plugin, and our guide to SEO on WordPress walks through the settings that matter.

You need a developer for: server level redirect rules, CDN and firewall settings that block crawlers, fixing render blocking resources in a theme, structured data that the theme does not support, JavaScript that hides content from the initial HTML, anything involving the hosting stack, and anything that touches the checkout on an ecommerce site. If your site is mid rebuild or about to move, the rules are different again and our guide to website migration SEO covers that case specifically.

How often to run it

Quarterly is right for most UK small and medium sites, plus an immediate pass after any of the following: a theme change, a plugin added that touches templates or caching, a hosting move, a URL structure change, or a redesign of any size. Those five events cause the overwhelming majority of technical regressions we find, and all five are things a business does deliberately and then forgets to check afterwards. A brand new site or a full relaunch runs to a different sequence again, which our new website SEO checklist covers from launch day through the first month.

If you need a technical SEO roadmap rather than a list, the running order above is the roadmap: crawlability first, then indexation and architecture, then page experience, structured data and duplication. Fix each layer before you spend time on the one above it.

One practical note on scheduling it. Put the quarterly pass in the calendar rather than leaving it to be triggered by a traffic drop, because the whole point of a checklist is that it catches things before they cost you anything. A pass that only ever happens after a problem is an audit with extra steps.

For the specifics of individual directives, Google's own documentation on robots.txt is the authoritative reference and worth reading before you change anything. If you serve a local area, the local SEO checklist is the natural companion to this one. If you would rather have the list worked through for you, the broader strategy sits on our SEO service page, and WordPress sites specifically are covered by our WordPress SEO service.

FAQ