Cloudflare's free agent readiness score at isitagentready.com checks llms.txt, MCP, and markdown signals. What each check means, what a scan can't see, and how to improve your score.
You ran the scan, you got a score, and now you want to know two things: what the number actually means, and what to do about it. Cloudflare recently shipped a free checker at isitagentready.com that grades a single URL on how prepared it is for AI agents, alongside a blog post explaining the thinking. It is a good tool, and the underlying idea is correct: agents read the web differently than people do, and most sites were never built for them. This post walks through what the readiness score measures, decodes each check in plain language, and is honest about the blind spots any one-time scan has.
The score measures structural signals on a page: the machine-facing affordances an AI agent looks for when it visits, not how good your content is or how well you rank. You hand it a URL, it fetches that page and a few well-known locations, and it reports back on a set of agent-relevant checks. Think of it as a readiness inspection of the building, not a survey of who walks through the door.
That framing matters because it sets expectations correctly. A structural scan answers "if an agent showed up, could it work with this page?" It does not answer "are agents showing up, and what are they doing?" Both questions are real. Only the first one is visible from a single fetch of your HTML and your /.well-known/ paths.
Cloudflare sits in front of a large slice of the web, so they see agent traffic patterns at a scale most vendors cannot. Building a free front door to that thinking is a smart move, and it gets more operators asking the right question. The score is a starting point they are clearly positioning as exactly that.
Here is what a readiness checker like this looks for, and why each item earns its place. Where the exact pass condition is not public, I describe the category rather than invent a rule.
llms.txt presence. The checker looks for an llms.txt file at your root: a markdown index that tells an AI system what your site contains and which pages matter. Agents work under tight context budgets. A site with thousands of URLs and no map forces the agent to guess, and it guesses wrong often. A clean llms.txt hands it the catalog, the key pages, and the policies up front. It is the cheapest high-impact fix on the whole list.
MCP and agent-tool support. This category checks whether your site exposes callable tools an agent can invoke instead of scraping rendered HTML. WebMCP is the in-browser flavor, surfacing navigator.modelContext so an agent can call functions like "search products" or "check availability." Keep expectations spec-accurate here: WebMCP is emerging, origin-trial era technology, and major assistants like ChatGPT and Claude do not broadly invoke site WebMCP tools today. A pass on this check is a forward investment in being callable, not evidence that agents are calling you now. We covered the spec and who actually invokes it in our WebMCP explainer.
Agent skills and discoverable capabilities. Related to the tool check, this looks for declared, machine-readable descriptions of what an agent can do on your site, often at a well-known path. The value is the same: an agent that can read your capabilities as data does not have to reverse-engineer them from your UI. This is newer ground, so treat a low mark here as "not yet adopted," not "broken."
Markdown content negotiation. This checks whether your server can return a clean markdown or text version of a page when an agent asks for one, instead of a JavaScript-heavy HTML document. Agents parse markdown far more reliably than a rendered DOM full of nav, modals, and tracking scripts. If your product copy only exists inside a client-side React shell, a crawler-style agent may see a blank frame. Serving a markdown twin removes that risk. Cloudflare and Crawlytics approach this differently in practice, which I broke down in a separate piece on how Crawlytics and Cloudflare's markdown approaches differ.
Agentic commerce signals. For sites that sell, the checker looks for the structured data an agent needs to buy: machine-readable product names, prices, availability, and the schema that frames them. Pages with schema.org/Product markup and server-rendered prices parse cleanly. Pages where the price lives in a JavaScript widget or a spec table rendered as an image get parsed wrong, or skipped. An agent that cannot confirm your price will not guess. It moves to a competitor whose data was legible.
A single-fetch scan cannot tell you who is actually crawling your site right now, and that is the gap that matters most. The checker reads your structure. It has no window into your traffic. Three things stay invisible to it, and all three live in your server logs.
Whether agents reach you at all. A perfect readiness score on a page that no agent ever fetches is a tree falling in an empty forest. The inverse is just as common: a mediocre score on a page that GPTBot and PerplexityBot already hit daily. Only your logs know which case you are in, because agent visits arrive under user agents like GPTBot, ChatGPT-User, ClaudeBot, and PerplexityBot, and Google Analytics filters most of them out by design.
AI referral attribution. When ChatGPT cites your page and a human clicks through, that visit often lands in analytics as "direct" traffic with no referrer. A structural scan has nothing to say about it. Knowing that AI assistants are sending you real people, and which pages earn the citations, is a measurement problem, not a markup problem.
Per-bot behavior over time. Agent interest is a trend, not a state. Is ClaudeBot's crawl rate climbing month over month? Did a new user agent start fetching your pricing page last week? A one-time score taken on a Tuesday cannot show you the slope. The slope is usually the more actionable signal, because it tells you whether to invest now or wait.
None of this is a knock on the Cloudflare tool. It is doing exactly what a structural checker should do. These are just questions that, by definition, no single-page scan can answer.
Work the list in this order, because the early items unblock everything below them.
1. Open bot access. Check your robots.txt and any WAF or firewall rules before touching anything else. If you are blocking GPTBot, ClaudeBot, or PerplexityBot, every other fix is wasted effort, because the agent never gets in to see it. This is the first thing to verify and often the fastest win. Decide deliberately which crawlers you allow, then confirm the allow rules actually resolve. A surprising number of "low score" cases are just an overzealous bot block.
2. Ship llms.txt. One markdown file at your root, listing your key pages with short descriptions. It is the highest ratio of impact to effort on this checklist, and you can publish a usable first version in under an hour. Start with your catalog or core service pages, your pricing, and your policies.
3. Fix markdown and schema. Make sure your important content exists in server-rendered HTML, add schema.org structured data where it fits (Product, Article, FAQ), and serve a clean text or markdown version of pages where you can. This is the layer that decides whether an agent extracts your facts correctly or gives up on them.
4. Add the commerce layer. Last, not because it does not matter, but because it only pays off once the three layers above are solid. Expose products as callable tools via WebMCP for the agents that support it, knowing it is a forward bet on a capability still rolling out. There is no point being buyable to an agent that could not find or parse you in the first place.
A readiness score photographs your structure at one instant; visibility is the film that runs after. Both have value, and they answer different questions. The scan tells you whether your front door is built for agents. Ongoing visibility tells you who is walking through it, how often, and whether that flow is growing or stalling.
Run the free Cloudflare scan. It is fast, it costs nothing, and it will surface real structural gaps worth fixing. Then pair it with measurement, because the moment after you fix your score is exactly when the interesting questions start: did agent traffic respond, which bots picked up your new llms.txt, and are the AI assistants now citing the pages you cleaned up. That is the work a snapshot hands off to, and it is where the return on all those fixes actually shows up.
The honest summary: a one-time score is the right place to start and the wrong place to stop. Use it to find the gaps, fix them in order, then watch what your logs do next.
Written by Crawlytics Team. Crawlytics tracks AI bots, generates llms.txt, and powers WebMCP commerce, all from one snippet on any stack. See how it works →
Yes. Cloudflare's Agent Readiness checker at isitagentready.com is a free tool that scans a single URL and reports on agent-relevant signals like llms.txt presence, tool support, and markdown availability. You do not need a Cloudflare account or a paid plan to run a scan on a page. It is built as a public front door to the topic, so the barrier is intentionally low. For deeper or ongoing analysis across many pages and your actual bot traffic, you will want a dedicated tool, but the first look costs nothing.
A good result is one where an agent could discover, parse, and act on your page without guesswork, rather than any specific number. Focus on the underlying checks instead of the headline figure: is your content reachable in server-rendered HTML, do you publish an llms.txt, can an agent get a clean text version, and is your structured data present. Passing the foundational items (bot access, llms.txt, clean parseable content) matters far more than maxing out emerging checks like WebMCP, which most assistants do not invoke yet. Treat the score as a checklist, not a grade.
Not directly. No AI assistant uses Cloudflare's score, or any third-party readiness score, as a ranking input. What the score measures, though, overlaps heavily with what helps you get found and cited: pages an agent can crawl, parse, and trust are more likely to be retrieved and quoted in an AI answer. So improving the things the score checks can improve your real-world AI visibility, even though the number itself is not a signal any model reads. Fix the structure for the agents, not for the score.
An SEO audit grades you for human searchers and traditional ranking factors; an agent readiness check grades you for autonomous AI agents. The overlap is real (clean HTML, fast pages, structured data help both) but the priorities diverge. A readiness check cares about llms.txt, machine-readable tools, markdown content negotiation, and whether bots are even allowed in, items a classic SEO audit barely touches. Conversely, an SEO audit weighs backlinks, keyword targeting, and SERP features that agents largely ignore. Run both: they cover different visitors with different needs.
No. Every fix that moves an agent readiness score is implementable on any stack: llms.txt is a file you publish, schema markup is HTML you add, server-rendered content is a build choice, and opening bot access is a robots.txt and firewall edit. Cloudflare's tools can make some of these easier if you are already on their platform, but none of them require it. The checker is vendor-neutral about your hosting, and so is the underlying work. Pick the implementation that fits your stack and ship the fixes in priority order.
This page is part of Crawlytics.app. View all pages: llms.txt · llms-full.txt