What agent readiness actually means

Agent readiness is the degree to which a website can be used by an agent that has no browser. Not a headless browser: a client that sends an HTTP request, reads the response and decides what to do next. It runs no JavaScript, holds no cookies and waits for no human to dismiss a dialog. Whatever the site returns to that request is all the agent has to work with.

The framing is narrow on purpose: it makes the question answerable. Either the response contains the price or it does not; either an unknown path returns 404 or it returns the application shell.

What agent readiness is, precisely

Agent readiness breaks into four questions, each measurable from outside the site:

• Reach. Does a request from a non-browser client arrive at content, or at a challenge, an empty shell or a timeout?
• Discovery. Does the site state what it is and what exists on it, in files a client can read without guessing?
• Legibility. Does the response carry the content in a form a machine can parse, or does the meaning exist only in a rendered DOM?
• Permission. Does the site state how its content may be used and what a client may do next?

Each question maps to checks with a defined measurement, a command anyone can run and a fix to ship, because "agent-ready" is otherwise an adjective, and adjectives are not auditable. A published result carries per-check evidence, a reproducible score and a SHA-256 fingerprint, so the summary can be recomputed rather than believed.

A result is a claim about specific public surfaces at a specific moment, not a judgement about design or brand.

What agent readiness is not

Three neighbouring practices get sold under similar names, and vendors blur them deliberately. It is worth separating them.

Not SEO

SEO asks whether a search engine will rank a page for a query. Agent readiness asks whether a client can complete a task without one. Different consumer, different failure, and one technical divergence explains most of the confusion: search engines render JavaScript.

Google's documentation describes two stages. A URL is fetched and parsed, then queued separately for rendering, where a headless Chromium executes the JavaScript before the content is indexed. An agent that never renders sees only the first stage, so a site can rank well and still be empty to an agent.

The overlap is genuine on crawlability, canonical URLs and sitemaps. The Sitemaps protocol lists pages for crawlers; it says nothing about whether a client can read them.

Not GEO or AI visibility

GEO and AI visibility products measure whether a model mentions a brand in generated answers. Those measurements are real, but they are a different kind of claim: they depend on a proprietary model, an undisclosed retrieval stack, a prompt set and a date, any of which can change.

Agent readiness measures the site's own responses, which anyone can reproduce with a terminal. The two overlap where clean semantic markup helps both. They are not substitutes: appearing in AI answers is not evidence that an agent can check your price, and a valid contract file is not evidence that a model will recommend you.

Not accessibility

Accessibility is about people. WCAG 2.2 defines how to make content usable by people with disabilities, as testable criteria for human-facing conformance. Agent readiness is about agents with no user.

The overlap is large: both depend on structure that can be programmatically determined. Headings, a declared language, meaningful sequence, labelled controls and text alternatives help a screen reader and a parser for the same reason.

The differences run both ways. A WCAG-conformant site can still return a client-rendered shell to a non-browser client. An agent-readable site can still fail contrast, keyboard access and focus visibility. Conformance to one is not conformance to the other, and neither should be reported as the other.

The failures a browser hides

Every failure below looks like success in a browser, because the browser supplies what the client lacks: a JavaScript engine, cookies, a rendered DOM and a residential network. The page is perfect; that is the problem.

No llms.txt, and no single entry point

llms.txt is a proposal, not a standard, and it is worth saying so plainly. The llms.txt proposal asks for one markdown file at a known path that names the site and links machine-readable versions of what matters, because HTML wraps its information in navigation, scripts and decoration that are slow to strip.

Its absence is not an error. The failure mode is subtler: a site with hundreds of pages and no machine-readable entry point forces every agent to re-derive the structure by crawling, which is slow, expensive and easy to get wrong. Publishing the file is half the work: a file whose links point at JavaScript shells has moved the problem rather than solved it. The llms.txt check scores both parts: the path, and whether what it points at is readable.

Content that exists only after JavaScript runs

