Is "Agent Readiness" a Real Category - or Just Snake Oil?
Unpacking the "agent ready" industry
TL;DR
“Agent readiness” became a thing overnight — Cloudflare’s Agent Readiness Score, Google’s new Lighthouse category, and a cottage industry of scanners and scorecards. Most of it is hype dressed up as a standard.
The term hides two completely different problems: discovery (will ChatGPT, Gemini, Claude, or Perplexity recommend and cite you — the GEO/AEO problem) and usability (can an agent actually search, add to cart, or check out once it arrives, or use other capabilities such as MCP). Fixing one does nothing for the other, yet most “readiness” scores mash them into a single number.
There is no abstract “agent.” Almost all measurable AI traffic comes from four apps — ChatGPT, Gemini, Claude, Perplexity — with ChatGPT dominating. A protocol only matters once those platforms adopt it. Ahrefs found llms.txt — the supposed “holy grail” — is ignored 97% of the time, and the remaining 3% is mostly bots.
Google’s Lighthouse Agentic Browsing audit is the sane version: no single score (Google admits the standards are still evolving), just signals across accessibility, layout stability, WebMCP, and llms.txt — which it treats as optional. Most of it is plain good engineering that also happens to help agents. WebMCP is the only genuinely forward-looking piece.
Stop optimizing for a theoretical future agent. Measure against real use cases and outcomes, follow what the platforms that actually drive traffic are measuring and supporting, and skip the weekly checklist. This changes the day a major platform says it will reward agent-efficient sites in rankings — not before.
🚨 WebMCP Directory Update 🚨
The WebMCP directory we launched at webmcp.cool has a new home: webmcp.com. Same directory, easier to find. We have also added resources and made the directory more robust for the community. If your site exposes WebMCP tools, add it there.
And if you want help implementing WebMCP, or want to know what best practice looks like, we have a lot of hands-on experience. Write to us at founders@nekuda.ai or schedule call:
You’re not agent ready yet?!?
In the last few months, “become agent ready” suddenly became a thing.
Cloudflare launched a public Agent Readiness Score at isitagentready.com - a 0-100 grade across dimensions like discoverability, content accessibility, bot access control, and protocol discovery. Google added an Agentic Browsing category to Lighthouse, their famous website analysis tool. Underneath them, a cottage industry of scanners, scorecards, and audits has appeared, each promising to tell you whether your website is ready for agents and what you need to do next.
The problem is that it is still unclear whether being “agent ready” provides any tangible benefit beyond the hype. More importantly, the term itself hides a lot of confusion because it bundles together different problems and use-cases under a single label.
Much of the discussion also starts from the wrong place. Instead of asking what users are actually doing, which applications they are using, and what outcomes websites are trying to achieve, people talk about “agents” as a single category. Once you start from an abstraction, it becomes very easy to create endless checklists, standards, and scores that sound important but are difficult to connect back to reality.
Problem 1: “Agent readiness” is two problems disguised as one
The first issue is that agent readiness is often used to describe two completely different things.
The first is discovery. Will ChatGPT, Gemini, Claude, Perplexity, or another AI application recommend your website, cite your content, or surface your product when a user asks a question? This is the GEO, AEO, and AI search problem. It is fundamentally about content availability, indexing, reputation, and distribution.
The second is usability. Once an agent arrives on your website, can it actually do the thing it came to do? Can it search products, fill out a form, add an item to a cart, make a reservation, or complete a purchase? Usability represents actually a really small sub-set of traffic today (more on this below).
These are not two versions of the same problem. Work that improves discoverability will not necessarily make an agent capable of navigating your checkout flow, just as a perfectly usable website will not automatically get recommended by ChatGPT.
Yet many “agent readiness” scores combine both into a single number, which makes it difficult to understand what is actually being measured and where effort should be invested.
Problem 2: Who exactly is the “agent”?
The deeper issue is the word itself. Most agent-readiness frameworks evaluate websites against an abstract concept called “the agent.”
When you look at actual traffic, the picture becomes much simpler. The overwhelming majority of measurable AI referrals today come from a handful of applications: ChatGPT, Gemini, Claude, and Perplexity. ChatGPT alone accounts for most of that traffic depending on which dataset you look at.
This matters because every week there seems to be a new protocol, specification, framework, or standard that claims to be critical for the future of agent interaction. In reality, whether any of those standards matter depends largely on whether the major platforms adopt them. A technically elegant protocol without adoption is simply documentation.
A recent Ahrefs study found that LLM.txt - often described as the “holy grail” of agent standards for websites - is ignored 97% of the time. The remaining 3% of requests come primarily from bots rather than AI agents.
That is why we are generally skeptical of broad agent-readiness checklists. Instead of optimizing for a theoretical future agent, it is usually more useful to follow the guidance and requirements of the platforms that already have users. Those platforms determine where traffic flows, which standards become relevant, and ultimately which implementations matter.
So should you be agent ready?
The answer is probably yes, but that does not mean implementing every new protocol, framework, or checklist that appears every week.
Standards only matter once the major platforms adopt them. The web is full of technically elegant ideas that never achieved meaningful adoption because the applications that drive traffic never supported them. The same principle applies here.
If ChatGPT, Gemini, Claude, and Perplexity account for almost all meaningful AI traffic today, then their requirements matter far more than theoretical definitions of what an “agent-ready website” should look like. Rather than optimizing for an abstract future agent, it is more useful to look at what the major platforms are actually measuring, supporting, and encouraging developers to build.
Google’s new Agentic Browsing category in Lighthouse is a good example of this approach.
What Google’s Agentic Browsing audit actually measures
Google recently added an Agentic Browsing category to Lighthouse, the same tool developers already use for performance, accessibility, and SEO.
Unlike many agent-readiness products, Lighthouse agentic browsing doesn’t produce a single score. Google explicitly says the standards behind the agentic web are still evolving, so the goal is to provide signals rather than rankings. That alone is a useful contrast to an industry increasingly built around scoring something that is still poorly defined.
The audit focuses on four areas: accessibility, layout stability, WebMCP, and llms.txt (yes the same one that we mentioned is not being used right now :)).
Most of these are not new ideas. Accessibility and layout stability have been considered good engineering practice for years. Google’s point is that they also make websites easier for agents to use. Accessibility gives agents a structured representation of a page, while stable interfaces reduce failures for agents navigating visually.
WebMCP is the most forward-looking part of the audit. Instead of forcing agents to navigate interfaces, it allows websites to expose structured actions directly.
The most interesting signal may actually be llms.txt. Despite the attention it receives, Google treats it as optional. A missing file does not fail the audit, suggesting that even Google views adoption as early and the evidence of value as limited.
The broader lesson is that Google’s view of agent readiness is considerably narrower and more practical than much of the surrounding industry. Most of what Lighthouse measures boils down to making websites understandable, stable, and operable. There is very little protocol theatre and very little speculation about a distant future.
It is worth mentioning another standard that Google also recently announced - Agentic Resource Discovery (ARD) - an experimental open standard for helping AI agents discover tools, APIs, MCP servers for websites/businesses they interact with. Developers publish a simple file on their domain, which agents or discovery services can crawl and index so agents can find available capabilities before invoking them. It is backed by Google and partners including Microsoft, GitHub, Hugging Face, Salesforce, and Nvidia, making it a credible attempt, but still early.
The bottom line - measure against use cases and outcomes, not “agent readiness”
The biggest mistake in the current conversation is treating “agent readiness” as a single thing.
Discovery and usability are different problems. AI referrals are concentrated among a handful of applications. And many of the standards people are rushing to implement have not yet been adopted by the platforms that matter.
If you’re deciding where to spend time, start with the things major platforms are actually measuring and supporting. Follow the requirements of real products rather than abstract agents.
A lot of “agent readiness” turns out to be much less mysterious once you stop talking about agents in the abstract and start talking about what users and applications are actually trying to do.