Technical SEO in 2026, in the order that matters.

Why the checklist is the wrong shape

You can generate a technical SEO checklist in seconds, and the reason it feels useful is the reason it is not: everything is present, so nothing is prioritised. A missing canonical and an uncompressed hero image appear as two line items of equal weight, when one can remove a page from the index and the other costs a tenth of a second.

This is the same failure as an audit that is really a crawl export. The tool finds everything. Deciding what matters is the part it cannot do, and the part you are actually paying for.

So the useful structure is not a list. It is a sequence of four questions, each of which only makes sense if the one before it is answered yes.

1. Can Google reach it

Discovery is links. Google finds URLs by following them, which is why submitting your site is a solved problem and why an orphan page can sit in a sitemap for months doing nothing. A sitemap declares that a URL exists. An internal link is what says it matters.

The checks here are unglamorous and they settle most cases. Is the page linked from somewhere Google already crawls, with a real anchor rather than a script-built menu? Does the server return 200 rather than a soft error? Is it blocked in robots.txt, which does not do what most people think it does? Are internal links pointed at canonical URLs, or are you routing every crawl through a redirect chain?

What is usually not the problem here is crawl budget. Below a few thousand URLs it is essentially never the reason a page is missing, and reaching for it first reliably hides the real cause.

2. Is it indexed, and is that a choice you made

Crawling and indexing are separate decisions, and Google declines plenty of pages it has successfully read. The Search Console status tells you which conversation you are in, and they are genuinely different conversations rather than degrees of the same problem.

Discovered, currently not indexed means it knows the URL exists and has not judged it worth fetching, which is about internal linking and perceived value. Crawled, currently not indexed means it read the page and declined it, which is a quality judgement with no technical fix at all. Treating the second as a crawl problem is the most common wasted month in this work.

The technical faults that genuinely belong here: a noindex left on after a staging launch, a canonical pointing at a URL that redirects, parameter and filter URLs multiplying a modest catalogue into a combinatorial mess, and near-duplicate pages where Google picks a canonical for you and picks the wrong one. Make that choice yourself or it gets made for you.

3. Can it understand the page

Two things sit here. Rendering, meaning whether the content exists for a crawler at all, and structure, meaning whether the machine can tell what the page is about and who stands behind it.

Rendering is the one that still catches sites out in 2026. Google executes JavaScript, but it does so in a second pass on its own schedule, and content that only exists after a client-side fetch is content you are asking it to come back for. If the primary copy, the internal links and the canonical are not in the HTML response, you have made an optional step mandatory. Fetch the URL with JavaScript disabled and read what comes back. That single check finds more real problems than most audits.

Structure is headings that describe the document, alt text that says what the image shows, and structured data that resolves to one coherent entity rather than three contradictory ones. Worth being clear-eyed about what that buys: schema is not a ranking factor. It earns eligibility for a different-looking result and an entity a machine can resolve, which is worth having and is not a position.

4. Is there a reason to prefer it

Everything left is a tiebreaker, and tiebreakers only break ties. HTTPS, mobile rendering and Core Web Vitals are real signals and small ones. They decide close calls between comparable pages. None of them will lift a page that fails question two, which is why speed work on a site with an indexation problem feels like effort with no result.

This is not an argument for ignoring them. It is an argument for doing them for the visitor, who is the one actually waiting, and treating the ranking effect as a bonus. That reasoning is set out properly in the Core Web Vitals write-up.

What actually changed for 2026

Less than the guides suggest. The four questions above would have been the right frame in 2019 and will be in 2029, because they follow from how a search engine has to work rather than from a policy.

Three things are genuinely different. AI-generated answers now absorb a class of short factual query, which changes which pages earn clicks rather than whether search sends them, and the exposure is concentrated in pages that existed only to state a fact. That is covered in AI Overviews are not a traffic apocalypse.

Second, entity clarity carries more weight than it did, because a model summarising you has no SERP to fall back on and will confidently merge you with a similarly named business if your own markup and profiles do not agree. Third, INP replaced FID as a responsiveness metric, which was a real change to what gets measured and a small change to what gets ranked.

What did not change: no minimum word count, no density target, no cadence bonus, and no credit for being old.

The order is the method

If you take one thing from this, take the sequence rather than the contents. When a page is not performing, walk the four questions in order and stop at the first no. That is the fix worth doing, and everything after it is a distraction until it is done.

It is also the honest answer to why a site can pass a 200-point audit and rank for nothing. Passing checks is not the same as answering the four questions, and on a new domain the real constraint is often none of them: it is that nothing links to you yet, which no amount of technical work will substitute for.