I passed every agent-readiness check while three statements in my own metadata were false

Two days after writing that Cloudflare’s agent-readiness checklist is a real specification whose companion score should not be trusted, I built this site to that specification and graded it with a public scanner.¹² It went from level 1 of 4 to level 4 of 4, six checks gained and none lost. Three of the statements I published for agents to read were false at the moment the scanner rated them, and nothing in the toolchain noticed, because every check I ran grades whether machine-facing metadata exists and parses. None of them grades whether it is true.

One invented value for a schema field reached four published files, passed three deterministic gates, 100 unit tests and a 109-assertion browser probe, and was found by the first independent reader.

What do agent-readiness scanners actually check?

Agent-readiness scanners fetch a fixed list of URLs at standard paths, the well-known URLs that let any client find a file without being told where it lives. They confirm each returns the right status code and content type, then parse the result against a published shape. The isitagentready.com scanner reports a level from 1 to 4, plus a per-check record of the literal request it made.² Every check is structural.

So a Content-Signal line, the robots.txt directive stating whether search indexing, AI training and AI answers are permitted, must be present and syntactically valid.³ An API catalog must take the shape of a linkset, the list-of-links format RFC 9727 requires for machine discovery.⁴ A skills index, the file naming the tasks a site offers an agent, must carry a name, a type, a description and a SHA-256 digest for every entry.⁵ That digest is a fingerprint of the file’s exact bytes.

The design is sound on its own terms. A scanner cannot know your publishing cadence or your field values, so it does not try. The failure is in reading the level as a quality signal for the content, which is the same mistake I warned about in the score beside the checklist, arriving from a different direction.

Six of the thirteen originally failing checks now pass. Of the seven still failing, six I declined on purpose, and that list matters more than the level does. OAuth discovery, OAuth protected-resource metadata, an Agent2Agent card, an auth.md, an ARD manifest and DNS-based discovery records all assume a site can prove an identity, hand work to another agent, or announce itself over DNS. A static site does none of those, so publishing the metadata anyway would move the number and lie to whatever read it. The seventh, an MCP server card, a manifest describing a live Model Context Protocol server, stays open instead of refused, because running a real server is a decision I have not made.

The build underneath that number is not decorative. Every article and Pulse day here now ships a markdown twin. I measured four of those pairs against the HTML they duplicate and the markdown ran 65% to 74% smaller, with one article falling from 49,070 bytes to 16,286.

My own AI-crawler log shows agents already fetching those files before I advertised the convention anywhere. As of 2026-08-19 it recorded 394 such requests across 28 logged days, on 27 of them. Small, and persistent. Cloudflare’s edge converter would have done the same job with no code, and it requires a paid plan this zone does not have,⁷ so a small worker serves the authored files instead.

That worker is also where a platform document earned its keep. Adding the worker meant the site’s _headers file, which attaches response headers with no code, stopped applying to every path the worker now answers. Cloudflare states that plainly, and no build step or validator would have surfaced it.⁸ The header would simply have been absent. Reading Cloudflare’s own documentation caught that one, unlike the three false statements ahead.

How did a wrong value reach four published files?

The Pulse section of this site tags every item with a status field, and I documented that field as taking one of three values: rumored, reported, or in testing. The schema that validates every item declares z.enum(["confirmed", "observed"]). All three of my values are plausible for the domain, which is why they survived, and not one of them can ever appear in the data.

The guess then traveled. I wrote it into llms.txt, into the OpenAPI description, into a description for one of the site’s WebMCP tools, a draft browser API that lets a page hand callable functions straight to an agent,⁶ and into a published agent skill.⁵ Four files, one unchecked assumption, and each later copy took the earlier one as settled. The correct value sat eleven lines from code I had already read that morning.

Two other statements were wrong the same way. I told agents that Pulse days are published by hand, having read the workflow file that says so in its own header, when the pipeline actually autopublishes with the human approval step deliberately removed. And a published skill told agents that no markdown version of the homepage existed, while that file was live on the same site, shipped earlier the same day so a scanner check would pass.

