What AI agent readiness means

For thirty years the assumption was that a person would read your website. Design, copy and navigation all followed from that. Search engines complicated it a little — you also had to be legible to a crawler — but a crawler only ever wanted to read and index.

Agents want to do. An assistant asked to book a plumber, compare three quotes, or check whether you deliver to a postcode is not browsing. It is fetching, parsing, and looking for something it can act on. If your opening hours only exist inside a JavaScript component, or your contact details are an image, that agent fails and moves to a competitor whose site it could read.

The two overlap at the edges. Both care about a valid robots.txt and a working sitemap. But the goals are different, and optimising for one does not deliver the other:

• SEO asks where you appear in a ranked list of results for a query.
• Agent readiness asks whether a program can retrieve your information at all, understand it without guessing, and find an interface to act through.

A site can rank first and still be opaque to an agent — heavy client-side rendering is the usual culprit. A site can also be perfectly legible to agents and rank poorly, because ranking depends on authority and competition that have nothing to do with machine access.

This is why we stopped presenting Banksia as a search and accessibility service. Those are worthwhile, but they are a different job, and bundling them muddied what we are actually good at.

Almost every emerging standard in this space is solving one of four problems, in order. Each layer only matters once the one before it works.

• Find it. A valid robots.txt, a reachable sitemap, honest canonical URLs. Increasingly also Link response headers, and DNS records under _agents that advertise your interfaces before a page is ever fetched.
• Read it. Content present in the HTML the server returns, not assembled later by JavaScript. Structured data that states plainly what your business is. Optionally, the ability to return Markdown to an agent that asks for it, instead of boilerplate wrapped around the paragraph it wanted.
• Know the rules. Whether you permit AI training, search indexing or answer generation on your content — declared explicitly through Content Signals rather than left for each company to assume. And, going the other way, a means of verifying that an agent claiming to be a given assistant really is one.
• Act on it.Discoverable endpoints an agent can call: an MCP server card, published Agent Skills, WebMCP tool registration, an API catalogue, OAuth metadata so it knows how to authenticate. For sellers, checkout protocols that let an agent transact on a customer’s behalf.

This matters more than the individual standards, and it is where most advice in this area is dishonest. Some of it is decades old and entirely safe to implement. Some was published a few months ago and may not exist in a year.

Settled. robots.txt, sitemaps, canonical URLs, HTTPS, correct status codes, well-known URIs, and schema.org structured data. Server-side rendering is a well-understood engineering practice. None of this is a gamble.

Emerging but stabilising. MCP has broad adoption across assistant vendors. Content Signals has an active IETF draft behind it. Both are reasonable bets today.

Genuinely speculative. llms.txt is a proposal, not a standard, and no major assistant has committed to reading it. The agentic commerce protocols are moving month to month. DNS-based agent discovery is early. These are cheap to add and may prove useful, but nobody should tell you they are required.

Every Banksia finding is labelled with which of these it belongs to. If a report tells you to implement something, it also tells you how settled the underlying specification is, so you can decide whether it is worth your time.

We assess the layers above against what your site publishes publicly, and we show the evidence: the request we made, the response we got, and the conclusion we drew from it. No score appears without the trace behind it.

We are deliberate about the boundary between what we measure today and what we intend to. What we check lists both, separately, so you can see exactly which signals a report will cover before you request one.

The specifications and proposals behind the above, if you want to read the primary sources rather than take our word for it.

• Model Context Protocol (MCP) specification — How an agent discovers and calls tools exposed by a service.
• Content Signals — A robots.txt extension for declaring how your content may be used by AI systems.
• IETF draft: AI preferences and content signals — The standards-track work behind those declarations.
• The llms.txt proposal — A convention for a plain-text summary of a site aimed at language models.
• RFC 9727: API Catalog — A well-known document listing the APIs a host offers.
• RFC 8615: Well-Known URIs — Why so much of this lives under /.well-known/.