All You Need to Know About Cloudflare’s Agent Readiness Score: the Practical Angle

For a long time, "AI readiness" has been a vague concept. We've talked about it in gut feelings—wondering if our content is "crawlable" or if LLMs are interpreting our pages correctly. But we lacked a standardized way to measure the technical infrastructure that allows an AI agent to actually function on a website.

That changed recently with the launch of Cloudflare's Agent Readiness Score. By moving the conversation from intuition to a measurable score, we now have a baseline. However, as with any new metric, the danger lies in chasing the number without understanding what it actually represents. If you look only at the composite score, you might walk away with a completely wrong impression of your site's health.

The Toolkit: Scanner, API, and the MCP Endpoint

Cloudflare didn't just release a simple webpage; they shipped a suite of tools designed to audit how "legible" a site is to an AI. The primary interface is a public scanner at isitagentready.com. You enter a URL, select a site type, and receive a report detailing which checks passed or failed, accompanied by AI-generated suggestions for improvement.

Beyond the web interface, this functionality is integrated into Cloudflare Radar for broader URL analysis and is available via a programmatic API for those who want to automate these audits across large portfolios of sites.

Perhaps the most interesting technical addition is the stateless MCP (Model Context Protocol) server available at /.well-known/mcp.json. This allows an AI agent to call the scanner as a tool. In essence, an agent can now audit a website's readiness before it decides how to interact with that site.

Expert Interpretation: The existence of the MCP endpoint is a pivotal shift. We are moving toward a web where the "user" (the agent) can check the "manual" (the readiness score) before attempting to use the "product" (your website). The tradeoff here is transparency versus control; while you want agents to find you, you are also providing a roadmap of your technical gaps to any agent that asks.

Breaking Down the 16 Checks Across 5 Categories

The scanner doesn't look at your writing; it looks at your plumbing. It evaluates 16 specific checks divided into five distinct categories.

Discoverability (3 Checks)

This category focuses on the basic metadata an agent needs to navigate your site. It checks for the existence of a robots.txt file (the fundamental crawl policy) and a sitemap.xml (which allows agents to enumerate your pages efficiently). It also looks for RFC 8288 Link headers, which provide canonical or related resource pointers in the HTTP response, aiding agents that prefer parsing headers over HTML.

Expert Interpretation: These are the "low-hanging fruit." If these fail, you aren't just failing a score; you are actively hindering the most basic discovery mechanisms used by almost every crawler in existence. The decision here is simple: these must be present and valid.

Content (1 Check)

The scanner tests for "Markdown for Agents" via content negotiation. It sends an Accept: text/markdown header to see if the server returns Markdown instead of HTML. While this isn't an IETF standard yet, it is a Cloudflare proposal based on standard HTTP mechanisms.

Expert Interpretation: Why does this matter? Tokenization costs. Markdown is significantly cheaper for an LLM to process and easier to parse than bloated HTML. The tradeoff is development effort; most CMS platforms don't support dynamic Markdown negotiation out of the box. If you have a high-traffic site, implementing this could theoretically reduce the "friction" for agents interacting with your data.

Bot Access Control (3 Checks)

This section examines how you manage AI traffic. It checks for AI-specific user-agent rules in robots.txt (e.g., GPTBot or ClaudeBot) and looks for "Content Signals," an emerging spec for per-URL access rules. It also checks for Web Bot Auth request signing via /.well-known/http-message-signatures-directory, which allows agents to cryptographically prove their identity.

Expert Interpretation: This is where the tension between "openness" and "protection" lives. Many site owners want to be "agent-ready" but fear data scraping. The decision to implement request signing is a high-effort move that only makes sense for sites requiring strict identity verification for the agents they allow in.

API, Auth, MCP & Skill Discovery (6 Checks)

This is the most technical category. It looks for machine-readable indexes of API endpoints (RFC 9727), OAuth/OIDC discovery metadata (RFC 8414), and declarations of OAuth-protected resources (RFC 9728). It also checks for MCP Server Cards (SEP-1649) and an Agent Skills index.

Expert Interpretation: This category is designed for applications, not blogs. If you are running a SaaS product, these are critical because they tell an agent how to use your software. If you are running a personal blog, these checks are largely irrelevant. The risk here is "score anxiety"—trying to fix these just to see a higher number when your site doesn't actually provide an API.

Commerce (3 Optional Checks)

For e-commerce sites, the scanner checks for the x402 payment protocol, the Universal Commerce Protocol (UCP) profile, and the Agentic Commerce Protocol (ACP) discovery document.

Expert Interpretation: These are flagged as optional. Cloudflare recognizes that a non-commerce site shouldn't be penalized for lacking a payment protocol. However, for those in e-commerce, this represents the future of "agentic commerce" where an agent can execute a purchase on behalf of a user.

The Scoring Paradox: Why Your Number Might Be Lying

