Technical SEO Foundations: Why Good Content Doesn’t Rank

There is a particular frustration that brings marketers to this question. The content is good. It is genuinely good, better than the pages outranking it, researched and written and edited to a standard the competition has not matched. And it will not move. Rankings sit flat or drift down, and every instinct says write more, write better, when the content was never the problem.

The problem is underneath it. Technical SEO is the foundation the content sits on, and a broken foundation caps everything above it no matter how good that content is. Google has to be able to reach the page, read it, index it and judge it fast enough to serve before any of the writing matters. When one of those fails, the page does not get a fair hearing, and no amount of editing fixes a problem that was never about the words. This is the part of SEO a content audit cannot see, because a content audit looks at the content.

What follows is the four foundations in the order they matter, and then the part most guides skip: how to work out which one is actually your blocker, rather than fixing the one you can see.

Core Web Vitals and page experience

Page experience is Google’s measure of how it feels to use your page, and Core Web Vitals are the three metrics at the centre of it. They have been a confirmed ranking signal since 2021, and they are the foundation most often misreported, so it is worth getting the current figures exactly right.

There are three. Largest Contentful Paint measures loading: how long until the largest visible element, usually a hero image or headline, finishes rendering. The good threshold is under 2.5 seconds. Interaction to Next Paint measures responsiveness: the lag between a user tapping or clicking and the page reacting. The good threshold is under 200 milliseconds. Cumulative Layout Shift measures visual stability: how much the page jumps around as it loads, the thing that makes you tap the wrong button because content shifted under your thumb. The good threshold is under 0.1.

Two things about these thresholds matter more than the numbers themselves, and both are where teams go wrong.

The first is a correction. You will read in a lot of 2026 guides that Google lowered the LCP threshold to 2.0 seconds. That is wrong. Google’s own documentation still defines the good LCP threshold as 2.5 seconds, unchanged. The 2.0 second figure spread through SEO blogs and got repeated until it looked like fact. If your developer is optimising to 2.0 seconds, they are working to a stricter bar than Google sets, which is not harmful but is worth knowing. The figure that did change is older: Interaction to Next Paint replaced First Input Delay as the responsiveness metric in March 2024, so any guide still talking about FID is out of date.

The second is the one that catches everyone. Google judges these metrics on field data, not lab data. It uses the real experience of your actual visitors, collected through the Chrome User Experience Report over a rolling 28-day window, and it requires that at least 75 percent of those visits hit the good threshold.

This is why a page can feel fast when you test it on your own laptop and still fail. You are one visit on a fast connection. The 75th percentile is the fourth-slowest user out of every four, typically someone on a mid-range Android phone on a patchy mobile signal, and that is the user Google is measuring. If you only ever test on your own machine, you are testing the one case that does not count.

Of the three, Interaction to Next Paint is the one most sites fail, around 43 percent of them, and it is the hardest to fix. Loading problems are usually about resources: a heavy hero image, a slow server. Layout shift is usually about dimensions: images and ad slots without reserved space. But responsiveness is about JavaScript architecture, and you cannot compress your way out of it. If your page runs heavy scripts that block the main thread while a user is trying to interact, the fix is structural, which is why it is the metric that needs a developer rather than a plugin.

One caveat worth holding onto, because it stops you over-weighting this foundation. Core Web Vitals are a ranking signal, not the ranking signal. Google has been explicit that they act as a tiebreaker between pages of similar content quality, and that strong content with a poor page experience can still outrank weak content with a perfect one. So this matters, but it matters as a multiplier on content that is already competitive, not as a substitute for it. Globally only about 56 percent of sites pass all three, so clearing the bar is a genuine edge, but an edge is not the whole game.

Crawlability, indexation and site architecture

The fastest page in the world ranks for nothing if Google never reaches it. Before page experience matters, before content matters, Google has to be able to crawl the page and choose to index it, and this is the foundation that fails most silently, because nothing on the page looks wrong.

Crawlability is whether Google can reach the page at all. The common blockers are mundane and easy to ship by accident: a robots.txt file that disallows a section you meant to keep open, a noindex tag left in place after a staging site went live, a page buried so many clicks deep that the crawler rarely gets to it, or an internal linking structure so thin that important pages have almost nothing pointing at them. None of these show up when you look at the page in a browser. They show up only when you look at how Google sees the site.

