How to Make Your Site Agent-Ready

Agent-readiness, defined: what makes a site usable by AI agents

Agent-readiness is the measurable degree to which a website lets AI agents discover, read, access, use, transact with, and trust it — achieved by implementing a defined set of machine-readable standards across six dimensions, each of which the Agent-Readiness Audit can verify. It is the engineering counterpart to the descriptive reference work in the Almanac: where the reference explains the agentic web, this page tells you how to ship it.

Agent-readiness is processual, not a switch. It is a sequence of concrete changes — files at your site root, HTTP headers, structured markup, capability manifests — each tied to a named standard. "Ready" is not a subjective judgement: each standard either resolves correctly or it does not, which is exactly what makes readiness machine-verifiable. Every how-to on this page implements one standard, satisfies one audit check, and ends the same way — verify it with the Agent-Readiness Audit.

Agent-readiness vs. SEO vs. accessibility: the distinction this guide draws

Agent-readiness targets autonomous machine clients, which separates it from two adjacent disciplines. Classic SEO optimizes a site for human-ranking search engines; web accessibility (WCAG) optimizes it for human assistive technology. Agent-readiness optimizes it for AI agents acting on a user’s behalf — programs that fetch, parse, and act on your pages without rendering them. The signals overlap (clean structure helps all three), but the client is different, and so is the proof: an agent-ready site is judged by whether a machine can complete a task on it.

Agent-ready means machine-verifiable: the standards-and-proof model

Every readiness claim on this site resolves to a standard plus a pass/fail check. You do not assert that your site is agent-ready; you implement a named standard (llms.txt, Web Bot Auth, JSON-LD), and a check confirms it resolves. That standards-and-proof model is why each how-to names both the spec it implements and the audit check it satisfies — and why this page closes into the Audit rather than ending in claims. Every how-to here implements a standard specified in the Agent Protocol Atlas.

Six readiness dimensions structure how a site serves the agentic web

Agent-readiness has six dimensions — Discoverability, Content, Access control, Capabilities, Commerce, and Quality — and each maps to a cluster of standards and to a category of checks in the Agent-Readiness Audit. The first five mirror the field’s scored categories (Cloudflare’s public model groups readiness as Discoverability, Content, Bot Access, Capabilities, and Commerce, as reported in 2026); Agents Welcome adds Quality as the structured, fresh, self-demonstrating dimension — the extension that makes the whole set machine-verifiable.

Discoverability: declaring your site to agents

The discoverability dimension is the Layer-1 declaration: it tells agents your site exists and where its important content lives, before any reading or acting happens. Member standards: llms.txt, llms-full.txt, AGENTS.md, agents.txt, agents.json, .well-known discovery, and NLWeb. Start here — the discoverability dimension declares your site to agents so everything downstream has something to find.

Content: serving machine-readable, answer-first content

The content dimension serves machine-readable, answer-first pages an agent can lift without parsing layout. Member standards: markdown twins, content negotiation (text/markdown), answer-first structure, and FAQ schema. Answer-first prose plus schema is a documented citation signal for AI answer engines — the content dimension serves machine-readable, answer-first pages that agents quote verbatim.

Access control: letting the right agents in and verifying them

The access-control dimension governs which agents you admit and how you confirm their identity. Member standards: Web Bot Auth (RFC 9421, Ed25519 signatures), an AI-aware robots.txt, pay-per-crawl, RSL, and Content-Signal. Shared crawler entities such as GPTBot and ClaudeBot show up here, and verifying them turns an anonymous user-agent string into a cryptographically proven caller.

Capabilities: exposing tools an agent can call

The capabilities dimension exposes callable tools so an agent can act on your site, not just read it. Member standards: MCP, WebMCP, and the agents.json action manifest. This dimension is optional — implement it only when agents genuinely need to do something (book, query, submit) rather than merely retrieve.

Commerce: accepting agent payments and checkout

The commerce dimension lets agents pay and check out on your site. Member standards: x402, AP2, ACP, and UCP. It depends on everything above it — an agent cannot transact on a site it cannot discover, read, or be trusted on — so the commerce dimension enables agent payments and checkout as the last layer, not the first.

Quality: structured, fresh, retrievable and self-demonstrating

The quality dimension is the machine-verifiable, structured-data layer: it makes your facts extractable, fresh, and provable. Member standards: JSON-LD / schema.org, freshness signals (last_verified), markdown twins, and self-demonstration. This is the Agents Welcome extension to the field’s five-category model — the dimension that turns "we serve agents" into something an audit can score.

Implementation order: which agent-readiness step to ship first

Implement agent-readiness in dependency order: start with Discoverability (llms.txt, AGENTS.md) and Content (markdown twins, answer-first) because an agent must find and read you before anything else, then add Access control (Web Bot Auth, robots policy), then Capabilities (MCP, agents.json) only if agents need to act, and reach Commerce (x402, AP2) and the full Quality layer last. The rule is simple: you cannot expose tools to, or take payment from, an agent that cannot yet discover or read you.

1. Discoverability first — ship llms.txt and AGENTS.md at your root so an agent can find your important pages. Prerequisite for everything else.
2. Content next — add markdown twins and answer-first structure so the pages it found are actually readable by a machine.
3. Access control — add Web Bot Auth and an AI-aware robots policy so you can admit and verify the right agents now that they can read you.
4. Capabilities — publish agents.json / an MCP surface only if agents need to call tools, not just read.
5. Commerce — wire x402 / AP2 once discovery, reading, and trust are in place, because payment is the highest-trust action.
6. Quality, throughout and last — JSON-LD, freshness, and self-demonstration harden every layer and make the whole set machine-verifiable.

