AI Agent Readiness: What We Learned Scoring Our Own Site

AI agent readiness is whether an AI agent can find your site, read what it sells, and act on it without a person in the loop. It is decided by about seven files, most of which take an afternoon. We built a free scorecard to measure it, ran it against our own site, and spent four days fixing what it found.

What an agent does when it visits you

A person landing on a product page reads a headline, looks at a picture, and decides. An agent does none of that. It fetches a small number of files at predictable addresses, and if those files are missing it either guesses from your HTML or moves on to a competitor whose files are present.

That is the whole mechanism, and it is why agent readiness is a checklist, not a strategy. The seven surfaces below are what a scorecard looks at.

Not all seven apply to every site. A blog has nothing to say about checkout, and scoring it against commerce checks produces a low number that means nothing. That distinction turned out to matter more than we expected.

The first number was wrong

The first run put redhub.ai at 39 out of 100, verdict DARK TO AGENTS. That was a bad enough result that we checked it instead of accepting it, which is how we found that the form only asked for the homepage.

The number was an artifact of our own form, not a reading of the site.

Most sites keep their product schema on product pages. Ours does. Scoring a storefront from its homepage alone marks it zero on the heaviest check in the model, and the form gave you nowhere to paste a product page. Adding that one field moved the same site from 39 to 61 without changing a byte of the site itself, which is the tell: a score that moves when only the questionnaire changed was never measuring the site.

So 61 is where this actually starts.

The second defect was worse and took longer to see. The form hardcoded the .well-known input to empty and never offered a box for it, so that check read 0 out of 2 for every site the tool could ever score, including sites that publish those files. It went unnoticed for a simple reason: our own zero was correct. We had nothing at /.well-known/. Where your own answer happens to be right is exactly where a broken input is invisible.

The top grade was hiding holes

With the form fixed, we ran the scoring model across its whole input space to see how it behaved. Of the cases that earned the top verdict, 48 percent had at least one applicable check sitting at zero. A site could be told agents can find, read, and act on it while an entire surface was missing.

That is an averaging problem, and it is the failure every deterministic gate we build exists to prevent. A weighted score lets strength in six places paper over an absence in the seventh. So the scorecard now runs a second gate: a top-band score is held at the middle verdict while any applicable check reads zero, and the result names which surface is dark.

The fix demoted 64 cases, all of them scoring between 75 and 81, and 56 of those were missing a Content Signal entirely. That last number is what convinced us the gate was discriminating and not blunt. A site that has never declared what agents may do with its content is not a site that has earned a top grade.

Then we fixed the site

With a scorecard we trusted, 61 was a real number and it was ours to fix. Four changes, in the order we made them.

The feed is worth one more sentence, because how you build it matters more than whether you have one. A feed exported on a schedule drifts from the site between exports, and a feed that contradicts its own product page is worse than no feed at all. Ours is generated at build time from the same two files the product pages render from, so the two cannot disagree. We verified that instead of assuming it, by sampling 20 products and comparing the feed price against each page's structured data.

What we did not fix

One check still sits at half marks, and it stays there deliberately.

The .well-known check goes to full marks if you publish an MCP server card. We do not run an MCP server. Publishing a card describing an endpoint that does not exist would have bought ten points and made the file a lie, which is the exact behavior our products are built to catch. It moves the day we build one.

One more correction

Writing this post turned up a claim on our own product page that we had not verified. We had described Cloudflare's Agent Readiness Score as running commerce checks against every site, capping content sites at roughly half marks. Cloudflare's launch post says the opposite in plain words: it checks the agentic commerce standards "but these do not currently count towards the score." A content site is not penalized for missing them, so the mechanism we described does not exist.

The page is corrected. The real difference between the two tools survives it, and it is a difference in question, not in quality. Cloudflare scans your live site and asks which standards it supports. Ours asks how much of what applies to your kind of site is in place, which is why it makes you declare what you are first. Run both. They disagree in useful ways.

The same site scores 94 here and 29 there

So we ran redhub.ai through Cloudflare's scorer too. It returned 29 out of 100, Level 2, Bot-Aware. Same site, same week, a 65-point spread. The reason is entirely in what each tool counts.

Fourteen checks carry that score and each is worth the same. We passed four, and four out of fourteen is 29, which is the number on the dial. Weighting its categories equally instead would have produced 38, so the flat count is the arithmetic that fits.

Half the score sits in one category. Seven of the fourteen checks are API, authentication and agent-endpoint discovery: an API catalog, OAuth authorization-server metadata, OAuth protected-resource metadata, an agent-registration document, an MCP server card, an agent-skills index, and WebMCP tools in the browser. We run one public API and no authenticated endpoints. Six of those seven describe infrastructure that does not exist here, and publishing them anyway would have bought about 35 points and made six files lie.

We shipped the four we could stand behind: an API catalog naming the one API we do operate, a Link header pointing at it, markdown content negotiation, and WebMCP tools that actually run. That should read eight of fourteen. We have not re-run it to confirm, and the WebMCP check in particular depends on whether the browser doing the checking implements the API our code looks for before it registers anything.

Neither number is wrong. Cloudflare asks which agent standards a site supports and asks it the same way of every site. Ours asks how much of what applies to your kind of site is in place, which is why it makes you declare what you are before it scores anything. A blog has nothing to say about checkout. A storefront with no public API has nothing to say about OAuth. Whether that silence is a failure or a non-question is the whole disagreement, and it is worth knowing which one your tool assumes.

How to check your own site

You can do most of this with a browser and ten minutes.

• Open yourdomain.com/llms.txt, /sitemap.xml, and /robots.txt. Note which ones 404.
• View source on one product page and search for application/ld+json. If there is no offers block with a price, agents cannot read what you charge.
• Check /.well-known/security.txt. Most sites have nothing there.
• Ask whether anything on your site is machine-readable as a catalog, not as a page.

Then paste those files into the Agent-Readiness Scorecard. It is free, it runs in your browser, and nothing you paste is uploaded. Declare what your site is first, because a check that does not apply to you is excluded rather than failed.