Indexation is the separate question of whether Google, having crawled the page, decided to keep it. A page can be crawled and still not indexed, and Google Search Console will tell you so in plain language: “crawled, currently not indexed” is one of the most common and most ignored statuses in SEO. It usually means Google reached the page, judged it not worth storing and moved on, often because the page is thin, duplicative, or one of dozens that look near-identical. A page that is not indexed cannot rank for anything. It is not in the contest.

Site architecture is the layer that ties crawlability and indexation together, and it is where the strategic thinking lives. Architecture is how your pages link to each other and how deep they sit from the homepage. A flat, well-linked structure, where important pages are a few clicks from the top and supported by relevant internal links, tells Google what matters and helps it crawl efficiently. A sprawling, shallow-linked structure, where key pages are stranded with little pointing at them, dilutes that signal.

For most sites under a few thousand pages, crawl budget is not the real constraint. The real constraint is that bad architecture buries your best pages and tells Google, by the shape of your linking, that they are not important. The fix is rarely technical wizardry. It is usually deciding what your important pages are and linking to them like you mean it.

Structured data and canonicalisation

These two are grouped because they are the technical signals most often shipped broken, and because both are about telling Google something explicitly rather than leaving it to guess.

Structured data, also called schema markup, is code that labels what your content is: this is an article, this is its author, this is a product, this is its price, this is a review and its rating. Google can often work some of this out on its own, but structured data removes the ambiguity, and it is what makes a page eligible for the rich results that take up more space in the search listing, the star ratings, the FAQ dropdowns, the recipe cards. The catch is that broken structured data is worse than none. A schema that declares a rating the page does not show, or an FAQ that does not match the visible content, can get a page a manual penalty or simply ignored. Most sites that ship structured data ship some of it broken and never check, because it lives in the code and renders invisibly. Validating it is a five-minute job that almost nobody does.

Canonicalisation is how you tell Google which version of a page is the real one when several URLs show the same or similar content. This happens more than people realise: a product reachable through three category paths, a page that exists with and without a trailing slash, a printer-friendly version, an HTTP and an HTTPS copy, parameters appended by filters and tracking. To you these are one page. To Google they can look like four pages competing with each other, splitting the ranking signal between them so none of them ranks as well as the single page would have.

The canonical tag points Google to the version that should rank and consolidates the signal onto it. Get it wrong, by canonicalising to the wrong URL or to a page that redirects or no longer exists, and you can quietly tell Google to ignore the page you actually wanted to rank. It is a one-line tag with the power to remove a page from the contest, which is why it is worth checking rather than assuming the plugin handled it.

Diagnosing what is actually holding you back

Here is the part that matters more than any single fix, and the part most guides leave out: how to find your real blocker rather than fixing the one you happened to notice.

The mistake almost everyone makes is fixing the visible thing. Core Web Vitals are easy to see because there is a report with red and green, so teams pour effort into shaving milliseconds off a page that was never going to rank because it is not indexed. The visible problem is rarely the binding one. Diagnosis is the work of finding which foundation is actually capping the page, and it runs in a specific order, because the foundations sit on top of each other.

Start with indexation, because nothing downstream matters if the page is not in the index. In Google Search Console, check whether the page is indexed at all. If it says “crawled, currently not indexed” or “discovered, currently not indexed,” stop: you have found your blocker, and no amount of speed or schema work will help until the page is in the index. This is the first check because it is the most common cause of a good page ranking for nothing, and the one teams skip straight past on their way to the optimisation work.

If the page is indexed, check whether it is being crawled the way you think. Use the URL Inspection tool to see how Google actually renders the page, not how it looks in your browser. Pages that depend heavily on JavaScript sometimes render for users but not for the crawler, so Google indexes a near-empty version of a page that looks complete to you. If what Google sees is missing your content, that is the blocker.

Only once you have confirmed the page is indexed and rendering correctly does it make sense to look at page experience and Core Web Vitals, because those are the tiebreaker layer. A page that is indexed, rendering and genuinely competitive on content but stuck just below the pages it should beat is the page where Core Web Vitals are worth the effort. A page that is not indexed is not a Core Web Vitals problem, however red its score.

