Should you chase an agent-readiness score? From Level 1 to Agent-Native

Cloudflare launched isitagentready.com during Agents Week: 20 checks that score how ready a site is for AI agents. The framing sticks. "The web learned to speak to browsers, then to search engines. Now it must learn to speak to AI agents."¹ We scanned our site and the result wasn't pretty: 29 points, Level 1 "Basic Web Presence", with ten items missing.

Scores move people, as Lighthouse proved. So before filling anything in, we asked a prior question: what does this score actually measure?

The score blends three different things

Agent-readiness tools measure not one axis but three distinct dimensions.²

The dimensions don't compensate for each other. A comparison by Dachary Carey, author of the AFDocs spec, illustrates the gap: her site scored 100/100 in AFDocs but 33 on Cloudflare's scale, "Level 1: Basic Web Presence."²

The traffic evidence is limited too. In the material Carey reviewed, MCP Server Card and API Catalog had fewer than 15 adopters combined across the top 200k domains, and logs from one agent-heavy site showed no probes for those .well-known endpoints.² Robots.txt and sitemaps serve crawlers like GPTBot; they do not establish use by coding agents. A large share of the score measures readiness for a future that hasn't arrived.

That doesn't make the score meaningless. Per Cloudflare's Radar dataset, 78% of the top 200k domains have robots.txt, but only 4% publish Content Signals and 3.9% support markdown negotiation.¹ The standards are early, and adoption trends are a usable signal for when to invest in the protocol layer.

Our rule: substance only

Reviewing the 10 items, we set one principle. Never publish metadata for a service that doesn't exist. Posting OAuth discovery documents with no protected API, or an MCP card with no server, raises the score while feeding agents a false signal.

Half filled, nearly half deliberately left empty. But we're an AX consulting firm. To talk to clients about agent readiness, our own site has to be the proof. So instead of waiting for the protocol layer to show up in traffic, we pulled it forward by building the substance first.

What we actually built

An agent meets a site at three layers: it discovers, it reads, it acts.

Read: markdown negotiation

Send Accept: text/markdown to any URL and you get markdown instead of HTML. Browsers never send that header, so the human experience is untouched. Cloudflare's own benchmark puts the token savings of markdown negotiation at up to 80% (self-measured, so treat the number as directional).¹

The implementation came down to one middleware branch and one route. Insights articles are authored in MDX, so they ship essentially as source. Every other page skips HTML conversion entirely: we assemble markdown from the same structured data that renders the page. Using one source for both views reduces mismatch risk.

Discover: Content Signals and a skills index

We declared three values in robots.txt.

User-Agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Allow: /

ai-train=yes is a policy call. A publisher protecting content revenue might rightly say no. For a marketing site, future models training on our content is brand exposure. This trade-off has a different answer per site.

Under /.well-known/agent-skills/ we published a skills index with three entries: how to request a consultation, how to read our content as markdown, and how to use the MCP server. Each SKILL.md's sha256 digest is computed at build time, so the index can never drift from the bodies.

Act: a real MCP server

Publishing an MCP Server Card requires an MCP server. So we built one. With mcp-handler, a single Next.js route runs a Streamable HTTP server carrying seven tools: six content tools for services, case studies, and insights, plus request_consultation.

The consultation tool required no new backend. It calls the same server action the web form uses. One set of validation, one email path, and a consultation filed by an agent lands in the same channel as one typed by a person. Building a separate system for agents would have doubled the maintenance for nothing.

Trust: DNS-AID and DNSSEC

DNS-AID is an IETF draft for advertising agent endpoints through DNS.³ With the MCP server live, the records finally had something to point at. The two SVCB records below document what we put into Route 53 against draft-00 at the time.

_index._agents.801pla.net.  3600  IN  SVCB  1 801pla.net. alpn="h2" port="443"
_mcp._agents.801pla.net.    3600  IN  SVCB  1 801pla.net. alpn="h2" port="443"