The minimum viable agent-ready site is steps 1–2: discoverable and readable. Everything after that is unlocked capability, in the order an agent actually needs it.

How-to: implement each agentic-web standard on your site

Each agent-readiness how-to implements one standard in three moves — add the artifact, point it at your content, and confirm it resolves — and each ends the same way: verify it with the Agent-Readiness Audit. The cards below are the on-hub summaries; the full step-by-step for each lives on its own /agent-readiness/<how-to> subpage.

llms.txt: declare your content to agents

Add an llms.txt file at your site root that lists your most important pages as a clean, linkable index for agents. It implements the llms.txt declaration standard, whose spec lives at the llms.txt standard, specified at its protocol entry (primary source: llmstxt.org, verify at build). It satisfies audit check discoverability.llms_txt. Self-demo: this site serves /llms.txt live. Then verify it with the Agent-Readiness Audit.

agents.json: publish your agent-facing capabilities manifest

Publish an agents.json manifest that declares the agent-facing actions and capabilities your site exposes. It implements the agents.json declaration standard — agents.json declares your agent-facing capabilities (verify against the primary agents.json spec at build). It satisfies audit check capabilities.agents_json. Then verify it with the Agent-Readiness Audit.

Markdown twins: serve a machine-readable copy of every page

Serve a .md copy of every HTML page so agents can read your content without parsing layout markup. It implements the markdown-twin content pattern (the content dimension; no standalone protocol entity). It satisfies audit check content.markdown_twin. Self-demo: every page on this site has a .md twin — append .md to this URL. Then verify it with the Agent-Readiness Audit.

JSON-LD: make your entities machine-parseable with schema.org

Mark up your entities with schema.org JSON-LD so an agent can extract structured facts, not just prose. It implements schema.org structured data — JSON-LD uses schema.org for agents to expose entities as machine-readable facts. It satisfies audit check quality.json_ld. Self-demo: this page ships an @graph JSON-LD block. Then verify it with the Agent-Readiness Audit.

Web Bot Auth: verify the agents that visit your site

Verify visiting agents by checking their Ed25519-signed requests under RFC 9421 and publishing your own key directory. It implements Web Bot Auth, specified at its identity-layer entry under RFC 9421 (verify the RFC 9421, Ed25519, and Signature-Agent facts against the primary IETF / Cloudflare source at build). It satisfies audit check access_control.web_bot_auth and lets you verify the agents catalogued in the crawler registry. Follow the dedicated Web Bot Auth how-to to implement agent verification on your own site; see it defined as a term in the Lexicon first if needed. Then verify it with the Agent-Readiness Audit.

Content negotiation: return text/markdown to agents that ask

Return text/markdown (or JSON) when an agent sends Accept: text/markdown, so the same URL serves humans and machines the right format. It implements HTTP content negotiation for agents (media type per IANA; the content dimension). It satisfies audit check content.content_negotiation. Self-demo: request this page with Accept: text/markdown and you get its .md twin. Then verify it with the Agent-Readiness Audit.

Agent-readiness checklist: every check the Audit runs, mapped to a standard

The Agent-Readiness Audit runs one check per standard across the six dimensions, and every check maps to exactly one how-to on this page — so the checklist below doubles as your implementation plan. It is exactly what the Agent-Readiness Audit verifies (POST /api/audit): the checklist is itself machine-readable.

Self-demonstration: this site implements every step, and you can verify it live

This site implements every how-to on this page — it ships an llms.txt, an agents.json, a markdown twin per page, schema.org JSON-LD, a Web Bot Auth key directory, and content negotiation — and you can verify each one live before you trust the advice. Its own Agent-Readiness Audit score is rendered at build from these live artifacts, not hardcoded; the point is that the proof is fetchable, not asserted.

• llms.txt — fetch /llms.txt (proves the llms.txt how-to).
• agents.json — fetch /.well-known/agents.json (proves the agents.json how-to).
• Markdown twin — append .md to this URL, or fetch /agent-readiness.md (proves the markdown-twins how-to).
• JSON-LD — read the @graph block in this page’s head (proves the JSON-LD how-to).
• Content negotiation — send Accept: text/markdown to this URL (proves the content-negotiation how-to).
• Web Bot Auth — sign a request with Ed25519 and check /api/whoami; the key directory is published (proves the Web Bot Auth how-to).

Because every check is what the Agent-Readiness Audit verifies (POST /api/audit), an agent can read what this site claims and immediately test each claim against the matching live path — the honest version of "agent-ready."

Agent-readiness border: from implementing standards to certifying them

You now know which standards make your site agent-ready and how to implement each one — but did you actually ship them correctly, and can you prove it to the agents (and customers) that matter? That question cannot be answered with more how-to detail; it can only be answered by running the verification. Implementing a standard and proving it works are different jobs: this guide shows you how to ship each one, while the Agent-Readiness Audit checks every standard, scores your site across the six dimensions, and — when you pass — certifies it as Agents Welcome.

Ship each step, then the Agent-Readiness Audit checks every standard and certifies your site. Every readiness step implements a standard specified in the Agent Protocol Atlas; unsure of a term? Every standard here is defined in the Agentic Web Lexicon first. An agent-ready site lets the frontier models in the Model Matrix complete tasks for users, and adoption of each readiness standard is measured over time in the State of the Agentic Web report.