The HTML response contains <div id="root"></div> and a script tag. A browser builds the page; a client that does not execute JavaScript receives an empty document, with no sign that anything is missing. Google may render it later, in a separate queue. A task-running agent generally will not, and many agents deliberately refuse to execute JavaScript from an untrusted page, because that is a security decision rather than a performance one.

The measurement is blunt: fetch the page without a browser, remove script, style and template blocks, and count the text that remains. The no-js-fallback check does that, and the fix is the same idea in reverse: server-render the content so the first response already contains it.

Wildcard SPA fallbacks that answer 200 for every path

This is the most damaging failure, because every dashboard looks healthy. A catch-all rewrite returns the same index.html, with the same title, and a 200 status for every URL, including URLs that do not exist. Logs show no errors, responses are fast and uptime is perfect.

The damage is semantic. An agent fetching /pricing and /careers receives the same document and cannot distinguish "this page exists" from "this page does not", and it cannot trust the status code. RFC 9110 defines 404 to mean the origin has no representation for the target, and 200 to mean the response is the representation requested. A wildcard fallback tells every client that every URL is valid, which is false. The spa-fallback check compares two same-origin URLs and an unknown path; passing means each route ships its own document and unknown paths return 404.

Parked domains

The domain resolves, the homepage answers 200, and the body is a placeholder: a for-sale notice, an ad page, or a redirect chain ending at a broker. Nothing here is unready, because there is no site — only a registration.

This matters to anyone producing audits: a scanner that counts status codes reports "reachable, most checks failed", which reads like a bad site and is not. The accurate finding is that there is nothing to measure. A number attached to a parking page is a fabricated claim about a business that does not exist.

Blocked is not a low score

If a site refuses every automated client, the scanner has no observations. The tempting response is to score it zero and call that conservative. It is not conservative; it is wrong, and unfalsifiable, because the owner cannot point at anything to show the scanner was mistaken about what it never saw.

Network-level blocking turns that into a credibility problem. Bot management routinely treats datacenter address ranges differently from the rest of the internet, so a scanner running from one cannot distinguish three situations:

1. The site blocks all automated clients, deliberately.
2. The site blocks this network, or this class of network, and serves agents elsewhere.
3. The edge configuration is misfiring and the block was never intended.

Reporting any of them as a property of the site — and especially the datacenter-IP block — is the biggest credibility risk an audit product can take, because the report is confidently wrong about a fact the owner can verify in five minutes. Once one such report circulates, every other number is suspect.

There is a consent argument too. RFC 9309, which specifies the Robots Exclusion Protocol, states that its rules are not a form of access authorization and that operators needing real access control should use an application-layer mechanism. A 403 in a log is evidence about one request under one configuration, not a durable claim about what a site contains.

So the scoring contract has a third outcome beside pass and fail: not measured. Score null, grade NA, level null, confidence reported with a written reason, trigger conditions published. Instead of a number, the report publishes raw evidence: status code, content type, byte count and timestamp, so a reader can disagree with the interpretation without re-running anything. A check that is not measured stays in the denominator at 0 points, so the score and the confidence both fall. Dropping it would reward a site for being hard to measure.

How to start

Read the contract before changing anything, then fix in order of cost: the cheap items usually unblock the expensive ones.

1. Understand the instrument. /methodology is the scoring contract: 5 dimensions, tier pools, the formula, grades and the rule for a site that is not measured. /checks lists all 61 checks with their measurement, reproduction command and fix.
2. Confirm reachability and state your rules. reachable, robots.txt, ai-rules, content-signal. Small edits; a declared policy beats an implicit one.
3. Publish one entry point and one index. llms.txt, sitemap.xml, sitemap.md. Link to pages that are readable, not to shells.
4. Make the first response carry the content. no-js-fallback and spa-fallback change how every other check scores; headings, meta and jsonld decide how much of it a parser can interpret.
5. Cut what the agent pays for. markdown-negotiation gives a client a markup-free representation at the same URL, and token-efficiency measures how much of the response is content rather than scaffolding.

Work that list and you will have something measurable. What you should not do is publish a number you did not measure, including for your own site: if a scan cannot observe the site, the report says so.