The Technical Work Behind Rankings

A dependency chain, not a checklist

Technical SEO gets presented as a list of two hundred items, which is useless for deciding what to do on a Tuesday. It is more usefully understood as four questions in a fixed order, where a failure at any point makes everything after it irrelevant.

1. Can it be reached? Is the URL crawlable, does it return a usable status code, is it blocked.
2. Is it understood? Does what a search engine sees after rendering match what a visitor sees.
3. Is the right set stored? Are the pages you want indexed indexed, and the pages you do not want indexed absent.
4. Does it perform? Three metrics, at real-user thresholds.

The order is not stylistic. Rewriting a page that is blocked in robots.txt changes nothing. Improving load time on a page that renders empty for crawlers changes nothing. In practice, most sites that believe they have a content problem have a step-one or step-three problem that nobody checked, because checking is unglamorous and takes an afternoon while content strategy takes a quarter.

Everything below can be run by a marketer with Search Console access and a crawler. The judgment about what to do with the findings is harder than the finding, which is the honest case for bringing someone in — but not before the checks are done.

Check one: can it be reached

Start with the live robots.txt, read in a browser rather than assumed from a plugin's settings screen. Directives added for a staging environment and shipped to production are a leading cause of catastrophic, fully self-inflicted invisibility.

Then crawl the site and inventory the status codes. What you are looking for:

• 200 count versus what you expected. If the crawler finds far fewer URLs than exist, something is blocking discovery — usually navigation that only exists in JavaScript, or a link structure that dead-ends.
• 404 and 410. Both are legitimate for permanently removed pages, and Google treats them as a strong signal not to crawl that URL again. What matters is whether anything valuable is returning them.
• 5xx and 429. These are rate-limiting signals that reduce the crawl capacity limit, and persistent server errors actively suppress crawling. A hosting problem therefore outlives the hosting problem.
• Redirect chains. Googlebot follows up to ten hops, but Google advises redirecting to the final destination directly. Chains accumulate silently as rules get layered over years.

One directive distinction is worth more than most audit findings: noindex is the wrong tool for controlling crawling. Google is explicit that it will still request the page and then drop it, wasting crawling time. If the goal is to stop requests, that is robots.txt. If the goal is to keep something out of the index, that is noindex — and the page must remain crawlable for the directive to be seen at all.

Check two: does it see what a visitor sees

Indexing is not one step. Google crawls, then renders, then indexes, and a page enters the render queue after crawling if it returns HTTP 200. Google's own description of the queue wait is deliberately loose: a page may stay on it for a few seconds, but it can take longer than that. No bound is published.

The check is direct. Take a URL from each template, run it through the URL Inspection tool in Search Console, and look at the rendered HTML rather than the source. Is the main content there? Are the internal links there? If the body copy appears in the rendered output and the source is nearly empty, rendering is working. If the rendered output is also empty, the page is being stored as a shell no matter how good the copy is.

Two details save real time here. Google renders with an evergreen version of Chromium, so "it works in my browser" is usually true and usually not the issue. And Google states that its rendering service may ignore caching headers, which can leave it using outdated JavaScript or CSS; the documented mitigation is content fingerprinting in asset filenames. That is a specific instruction a front-end developer can act on in an afternoon.

Google's own position on server-side rendering is worth quoting when this becomes an internal argument: server-side or pre-rendering is still a great idea because it makes the site faster for users and crawlers, and not all bots can run JavaScript. In 2026 that last clause is the stronger half of the argument, because the crawler population now includes a range of AI crawlers whose rendering capabilities are not documented at all.

Check three: is the right set stored

Open the Page Indexing report and compare two numbers: the count of URLs your crawl found returning 200, and the count Search Console reports as indexed. The gap is the finding.

Both directions are problems. A large set of intended pages missing from the index is lost inventory. A large set of unintended pages present — parameter variants, filtered listings, print versions, internal search results, staging URLs — is a diluted, duplicated index that costs crawling and confuses consolidation.

The state to watch most closely is Discovered — currently not indexed. Google names a large proportion of URLs in that state as one of the three conditions under which crawl budget genuinely matters, alongside sites with over a million pages changing roughly weekly and sites with more than ten thousand pages changing daily. Below those conditions, crawl budget is not your problem, and a project sold to fix it is selling you something you do not need.

Then check that your signals agree with each other. The canonical tag, the internal links, the XML sitemap and any redirects should all point at the same preferred URL. Contradictions are common after a redesign — a sitemap listing old URLs, a canonical pointing at a version the navigation never links to — and they are cheap to fix once seen. Keep sitemaps current with accurate <lastmod> values rather than a build timestamp that claims everything changed last night.

Check four: does it perform, in the numbers that count

Three metrics, assessed at the 75th percentile of real page loads, segmented by mobile and desktop: Largest Contentful Paint at 2.5 seconds or under, Interaction to Next Paint at 200 milliseconds or under, and Cumulative Layout Shift at 0.1 or under. Above 500 milliseconds INP is poor; above 0.25 CLS is poor.

The most common error at this step is using a lab score from a single simulated load as though it described your visitors. It does not. Field data at the 75th percentile is the assessment; the lab tool is for debugging a build.

The second most common error is treating speed as a ranking lever and pitching it internally that way. The defensible arguments are that slow pages lose people, and that Google's crawl documentation makes the crawling link explicit: if Google can load and render your pages faster, it might be able to read more content from your site. That is a real, citable benefit and it does not require anybody to promise a ranking movement.

The parts that only apply to some sites

A lot of technical SEO scope is sold to sites it cannot apply to. Three of the big ones, with the condition that triggers them:

• Faceted navigation. Applies once filters generate URLs. Google's description of the mechanism is precise: crawlers cannot tell whether facet URLs are useful without crawling them, so they access very large numbers of useless ones first. If facets should not be indexed, Google's preferred controls are robots.txt disallow and URL fragments, and it states that rel="nofollow" and rel="canonical" are generally less effective in the long term — which contradicts a great deal of received practice.
• Internationalization. Applies once there is more than one language or country version. hreflang annotations must return-link to each other, and a migration silently breaks every one of them if the annotations are not rewritten to the new URLs.
• Structured data. Applies where an eligible feature exists. It is a presentation and eligibility mechanism, not a ranking input, and misuse is one of the documented manual action types.

If none of these conditions describes your site, their absence from a proposal is a sign of a competent scope, not an omission.

What technical work can and cannot do

Technical work removes obstacles. It very rarely creates demand.

What it reliably does: makes pages reachable and storable, makes what is stored match what a visitor sees, consolidates signals so that ranking value lands on one URL instead of six, protects existing traffic through changes, and makes the site fast enough that people stay. Those effects can be large, and they are frequently the fastest available improvement precisely because they are removing a blocker rather than competing for attention.

What it does not do: make a page relevant to a query it does not answer, create authority, or make an under-served market bigger. If the pages are indexed, fast, correctly consolidated and still not appearing, the constraint has moved to content and competition, and the correct response is to stop buying technical work. Saying that out loud is the difference between a diagnosis and a subscription.

How you know it worked: coverage — the count of intended URLs actually indexed — moves first, often within days of a recrawl. Non-brand impressions by template move next, because impressions respond before clicks do. Field performance moves gradually because it accumulates from real visits. If none of those three has moved after a fix has been recrawled and given time, the fix was not the constraint, and the honest next step is to say so rather than to ship a second one.

Frequently Asked Questions

Published 2026-08-11