To illustrate the danger of the composite score, consider the example of nohacks.co. In an initial scan using the "All Checks" preset, the site scored 33/100, landing it in the "Bot-Aware" level. This low score was driven by the absence of API catalogs and MCP cards—things a content-focused blog simply does not need.

However, when the same website was scanned using the "Content Site" preset, the score jumped to 67/100. The website hadn't changed; only the configuration of the scanner had. The "Content Site" preset removes irrelevant checks, providing a more accurate reflection of readiness for that specific type of site.

The problem is that the "Site Type" toggle is tucked away inside a "Customize" dropdown. Most users will simply paste their URL, hit scan, and see the default "All Checks" score. This leads to a misleading conclusion: a site might appear "unready" simply because it isn't an API-driven application.

Expert Interpretation: This is a classic case of a tool being more powerful than its default user experience. The decision for any site owner is to ignore the initial composite number and immediately dive into the "Customize" menu to select the preset that matches their actual business model.

Delivery vs. Message: The Great Divide

It is vital to understand that the Agent Readiness Score measures delivery, not the message. It tests the pipes, not the water.

The scanner does not care if your headlines are clear, if your arguments are persuasive, or if your content actually answers a user's query. Those are questions of SEO, CRO, and quality writing. You can have a perfect 100/100 Agent Readiness Score and still have content that is useless to an AI because it is poorly written or logically flawed.

Expert Interpretation: We are seeing the emergence of two different disciplines. One is "Infrastructure Readiness" (what Cloudflare is measuring), and the other is "Semantic Readiness" (how well your content is structured for LLM reasoning). Improving your score helps the agent get to the content, but it doesn't help the agent understand the content.

The Risks of Gaming the Metric

Goodhart's Law states that when a measure becomes a target, it ceases to be a good measure. There is a significant risk that site owners will begin optimizing for the score rather than for actual agent utility.

For example, a site owner might publish a blank MCP Server Card or a fake Agent Skills index just to flip a "fail" to a "pass" in the scanner. This inflates the score without providing any real value to the agents visiting the site. In fact, it creates a worse experience by providing "dead ends" to the AI.

Expert Interpretation: Avoid the temptation to "check the box." If a check fails but the corresponding feature provides no value to your specific business, leave it failed. A 40/100 score that is honest is more useful than a 90/100 score that is a facade.

Practical Steps for Immediate Improvement

If you are auditing your site this weekend, don't try to fix everything. Focus on the high-leverage items that map to how real-world agents behave today:

• Audit your robots.txt: Ensure it exists and specifically addresses AI user agents like GPTBot, ClaudeBot, and PerplexityBot.
• Verify your Sitemap: Ensure sitemap.xml is present and correctly linked in your robots file.
• Review the Detailed Report: Ignore the composite score and look at the specific failing signals.
• Select the Correct Preset: Ensure you are measuring against "Content Site" or "API/Application" rather than "All Checks."

The Road Ahead: Vendor Fragmentation

Cloudflare's scanner is based on a mix of ratified standards (RFCs) and emerging proposals. It is inevitable that other vendors will release their own scanners with their own preferred lists of checks.

While there will be overlap on the basics (like robots.txt), there will be divergence on the emerging specs. We are entering an era where "Agent SEO" will require tracking multiple vendor-specific scanners to ensure your site remains legible across different AI ecosystems.

Introduction

The key issue here is Agent-readiness crossed from concept to measurable infrastructure this week. On April 17, as Cloudflare Agents Week extended into its sixth day, the company shipped isitagentready.com , a public scanner that scores any website on how prepared it is for AI... My read is to treat it as a decision point: what signal needs to become clearer, what part of the system is currently weak, and what evidence would show that the work is improving visibility rather than only adding activity.

That is the difference between reacting to a trend and building a useful search system. Connect this point back to the page template, internal linking, entity signals, content depth, crawl accessibility, and the way the brand is represented across the wider web before deciding what to change first.

Contents

The key issue here is 1. What Cloudflare Shipped: Scanner, API, And An MCP Endpoint Agents Can Call On You 2. 16 Checks, 5 Categories: What The Scanner Actually Tests 3. Nohacks.co Scored 33/100, Level 2 Bot-Aware 4. Same Website Scores 33 Or 67 Depending On The Preset You Select... My read is to treat it as a decision point: what signal needs to become clearer, what part of the system is currently weak, and what evidence would show that the work is improving visibility rather than only adding activity.

That is the difference between reacting to a trend and building a useful search system. Connect this point back to the page template, internal linking, entity signals, content depth, crawl accessibility, and the way the brand is represented across the wider web before deciding what to change first.

Practical next steps

The useful part is not only the idea itself, but the operating habit behind it. Use it as a checklist for decisions: what deserves attention now, what should be monitored, what needs a stronger evidence base, and what can wait until the system has more scale.