Then canonicalisation and structured data, which are less about whether the page ranks and more about whether it ranks as the right page and shows up richly when it does. Check that the page is not canonicalised away to another URL, and that any structured data validates against Google’s own testing tool.

The discipline is to diagnose before you fix, and to fix in the order the foundations stack. Most wasted SEO effort comes from inverting that.

The foundation is a diagnosis problem before it is a fixing problem

Technical SEO has a reputation as a checklist, a list of fixes you work through. The checklist is the easy part. The hard part, and the valuable one, is knowing which fix your site actually needs, because the same symptom, content that will not rank, has four different causes that look identical from the surface and need completely different work.

A site that diagnoses correctly fixes one thing and watches the page climb. A site that guesses fixes five things, moves nothing and concludes that SEO does not work. The difference is not effort. It is knowing where to look first.

FAQs

What is technical SEO?

Technical SEO is the work of making sure search engines can crawl, render, index and serve your pages, as distinct from the content on those pages or the links pointing to them. It covers page speed and Core Web Vitals, crawlability and indexation, site architecture, structured data and canonicalisation. Think of it as the foundation the content sits on: if the foundation is broken, even excellent content struggles to rank, because Google cannot reach it, read it, or judge it fairly.

What are Core Web Vitals?

Core Web Vitals are three metrics Google uses to measure page experience. Largest Contentful Paint measures loading speed, with a good threshold under 2.5 seconds. Interaction to Next Paint measures responsiveness, with a good threshold under 200 milliseconds. Cumulative Layout Shift measures visual stability, with a good threshold under 0.1. Google judges them on real visitor data from the Chrome User Experience Report at the 75th percentile, so a page has to be fast for most real users, not just on a developer’s test machine. Despite some guides saying otherwise, the LCP threshold remains 2.5 seconds in 2026, not 2.0.

Why is my good content not ranking?

Usually because something underneath the content is capping it. The page may not be indexed, may be crawled but judged not worth storing, may render differently for Google than for users because it depends on JavaScript, may be canonicalised to another URL, or may be too slow to clear page experience thresholds in a competitive query. Content quality is necessary but not sufficient: if the technical foundation fails, even the best content does not get a fair hearing. The fix is to diagnose which foundation is the blocker before rewriting anything.

How do I fix crawl and indexation issues?

Start in Google Search Console. Check the page’s status in the index: “crawled, currently not indexed” means Google reached it but chose not to store it, often because it is thin or duplicative. Use the URL Inspection tool to see how Google renders the page, since JavaScript-heavy pages sometimes render for users but not the crawler. Then check that no stray noindex tag or robots.txt rule is blocking the section, and that the page is well linked internally rather than stranded several clicks deep with nothing pointing at it. Indexation is the first thing to fix, because an unindexed page cannot rank for anything.

What technical fixes matter most?

The ones that remove a binding constraint, which depends on your site. In order of how often they cap a page: indexation first, since an unindexed page is out of the contest entirely; then crawlability and rendering, so Google sees the page as you intend; then Core Web Vitals, which act as a tiebreaker between competitive pages; then canonicalisation and structured data, which decide whether the right page ranks and whether it shows richly. The biggest mistake is optimising the visible layer, usually Core Web Vitals, while the real blocker, usually indexation, sits untouched.

How do I diagnose technical SEO problems?

Diagnose in the order the foundations stack, because they sit on top of each other. First confirm the page is indexed in Google Search Console, because nothing else matters if it is not. Then use URL Inspection to check Google renders the page correctly and is not seeing a near-empty JavaScript shell. Only then look at Core Web Vitals, since those are a tiebreaker that only matters once the page is in the contest. Finally check canonicalisation and structured data. The discipline is to find the binding constraint before fixing anything, rather than fixing the most visible problem and hoping it was the right one.

Last reviewed: June 2026

This article provides general information about technical SEO and search performance. Google’s ranking systems and Core Web Vitals thresholds change over time. Verify current thresholds and guidance against Google’s own documentation before making technical decisions.