# isitagentready.com and AgentReady.md: what each one measures Cloudflare runs a scanner at [isitagentready.com](https://isitagentready.com) that tells you whether your site is ready for AI agents. We run one at agentready.md that tells you the same thing. Both are free, both take a URL, both give you a score. They are not the same tool, and the difference is worth understanding before you act on either. ## What Cloudflare's scanner checks Per its own page, it runs checks across five categories: - **Discoverability** — robots.txt, sitemap, `Link` response headers, DNS for AI Discovery - **Content accessibility** — Markdown content negotiation - **Bot access control** — AI bot rules in robots.txt, Content Signals, Web Bot Auth - **Protocol discovery** — MCP Server Card, Agent Skills, WebMCP, API Catalog, OAuth discovery, OAuth Protected Resource, Auth.md, ARD manifest - **Commerce** — x402, MPP, UCP, ACP You can narrow the scan by site type, and at the end it hands you a block of instructions to paste into a coding agent so it can make the changes for you. The coverage of emerging protocols is the widest we have seen anywhere. The agentic commerce standards in particular — x402, UCP, ACP — are checked by almost nobody else, and Cloudflare is close enough to that work to keep the list current. If you are building an API or a storefront that agents are meant to transact with, that scan tells you things ours does not. ## What ours checks We check ten of those same `well-known` descriptors — MCP, A2A agent cards, Agent Skills, OAuth discovery and protected resource, API catalog — so on protocol discovery there is real overlap, and theirs is broader. The rest of what we do is a different question entirely: **not what your site declares, but what an agent is left holding after it reads you.** - **Content efficiency** — how much of your page is content and how much is scaffolding, measured in tokens - **Semantic HTML** — headings that make sense, real `
` and `
`, alt text, nesting depth - **Structured data** — Schema.org, Open Graph, canonical, declared language - **Machine accessibility** — whether the page works without JavaScript, its weight, where the content sits in the source And we give you the page converted to Markdown, the way an agent would keep it after discarding the rest. ## The gap between the two questions A site can declare every protocol on Cloudflare's list and still be useless to an agent that fetches it. Picture a well-built React storefront: valid `mcp.json`, agent card, OAuth discovery, x402 wired up. Perfect on protocol discovery. Now fetch a product page without JavaScript and you get an empty shell — nothing to read, nothing to quote, nothing to recommend when a customer asks an assistant which supplier to use. The reverse also happens, and more often: plain server-rendered pages, clean and complete, that no agent finds because there is no robots.txt rule letting the crawler in. **Declaring a protocol is a promise. Content is what you deliver on it.** The two scanners check different halves. ## Their scanner found our own bug This is not hypothetical for us. Our robots.txt returned `404` from our origin for months, and we did not notice, because Cloudflare's managed Content Signals Policy was answering for us at the edge with a plausible file we had not written — and our own scorer read that `200` and passed us. isitagentready.com reported it plainly: robots.txt not found. Their tool caught a real problem in our site that our tool was papering over. Fixing it dropped our score from 93 to 90, and the lower number was the honest one. Two things follow from that. First, a second opinion is worth having, especially when the first one is your own. Second, any scanner that reads through a CDN can be told a story by that CDN — including this one, and including ours. ## Which to use Use both. They are cheap and they take seconds. **Start with Cloudflare's** if your question is "do I expose the protocols an agent needs to work with me" — an API, an MCP server, anything transactional. Their list is longer and closer to the standards bodies. **Start with ours** if your question is "when an assistant reads my page, what does it actually get" — a content site, documentation, a business explaining what it sells. That is the case where the answer is usually worse than expected, and where seeing your own page as Markdown is the moment it lands. The healthy result is passing both. The common result is passing one and never checking the other. [Analyse a page](/) · [What we check, and how it is weighted](/about) · [The tools](/tools)