Why is a false value worse than a missing one for an agent?

A missing value leaves an agent uncertain, so it behaves conservatively or asks. A wrong value replaces an agent’s uncertainty with false confidence, and the agent acts on the false claim. Because that wrong value then becomes the input to a rule, the gap widens, and the rule looks like a safeguard while doing nothing.

That is exactly what my enum error produced. The rule I wrote said an item marked rumored must not be restated as confirmed, which is a real editorial concern and the reason the field exists. Implementing that rule literally, an agent would compare each item’s status against the string “rumored”, never match, and pass every unconfirmed item through unchecked. The safeguard was dead on arrival, and it read as diligence.

The same asymmetry showed up in a cost claim, where a review caught my fix instead of the original. A tool description said only “call it once per sitemap.” A critic flagged the undisclosed cost, correctly. My fix said “nothing rate-limits that endpoint,” which was wrong, since the worker applies a limiter of 20 requests per 60 seconds before any path branching. So the sequence ran from no claim, to a false absolute, to an accurate statement, and the middle state was the worst of the three. In my opinion this is the most common failure mode in review-driven editing, because specificity reads as rigor whether or not the specifics are right.

What caught the errors, and what could never have?

Three independent reviewers reading this site’s copy against its code found all three metadata errors in one pass: the invented enum value, the wrong publish cadence and the denied homepage file. Two found two errors each and overlapped on one, which is how all three surfaced. Nothing else did, and nothing else could have, because every automated check here tests structure or behavior and all three errors were structurally perfect sentences that were untrue.

The build was clean and the deterministic audit reported zero errors across every page the build produced. All 100 unit tests passed, and a browser probe that stubs the WebMCP API and executes every registered tool passed 106 assertions, later 109.

The audit checks that a page has one H1 and a resolvable JSON-LD graph. The unit tests check that an Accept header, the field a client uses to state which content type it wants back, here markdown instead of HTML, parses correctly, and that another header gets deleted. The probe checks that a tool registers and returns a well-formed object.

A sentence claiming the wrong publish cadence is structurally perfect and behaviorally invisible.

One check did earn its place, and it is the one that gates a hash. The skills discovery specification requires a SHA-256 digest per skill,⁵ so I generate the index from the files and fail the publish gate on drift. Editing both skills to fix the errors made that gate fail immediately, before anything shipped. A hash is the one field nobody can maintain by hand or eyeball, and it is therefore the one field where a machine check beats a careful reader.

What should you check that no scanner does?

Read the definition before you write a value, and prefer the file that the code loads over the file that describes intent. My two worst errors both came from a real, accurate, irrelevant source: a workflow that documents a manual path the pipeline no longer uses, and my own memory of a field’s plausible values. git log on the content directory would have settled the first in one command.

Four checks, none of which a scanner performs:

• Every enumerated value traced to its schema. Grep the value you are about to publish and confirm it exists. If it does not appear in a validator, a config constant or the data, it is invented.
• Every cost and limit traced to the code that enforces it. Numbers in agent-facing copy get acted on. Mine were wrong twice, once by omission and once by overcorrection.
• A reviewer who did not write the copy. The author is anchored on what they meant; a fresh reader sees what it says. When a second pass verified my fixes, I used a new instance deliberately, and that is the only reason it caught the false absolute my own correction had introduced.
• The claim that describes something you shipped today. Two of my three errors were true when written and false by the time they published, because the site changed underneath them within hours.

The deeper problem is that machine-facing copy has no readers to notice. A wrong sentence on a page gets a correction from someone; a wrong value in a skills file is read only by software that cannot tell, and by scanners built to confirm it parses. Until an agent-readiness check can compare a stated field value against the schema that governs it, the level is a statement about your plumbing. Whether the water is clean stays your problem.