People have started asking a new question about their websites. Not “does it rank”, but “can an AI agent use this?” If a customer asks their assistant about a company, can the assistant read the site, quote the prices without getting them wrong, and do something useful with what it finds?
The trouble with the question is that it’s really nine questions, and most of the advice going round answers two of them and calls it done. Below is what each one means, what this site has for it, and where it is deliberately empty. Some of the list costs nothing if you already build fast pages. Some is a draft standard worth an hour. A good part of it does not apply at all to a business that sells services rather than products, and saying so is more useful than padding the list.
The nine dimensions
The dimensions build on each other. A site that can’t be read can’t be used, and a site that can’t be found won’t be read. So they stack into levels, and the level you’re aiming at depends on what kind of business you are.
Most business sites sit at level 0 or 1 without knowing which.
What an agent does when it arrives
It helps to know the order. A fetch-and-read agent, which is most of them, doesn’t open a browser. It makes one HTTP request at a time and reads what comes back, in roughly this sequence.
If any stop fails, the agent either guesses or gives up. Most sites fail at the third stop, which is the cheapest one to fix.
1. Readable
If an agent fetches a page, does it get the words, or an empty shell?
Agents don’t run your JavaScript. A site whose text only appears after a framework has loaded and rendered it, which describes a lot of business sites built in the last ten years, is empty as far as an agent is concerned. The page that’s slow for a visitor on a cheap phone is the same page that’s blank to an agent, and for the same reason.
It is also the one check on this whole list that a performance report will not do for you, which is why our free check now fetches the page without JavaScript and counts the words that survive. A site can score in the nineties and still hand a crawler thirteen words.
That makes the foundation of this dimension free for any site that is already built for speed. On this site it was in place before the phrase “agent-ready” existed, as a side effect of the decisions in how this site scores 100/100:
| Check | Result |
|---|---|
| Content present in the raw HTML, without running JavaScript | Yes |
| Prices written as text rather than images or scripts | Yes |
| External scripts loaded by the homepage | 0 |
| Third-party domains contacted | 0 |
| AI crawlers blocked in robots.txt | None |
What the site has. /llms.txt, in the format proposed at llmstxt.org: a heading, a paragraph about what the site is, then lists of links with a sentence about each, so a model doesn’t have to crawl and guess. /llms-full.txt carries every guide in one file for anything that wants the whole corpus in a single request. Every guide also exists as markdown at its own address, this one at /blog/making-this-site-readable-by-ai-agents.md, the same words with the navigation and styling stripped off, advertised from the HTML page with a <link rel="alternate" type="text/markdown"> tag.
What it does not have: Accept-header negotiation. The convention where a request for a page’s normal URL carrying Accept: text/markdown gets markdown back directly. It cannot work here. These pages are static files, which is a large part of why they’re fast, and Vercel matches a file before it applies any rewrite rule, so the HTML always wins. The way round it is serving posts from a function instead of a file, which trades away the thing the site is built on for a convenience the alternate link and llms.txt already cover. Readiness checkers flag this. It is a decision, not an oversight.
2. Discoverable
Can an agent find the parts of your site it needs, without crawling everything and guessing?
The second stop is a handful of fixed addresses. An agent looks in them for one reason each: where are the pages, where is the API described, is there an MCP server, are there skills. A missing file means guessing.
What the site has. The old pair first, since they still matter most: a sitemap that lists every real page, and one canonical URL form with at most one redirect. Then the newer ones, each pointing at something that already existed:
- An OpenAPI description of the speed-check API at
/api/openapi.json, and an RFC 9727 catalog at/.well-known/api-catalogthat points at it. That second one exists purely to answer “where is this site’s API description?”, which sounds pointless until an agent is looking for exactly that. - An MCP Server Card at
/.well-known/mcp/server-card.jsoncarrying the endpoint, transport, protocol version and tool names. The format is a draft that has already changed shape once, so this one includes the fields from both versions in circulation. - An Agent Skills index at
/.well-known/agent-skills/index.json, listing the skill file with a SHA-256 digest computed from the real file at build time. A hand-typed hash goes wrong the first time someone edits the file and then sits there, wrong, for months. - An Agentic Resource Discovery manifest at
/.well-known/ard.json, the same map as typed entries with a few example questions each resource answers. Also a draft.
All four come from one builder in the codebase, so they cannot disagree with each other or with the routes they describe.
What it does not have: DNS-based discovery. Publishing agent endpoints as SVCB records under a _agents subdomain. Vercel DNS cannot hold that record type, so this one is not a choice. Moving DNS elsewhere for it alone would not be worth the risk for a proposal this young.
3. Permitted
Have you told agents what they may do, or are they guessing, or blocked by accident?
robots.txt is where a lot of sites are accidentally unfriendly. Either a plugin blocked the AI crawlers years ago and nobody noticed, or the file says nothing and everyone is left to guess.
What the site has. Content Signals, a small addition to robots.txt that states what is permitted for each use:
User-agent: *
Content-Signal: search=yes, ai-input=yes
Allow: /search=yes means indexing. ai-input=yes means an assistant may read the page to answer someone’s question. ai-train is left unstated on purpose, and that decision gets its own dimension below. Every major AI crawler also has a named group, so anyone looking for the policy finds it written down rather than implied. The API carries a rate limit of fifteen requests a minute per address, which an assistant running one check for one user will never reach.
Content Signals is months old, and whether every crawler respects it is not something anyone outside those companies can verify. It is here because writing your policy down costs nothing, not because it can be shown to change anything yet.
What it does not have yet. The rate limit answers with a 403 when tripped, where a 429 with a Retry-After header would be correct. A 403 tells an agent it is banned; a 429 tells it to come back shortly. That one is a genuine gap rather than a decision.
4. Factual
When an assistant quotes your prices, will it get them right?
Ask an agent what something costs and it reads a pricing page built for human eyes, then works out which number goes with which tier. That goes wrong quietly.
What the site has. The tiers as data at /api/pricing.json, and schema.org Offer markup on the pricing page. Both are generated from the single config file the page itself reads, so a price changes in one place and moves everywhere. The three kinds of price are marked as what they are, because a “from” price quoted back to a customer as though it were the price is a complaint waiting to happen.
5. Usable
Can an agent do something on your site on a user’s behalf, not just read about it?
Everything above lets an agent read the site. This lets it use the site, and for a business with a free tool it is where the leverage is.
What the site has. An MCP server at /api/mcp exposing three tools. check_site_speed takes a URL and returns what a person gets from the free check: the score, the three Core Web Vitals labelled as real-visitor or simulated data, the top fixes and roughly what each would save. get_pricing covers the moment the conversation turns to cost. email_full_report sends the full list to an address the user provides. It runs the same code as the web page, needs no login, holds no session, and sits behind the same rate limit as the rest of the API.
Alongside it, an Agent Skills file at /skills/site-speed-check/SKILL.md. Agent Skills is a format for instructions an agent loads when it needs them. This one covers how to read a result rather than how to fetch one: what lab data means, why a score of 19 can still be a site that loads quickly, and why the per-fix savings must not be added together. Handing an agent a tool is easy. Giving it enough context to explain the answer without misleading someone is the part that takes thought.
An agent finds both through dimension 2. The server card, the skills index and llms.txt all carry the addresses. Worth knowing, though: most assistants today still only connect to MCP servers a person has added by hand, so the endpoint belongs somewhere a human can copy it too.
What it does not have: WebMCP. WebMCP is a browser-side proposal that lets a page announce its functions to an agent driving a browser rather than fetching files. This site used to register its check that way on the audit page. It no longer does: the redesign removed every script we wrote, and WebMCP only exists inside the browser. The MCP server gives an assistant the same tool without any of it. Checkers will flag the gap, and it is a decision.
6. Authenticated
If some of your data belongs to a logged-in user, can their agent log in as them?
An agent meeting a tool that needs a login looks for OAuth metadata at fixed addresses: where tokens come from, which issuers and scopes the API accepts, and how a client registers itself without a human creating credentials first. Each step is a published standard. Without the metadata an agent cannot guess, and the user is left pasting an API key by hand, which most will not do.
What the site has: nothing, deliberately. Three separate readiness checks live here, and passing all three is an afternoon of work: an authorization server document, a protected-resource document, and an auth.md. Every tool on this site is free and public. Publishing metadata describing a login that does not exist would send agents off to fetch a token they do not need and imply the API is gated when it is open. Three checks gained, and a worse experience for the very agents the score claims to measure.
What would change that. Per-customer monitoring data, or account pages. The moment something here belongs to one customer rather than to everyone, these documents stop being decoration and become the only way an agent can reach it on that customer’s behalf. Until then the correct number of OAuth files on this site is zero.
7. Transactable
Can an agent buy from you without a human filling in the form?
Agentic checkout means an assistant assembles a cart, shows it to the user, takes consent and completes payment through a protocol the merchant supports. Several such protocols exist, each backed by a different large company, and none has won.
What the site has: nothing, and it is not a gap. Selling an audit or a fix sprint involves a conversation and a scope. There is no cart to assemble. An agent’s useful job here is delivering someone to the contact form already knowing what their site scores and what the work costs, which is dimensions 4 and 5, not this one.
If you do sell products, the practical route is whatever your commerce platform or payment provider turns on, since they absorb the protocol churn. The part worth doing yourself is the layer underneath: complete Product and Offer structured data with price, currency and availability, and a checkout that does not live entirely inside a third-party iframe, because a browser-driving agent fills forms and cannot see into one.
8. Attributable
When a model learns from you or cites you, is it on your terms?
Two different things get lumped together as “training”. One is a crawler collecting pages to train a future model, months before anyone asks a question. The other is an assistant reading the page right now to answer a user, and citing it. They are separate switches and deserve separate answers.
What the site has. A yes to the second, through ai-input=yes. Silence on the first. The Content Signals spec treats an unstated signal as neither permission nor refusal, which leaves the decision open rather than letting a default make it. The citation side is ordinary hygiene: every post carries a publication date and an organisation as its author, in the page and in the structured data, and URLs do not move. Assistants that cite prefer pages that look like that.
What it does not have. A TDM reservation, the machine-readable opt-out the EU copyright directive recognises. That form only carries meaning as a refusal, and there is no refusal here to express yet.
9. Verified
Do you know, rather than believe, that all of the above works?
Discovery files return 404 from a stale cache edge. A firewall rule blocks the MCP endpoint. A digest goes stale after an edit. None of that shows up in a browser.
Where the site stands. isitagentready.com, a scanner Cloudflare built, tests most of the standards above and scores this site 60 out of 100. Without the server card, skills index and ARD manifest from dimension 2, the same scan returns 40.
| Category | Result |
|---|---|
| Discoverability | 3 / 4 |
| Content accessibility | 0 / 1 |
| Bot access control | 2 / 2 |
| API, auth, MCP & skill discovery | 4 / 8 |
| Commerce | not applicable |
The six it still wants are the six named above: markdown negotiation, DNS-based discovery, the three OAuth documents, and WebMCP, which needs browser script this site no longer ships. Publishing OAuth files for tools that need no login would lift the number by three in an afternoon and mean nothing. A score is a checklist, and explaining what is missing beats ticking boxes to hide it. It is the same thing we say about PageSpeed scores.
What the scanner does not cover. Every discovery file gets fetched from outside the network after a deploy, with a cache-busting parameter, because one of them once returned 404 from a stale edge while existing perfectly well at origin. The MCP server gets called through the public URL rather than locally, because rate limits and bot protection block that kind of traffic silently.
A caveat
All of this is new. llms.txt is a proposal, and Google has said its search doesn’t use it. Content Signals is months old. MCP changes every few months. Nobody outside the AI companies knows exactly what each crawler and assistant respects today, and anyone promising you’ll “show up in ChatGPT” is guessing.
It is still worth doing, because all of it can be undone, and the parts that matter most (text in the HTML, no dependence on JavaScript, a written crawler policy, facts stored as data) were good practice long before anyone used the word “agent”.
What to check on your own site
Three things, in this order.
First, load your page with JavaScript switched off. If the words disappear, an agent sees an empty page, and your visitors on slow phones are waiting a long time to see anything. It’s one fix for both problems.
Second, read your robots.txt. A surprising number of sites block AI crawlers because a template did it years ago. Decide on purpose.
Third, put your prices and key facts in plain text, not in an image or a widget. If a person can copy it, an agent can read it.
You do not have to do the first one by hand. The free check on this site fetches your page with no browser and no JavaScript, the way a crawler does, and reports how many words were actually readable in what came back. A PageSpeed score cannot tell you that, because Lighthouse renders the page with scripts running. The same answer comes back through our MCP server, so your assistant can ask for it too.