Draft-02 kept _index._agents for the organization index, but moved a known agent's primary owner to a regular FQDN and treats names under _agents as inventory aliases. It also signals MCP through a protocol suite in alpn or the experimental bap parameter.³ The _mcp._agents record with only alpn="h2" is therefore a historical implementation record, not a current compliance example.

Draft-00 required DNSSEC for a public authoritative zone. Draft-02 changed ordinary record signing to SHOULD; if TLSA records are used, those records MUST be signed.³ Our domain is registered with Route 53 Domains, so everything from the KMS key through the KSK, zone signing, and the registrar DS record happened in one account. Keeping the zone and registrar together reduces coordination gaps and mismatch risk between the two systems.

Why we did not switch directly to draft-02

A cross-check with two public consumers on July 16, 2026 made the migration boundary clear. Cloudflare's isitagentready.com accepted both current records and DNSSEC. The latest dns-aid-core discover, however, found zero agents because it expects a regular-FQDN primary owner and a TXT index; only a direct verify of _mcp._agents accepted the record and DNSSEC. Replacing the existing index for one implementation would break discovery in the other.⁴

Parts of the draft are unsettled too. SvcParamKey numbers such as bap, cap, and well-known, along with the MCP ALPN identifier, still await IANA assignment. Route 53 accepts only its documented SVCB parameters and does not support arbitrary keyNNNNN presentation syntax.⁴ We therefore did not overwrite a working production record merely because a newer draft exists. The migration gate is a valid certificate and route for the regular FQDN plus parallel success across legacy and current consumers.

Deferral did not mean leaving the setup unattended. We created the Route 53-recommended CloudWatch alarms for DNSSECInternalFailure and DNSSECKeySigningKeysNeedingAction, then deployed a daily external regression check for the DS trust chain, both SVCB records, and the MCP Server Card.⁵ Once the draft stabilizes, the same check can cover the new regular FQDN first and retire the legacy name only after an observation period.

One lesson from the cutover: right after the DS record reached the parent zone, Cloudflare's resolver briefly returned SERVFAIL. That's the transition window where pre-signing cached answers collide with the new chain of trust; signing the zone first and publishing DS second keeps the window small. And if you ever roll back, the order reverses: remove the DS first, wait for propagation, then stop signing. Get it wrong and the whole domain stops resolving.

The rescan at the time came back 71 points, Level 5 "Agent-Native". Discoverability, Content, and Bot Access Control all hit 100, and every remaining gap in Discovery was one we had chosen to leave (the OAuth family and WebMCP). The scanner's rubric later changed: its public result on July 16, 2026 is Level 4 "Agent-Integrated", while DNS-AID itself still passes. That is another reason not to treat the number as a long-lived KPI.⁴

Does any of this help SEO?

Only partially. The content-accessibility layer (markdown views, allowing AI crawlers) can make content easier for generative engines to fetch and process, but it does not guarantee citations. Nor is the protocol layer that dominates the score directly tied to search visibility. We have no evidence that generative engines consult MCP cards or OAuth metadata when composing answers.

Two cautions. One observational study of 300,000 domains found no meaningful association between publishing llms.txt and citation frequency in AI answers.⁶ That result does not establish causality or describe every engine. If Content Signals or robots.txt policies actually prevent a crawler from fetching content, citation opportunities can shrink, but publishing a signal alone does not prove that outcome. If search and citations are the goal, skip the score and execute only the overlapping layer.

The verdict

Read an agent-readiness score as a roadmap signal, not a report card. The content-accessibility layer can reduce delivery and parsing costs, so do it first. Time protocol-layer investment against server logs and real use cases.² We pulled that moment forward for the proof value, but even then the order held: build the substance first, publish the metadata second. The same sequence appears in our gates for moving an AI PoC into production.

There's also a better test than any score: hand your site to an actual agent. Thirty minutes with a coding agent like Claude Code reveals things no scanner will tell you.

For what happens after discovery and reading, see how MCP 2026-07-28 changes AgentCore operations.

If you're weighing the direction of an AI transformation, agent readiness included, start with AX Consulting. If you need a team to build this kind of infrastructure, see Cloud & Infrastructure.

References