The technical work that actually pays

Search Engine Land published a prioritisation framework this month arguing that a subset of technical work delivers measurable value while much of the traditional checklist can safely be deferred. That has been quietly true for years. What has changed is the criterion for telling the two apart, and the new criterion is far less forgiving than the old one.

Why was the old checklist built for a different machine?

The traditional checklist was built for a crawler ranking pages. Its logic was incremental: each fix nudged a score, and the accumulation of small improvements produced a slightly better position. That model rewarded thoroughness, which is why the industry standardised on long audits. It also produced sharply diminishing returns, which everyone noticed and nobody wanted to say.

An AI system is not ranking your page against nine others. It is trying to decide what you are, and whether it can say so without being wrong. That is a comprehension problem rather than a scoring problem, and comprehension does not accumulate in small increments. Either the machine can state what you do and confirm it, or it cannot, and a hundred minor fixes will not move it across that line.

What is the new test for technical work?

Three questions, applied to any proposed task. Can the machine reach the information. Can it understand what the information means. Can it confirm the information somewhere it does not control. Anything that changes the answer to one of those is worth doing. Anything that does not is competing for budget against work that does.

Can it be reached?

Nothing else matters if the content is unreachable. That means crawl access is deliberately granted rather than accidentally denied, which is a live problem now that AI crawlers are distinct from search crawlers and are frequently blocked by rules nobody has revisited. It also means the substance of the page exists in the served HTML. Content assembled by script after load, or carried entirely by an animation, may be perfectly visible to a person and effectively absent to a machine. If the sentence that explains what you do only appears once something has faded in, it does not exist.

Can it be understood?

Understanding is where the real gains sit, and it is mostly not code. It is whether your business is described the same way everywhere, whether the concept you own is named consistently rather than paraphrased differently on each page, and whether the important claims are stated in plain declarative sentences rather than implied through design. Semantic markup and descriptive headings help because they tell the machine which parts of the page are the argument and which are the furniture. Defining your key terms explicitly on the page helps most of all, because it removes the machine's need to infer.

Can it be confirmed?

The third question is the one traditional audits ignore entirely. A machine that understands your claim then looks for agreement. Structured data describing your organisation, your people and your services matters here, and it matters much more when it links out to the independent records that confirm it. Structured data that contradicts the prose on the same page is worse than none, because it introduces exactly the inconsistency that makes a Composite Picture wobble.

What can safely wait?

Most of the rest. Micro-optimisation of individual page elements, exhaustive image compression on pages nobody reaches, chasing the last few points of a synthetic performance score, restructuring internal links for marginal equity flow. None of it is wrong. All of it is work that changes a number without changing whether the machine can describe you, and in a fixed budget it is competing directly against work that does.

The exception is anything that affects reachability. A page slow enough to time out is a crawl problem wearing a performance costume, and that belongs in the first category. The distinction is not speed versus structure. It is whether the fix changes what the machine can know.

How should you scope this with a client?

There is a commercial point buried in this. If you are paying an agency, or you are the agency, the long checklist has one obvious appeal: it looks like value. A short scope looks like less work even when it is worth considerably more, which is why so many engagements default to a thoroughness nobody benefits from.

The way through is to be explicit. Write down what the work covers and, in the same document, what it deliberately leaves alone and why. A scope that names its own exclusions is far harder to argue with than one that quietly omits them, and it converts the uncomfortable question of why the audit is short into a demonstration that you know which parts matter. That is not a defensive document. It is the clearest proof of judgement you can put in front of a buyer.

Comprehension is the whole game now. A business a machine can reach, understand and confirm will be described accurately even when it is not the loudest name in the field. A business that fails any one of those three will be described vaguely or not at all, no matter how many items were ticked off on the way. That matters more than ever as AI agents begin selecting suppliers on attributes they can verify.