Technical SEO is the set of fixes that allow a search engine to reach a page, read it and keep it in its index. It is not about what is written on the page. It is about whether anything can get to the page and take it away.
Most guides describe it as a list of boxes to tick: robots.txt, sitemaps, canonicals, Core Web Vitals, structured data, log file analysis. On 26 September 2026 I measured the six pages that rank on the first page of Google UK for "technical seo" (720 searches a month, DataForSEO, Google UK, September 2026). None of them passes the checklist it describes.
The six pages that explain technical SEO in the UK are not technically clean
I ran the six URLs from the first page of Google UK through the DataForSEO On-Page API with JavaScript execution switched off, reading the HTML exactly as a crawler that does not render receives it. Crawl of 26 September 2026, one fetch per page. Google's own documentation, the technicalseo.com tools homepage and the YouTube result are excluded.
| Page on page one for "technical seo" (position) | On-page score | HTML markup errors | Render-blocking resources | HTML weight | Images without alt |
|---|---|---|---|---|---|
| semrush.com/blog/technical-seo/ (2) | 100 | 8 | 3 | 283 KB | no |
| ahrefs.com/seo/technical-seo (3) | 93.41 | 0 | 8 | 1,086 KB | yes |
| searchengineland.com/guide/what-is-technical-seo (4) | n/a | n/a | n/a | 403 error returned to the crawler | n/a |
| mtu.edu (technical-seo) (5) | 98.17 | 8 | 0 | 108 KB | no |
| screamingfrog.co.uk/technical-seo/ (6) | 97.07 | 2 | 1 | 171 KB | yes |
| wpseoai.com (what-is-technical-seo) (8) | 100 | 0 | 2 | 527 KB | no |
All five pages that could be read have at least one render-blocking resource or a markup error. Two have images without an alt attribute. The page with the lowest score in the set, 93.41, is third. The same page is also the heaviest, over 1 MB of HTML alone. The fourth result refused our crawler outright with a 403 and still ranks, because what matters is what it serves to Googlebot.
This does not mean the technical side is irrelevant. It means it works as a threshold, not as a race. Above the threshold the engine reads you and other things decide your ranking. Below it you do not exist, and no content will save you. The useful work is finding where that line sits, which is lower than the checklists suggest, and then stopping optimising everything else.
The faults that wipe you out are few and you can spot them by the symptom
There is an order of magnitude between a problem that slows you down and a problem that deletes you. An LCP of 3.4 seconds costs you a few positions. A noindex left switched on after going live removes you from the index. In the technical reviews we carry out on company websites, the second kind are almost always few and almost always trivial.
The table below is the one I start from, because the symptom you see never appears where the fault is. Read it from the top: the first check that fails is the problem, the rest can wait.
| Symptom | Most common cause | Where to check it in two minutes |
|---|---|---|
| The page does not appear even when you search its exact title | Meta robots noindex, or a block in robots.txt | URL Inspection in Search Console, "Indexing allowed?" line |
| Search Console says "Discovered - currently not indexed" | Page reachable only from the sitemap, no internal link pointing to it | Look for inbound links with a desktop crawler |
| Page indexed but Google shows a different URL | Canonical pointing elsewhere, or a duplicate with parameters | Page source, rel="canonical" tag |
| Traffic collapsed after a redesign | Old URLs not redirected, or redirect chains to the homepage | List of old URLs from the Pages report, requested one by one |
| The page shows in the browser but not in Google's test | Content injected with JavaScript after load | Compare source HTML with rendered HTML |
| Stable impressions and falling clicks | Not a technical fault: the SERP has changed above you | Performance report, comparison by query |
The last row is the one that saves the most time. A drop in clicks with stable impressions is hardly ever technical, and hunting for the cause in the code takes weeks. If you want the full picture of possible causes, we have gathered it in the SEO audit guide.
Crawling, rendering, indexing: the three points where a page gets lost
Between publishing and appearing in the SERP there are three distinct steps, and a page can fall at each one for different reasons.
Crawling. Googlebot has to be able to reach the URL. It is stopped by a robots.txt that blocks the directory, a repeated network error, or a 404 error returned only to the bot. Note that a robots.txt block does not remove the page from the index, it only prevents it from being read: if it has external links it can stay in the SERP without a description. To really remove a page you need noindex, which means the crawler must be able to read it.
Fetching and rendering. Googlebot fetches the first 2 MB of a supported file, as documented by Google Search Central. On a 283 KB HTML file you never get near the limit; on a product page generated by a template with thousands of useless nodes it can happen, and one of the pages in the table above is already past half of it. Then comes the stage where JavaScript is executed, which is what separates Google from almost everyone else.
Indexing. The document is evaluated and, if it is judged useful enough, stored. Here the canonical decides which version is kept and which is discarded. According to the SEO chapter of HTTP Archive's Web Almanac 2025, 67% of mobile pages have a canonical, and in 0.71% of cases the value in the raw HTML differs from the one in the rendered DOM. It is a small percentage on a global scale, and still the kind of inconsistency that on a single site produces months of the wrong pages in the SERP. When the canonical is set badly the practical result is duplicate content competing with itself.
Crawl budget is almost certainly not your problem
It is the chapter that appears in every guide and that almost no reader running a business website needs. Google gives two thresholds in its documentation on managing crawl budget: sites with more than a million unique pages whose content changes weekly, and sites with more than 10,000 unique pages whose content changes daily. Below those sizes the same page says that keeping the sitemap up to date and checking the index coverage report is enough, and it calls those numbers "a rough estimate", not exact thresholds.
The company websites we work on typically have between 40 and 400 pages. Time spent optimising crawl frequency on a site like that is time taken away from the two things that do move rankings: internal links and page content. This part is only worth reading if you run an ecommerce site with faceted navigation, where filter combinations generate tens of thousands of URLs nobody asked for.
Core Web Vitals: the real thresholds and how much they actually weigh
The thresholds Google publishes on web.dev are three: LCP within 2.5 seconds, INP within 200 milliseconds, CLS of 0.1 or less. The detail that changes how you work on them is another one: the assessment is made at the 75th percentile of page loads, separately for mobile and desktop. The average does not count; what counts is that three visits out of four are inside the limit. A site that is fast for someone on full fibre in London and slow for someone on 4G on the M6 is judged on the second case.
On how much they weigh, the Web Almanac 2025 figures help put things in proportion: in June 2025, 48% of sites had a good overall assessment on mobile and 56% on desktop. That is a worldwide measurement across the whole HTTP Archive dataset. If half the web is below the threshold and half the web ranks anyway, Core Web Vitals are not an on/off switch. They are a tie-breaker that counts when two pages are equal on everything else, which is exactly how Google has always described them. The practical side is in our guide to page speed, together with the things that really move the needle: uncompressed images, fonts loaded from external domains, plugins that inject CSS on every page.
Also from the Web Almanac 2025: 91.5% of mobile pages are served over HTTPS, 70% have an H1, the median share of images with an alt attribute stops at 60%, and 15% of the alt attributes present are empty. These are the basics, and a quarter of the web still does not have them.
AI crawlers do not execute JavaScript, and that changes the priorities
The study carried out by Vercel with MERJ on bot traffic across Vercel's network, published in January 2025 and covering the previous month, measured something worth keeping in mind: none of the main AI crawlers renders JavaScript. GPTBot, ClaudeBot, the Meta and ByteDance crawlers and PerplexityBot read the HTML and nothing else. Googlebot and Gemini, on the other hand, do execute JavaScript.
The other numbers from the same study: in the month observed Googlebot made 4.5 billion requests, GPTBot 569 million, ClaudeBot 370 million, AppleBot 314 million and PerplexityBot 24.4 million. And 34.82% of ChatGPT's requests hit pages that did not exist, against 34.16% for Claude. These are measurements on the Vercel network, so on sites that are mostly American and built with JavaScript frameworks: they are not a picture of the web as a whole, but the rendering part is a property of the crawler, not of the sample.
The practical consequence is clear-cut. If your page content only appears after JavaScript has run, Google sees it and ChatGPT does not. On a WordPress brochure site the problem hardly ever comes up. It comes up on product configurators, on tabs loaded via AJAX, on sites built in React without server-side rendering. The rest of the reasoning, including what you can do to be cited in generative answers, is in GEO and AI Overviews.
One figure shows how little the market has moved: again from the Web Almanac 2025, only 4.2% of robots.txt files on mobile mention gptbot and 3.4% mention claudebot, and just 2.1% of sites have an llms.txt file. The llms.txt file, incidentally, is not supported by any engine that says so publicly.
Structured data: what it does and what it does not do
Structured data is not a ranking factor. It makes explicit to a machine what is obvious to a human reading the page: that this number is a price, that this date is an event date, that this block is a question with its answer. The measurable benefit is access to rich results in the SERP, which raise click-through rate at the same position.
The second benefit, talked about less, concerns systems that read without seeing. A model that has to extract the price from a product page finds it in the markup with certainty and in the text by inference. The types that cover 90% of the business sites we see are five: Product, LocalBusiness, Article, FAQPage, BreadcrumbList. Everything else is fine-tuning. How to implement them is covered in the guide to schema markup.
The order to fix things in on a 200-page site
This is the part missing from the big tool vendors' guides, because they are written for sites of a different order of magnitude. On a company website the order below reflects the ratio between what a fix costs and what you risk if you skip it.
| Fix | What you risk if you skip it | When it stops being a priority |
|---|---|---|
| Check that no useful page is set to noindex or blocked | Total absence from the index | Never, check again after every release |
| 301 redirects for old URLs after a redesign | Loss of your entire ranking history | After the first month from the migration |
| A consistent canonical on every page | Google chooses for you which version to show | When the CMS generates it automatically and you have checked it |
| Internal links that reach every useful page | Pages stuck in "Discovered - currently not indexed" for months | Never, it grows with the site |
| LCP under 2.5 seconds on landing pages | A few positions when pages are otherwise equal | When the commercial pages are sorted |
| Structured data on the five main types | No rich results in the SERP | When Product and LocalBusiness are validated |
| Server-side rendering | Invisibility to AI crawlers | Straight away if the site is WordPress or another server-side CMS |
| Server log analysis, crawl budget, edge SEO | Nothing, below 10,000 pages | Straight away, unless you manage a huge catalogue |
The first four rows can be checked in half a day with Google Search Console and a desktop crawler such as Screaming Frog. The others are projects. If even one of the first four is broken, the rest are pointless.
In a real project, the lever was not technical
Macropix is a Milan manufacturer of custom LED screens, with more than five thousand installations worldwide. When the project started, in 2020, the site did not appear for any category keyword in its sector. The result we talk about most is not first place on Google Italy for "ledwall", a keyword with 4,400 monthly searches in Italy: it is the line for "monitor pubblicitario" (advertising display), which went from position 88 to position 2. Position 88 is the ninth page of Google, which means zero traffic.
That jump did not come from a change to the code. It came from a well-written page on a subject the company had something to say about, published on a site that was already readable. The technical part was the prerequisite, not the lever. The full account of the method and the numbers is in the case study on SEO for manufacturing, and the other projects we work on are collected on the projects page.
The reverse holds just as well: on other projects we have seen excellent pages stay invisible for months because of a noindex forgotten at release. The same line of code that gains you nothing when it is right loses you everything when it is wrong. That is why the technical check should be done first and then almost forgotten, not done all the time. If you would rather have someone else do it, it is part of how we set up an SEO project.
For the rest, technical SEO is one skill within a broader job: if you are starting from scratch it is better to understand first what SEO is and how the three areas fit together, then come back here. And if the question is which signals really weigh on rankings, we have covered it in the articles on ranking factors and on on-page optimisation.
Frequently asked questions about technical SEO
Technical SEO is the set of changes to a website's infrastructure and code that allow a search engine to reach a page, read it and keep it in its index. It covers robots.txt, canonicals, redirects, internal link architecture, loading speed, rendering and structured data. It is not about the text on the page, it is about whether the page can be reached.
Technical SEO works on the conditions of access: whether the crawler reaches the page and understands it. On-page SEO works on the content of the page once it is accessible: title, heading structure, match with search intent, contextual internal links. The first is a yes-or-no prerequisite, the second decides the position among pages that are all accessible.
Yes, but with a modest weight and as a tie-breaker. The thresholds published by Google are LCP within 2.5 seconds, INP within 200 milliseconds and CLS of 0.1 or less, assessed at the 75th percentile of page loads. In June 2025, according to HTTP Archive's Web Almanac, only 48% of sites had a good overall assessment on mobile: half the web is below the threshold and ranks anyway.
The four checks that can wipe out traffic, namely noindex, robots.txt blocks, canonicals and redirects, should be repeated after every release to production and after every major CMS or plugin update. A full check with a desktop crawler makes sense twice a year on a stable site, and always before and after a migration.
Not for the diagnosis: Google Search Console and a desktop crawler are enough to find almost all problems on a site of a few hundred pages. For the fix, it depends. On WordPress most changes can be made from the dashboard or an SEO plugin. On a custom site, on an ecommerce site with faceted navigation or when server-side rendering is needed, you will not get anywhere without someone who can touch the code.
One thing the industry rarely says: basic technical SEO is now done by the CMS. That 67% of mobile pages with a canonical was not put there by a consultant, it was put there by a plugin installed once and never touched again. The value of technical work has moved to where the plugin does not reach: migrations, custom-built sites, catalogues with thousands of filter combinations. If your site is an up-to-date WordPress install with a well-configured SEO plugin, your problem is probably not technical. That is only half good news, because it means the work left is the hard part.
