How the Markdown for Agents checker works
- Paste any public URL into the box above and press Check site.
- Keep runs six parallel requests from the server: two to the URL you pasted, one with
Accept: text/markdownand one withAccept: text/html, one to the.mdvariant of the same path, and three to the origin root at/llms.txt,/.well-known/mcp/server-card.json, and/agent.json. - Each check returns pass, missing, blocked, or info with the raw request and first few hundred bytes of the response so you can verify what the checker saw.
Markdown for Agents, in one paragraph
Markdown for Agents is a set of four conventions that let a website serve clean Markdown to AI agents. A site can honour an Accept: text/markdown header, publish a .md variant at the same path, add a <link rel="alternate" type="text/markdown"> tag to the HTML head, or send a Link response header pointing to the Markdown version. Any one of the four is enough to make a page agent-ready. Cloudflare coined the name alongside its Content-Signal and x-markdown-tokens headers, but the conventions themselves work on any web server.
What the nine checks cover
- Accept: text/markdown negotiation. Confirms the server actually returned Markdown.
- .md variant at the same path. Confirms the alternate path resolves to Markdown.
- HTML alternate link. Scans the head for a Markdown alternate.
- HTTP Link header alternate. Looks for an RFC 8288 Markdown alternate.
- Vary: Accept. Checks that caches keep representations separate.
- Cloudflare Markdown signals. Surfaces token and content-signal headers.
- /llms.txt. Checks the file exists and starts with an H1.
- MCP server card. Checks the well-known server card and parses its JSON.
- /agent.json. Checks for a Google A2A agent manifest.
Blocked is not the same as missing
If the origin returns 403, 429, 503, or a Cloudflare bot-fight challenge page, the checker shows Blocked instead of Missing. The feature might still be implemented. Blocked points at bot policy, while Missing points at server configuration.
Frequently asked questions
Markdown for Agents is a set of four conventions that let a website serve clean Markdown to AI agents. A site can honour an Accept: text/markdown header, publish a .md variant at the same path, add a link rel="alternate" type="text/markdown" tag to the HTML head, or send a Link response header pointing to the Markdown version. Any one of the four is enough to call a page agent-ready.
Agents that fetch web pages pay tokens for every byte the server returns. HTML carries nav menus, CSS, tracking scripts, and widgets that the model does not need. Markdown drops all of that and keeps only the article structure. On most content pages Markdown is 80 to 95 percent smaller than the HTML, which means faster responses, cheaper context windows, and better comprehension.
The origin returned a 403, 429, 503, or a Cloudflare bot-fight challenge page. The feature might still be implemented correctly. We cannot confirm either way because the server refused the probe. Red means the feature is definitively missing; amber means we could not test it.
Vary: Accept is not required for Markdown negotiation to work, but it matters for intermediaries that cache the response. Without it, a CDN can cache one version and serve it to clients that asked for the other. The check is listed as nice to have rather than mandatory.
They solve different problems. Markdown content negotiation lets an agent fetch any specific page as Markdown. llms.txt lets an agent see the site index, pick the pages that matter for a task, and stop crawling the rest. A site built for agents usually wants both. If you only implement one, start with Markdown delivery because it compounds across every page.
Keep sits in the MCP ecosystem. Sites that expose an agent.json or /.well-known/mcp/server-card.json are declaring "I have an agent interface, here is how to talk to it." These two checks belong with the markdown checks because they answer the same parent question: can an AI agent do something useful with this domain?
Every check expands to show the exact request the checker sent and the first few hundred bytes it got back. Paste that into a ticket against your CDN, framework, or server config and whoever picks it up can reproduce the result without guessing what was tested.
No. The checker runs server-side fetches from Keep, so it can only see what a public crawler sees. Pages behind a login, intranet sites, or staging environments with auth will look blocked or missing to the checker, which matches what an agent would see.