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.
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.
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 technical SEO actually covers
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.
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.
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 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.
Speed and Core Web Vitals
Measured on real devices on real connections, not on a desktop on office wifi. Largest Contentful Paint and Interaction to Next Paint are the two that usually need work on WordPress sites.
Structured data
Machine readable markup that tells search engines what a page is. It does not lift rankings directly, but it is increasingly what decides whether you are quoted in an AI answer or ignored.
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
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.
- Confirm an XML sitemap exists, is listed in robots.txt, and contains only indexable canonical URLs. A sitemap full of redirects and noindexed pages actively wastes crawl budget.
- 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.
- Check server response times under load. A site that is fast when you test it and slow at 7pm has a hosting problem, not an optimisation problem.
2. Indexation
- Compare the number of pages you want indexed with the number Search Console reports 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.
- Check that pagination is handled sensibly and that page two onwards is not competing with page one.
- 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.
4. Speed and Core Web Vitals
- Measure with field data from real users where you have it, not only with a lab test.
- 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.
- 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.
- Confirm caching is actually active in production, and that your test is not being served a cached page while your customers are not.
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, FAQPage where you genuinely have questions and answers on the page.
- Validate it, 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.
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.
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.
- 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 makes every crawl less efficient than it should be.
- 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.
Technical SEO and AI search results
One thing has genuinely changed in the last two years. When an AI assistant or an AI summary answers a question, it has to parse your page quickly and confidently, and the pages that get quoted tend to be the ones with clean heading structure, visible answers near the relevant heading, and accurate structured data. Content rendered only after JavaScript execution, or buried in a tab that has to be clicked, is far less likely to be picked up.
This does not add new items to the checklist so much as raise the stakes on the ones already there. Crawlability, clean markup and a sensible heading hierarchy were always worth having. They are now the difference between being the source of an answer and being invisible behind one. It is also the reason the structured data block above 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.
You need a developer for: server level redirect rules, fixing render blocking resources in a theme, structured data that the theme does not support, 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.
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, and the broader strategy sits on our SEO service page.
FAQ
What does technical SEO include?
Crawlability, indexation control, site architecture and internal linking, speed and Core Web Vitals, structured data, and duplication and canonical handling. In short, everything that determines whether a search engine can reach, understand and serve your pages, as opposed to whether those pages deserve to rank. Content quality and links are a separate discipline that technical work enables rather than replaces.
How do you do technical SEO?
Work in dependency order. Confirm pages can be crawled, then that the right ones are indexed and the wrong ones are not, then that internal linking and architecture point value at your commercial pages, then speed, then structured data, then duplication. Optimising a page that cannot be crawled is wasted effort, which is why the running order matters as much as the items.
What is the 80/20 rule for SEO?
The idea that a small proportion of the work delivers most of the result. On the technical side specifically, the high value twenty percent is usually robots.txt and sitemap correctness, removing redirect chains, noindexing thin archives, fixing Largest Contentful Paint, and making internal links point at the pages that make money. Most of the remainder is refinement.
What tools do I need for a technical SEO check?
Search Console for indexation and field performance data, a crawler to find redirect chains and orphan pages, a page speed tool that reports real user field data rather than only lab scores, and a structured data validator run against the rendered page. Most of the checklist can be completed with free tools; paid crawlers mainly save time on larger sites.
How often should I run a technical SEO checklist?
Quarterly for most sites, plus an immediate pass after a theme change, a plugin that touches templates or caching, a hosting move, a URL structure change, or a redesign. Those five events cause most technical regressions, and each one is something a business does on purpose and then forgets to verify afterwards.
Does technical SEO matter for a small website?
Yes, but the ceiling is low and the floor is very low. Technical work rarely wins a competitive term on its own, and it routinely prevents you from winning one. On a small site the whole list is usually an afternoon of work, and the most common findings are a leftover staging directive, a sitemap full of redirects and an unoptimised hero image.
