Why these six questions?
Most AI tooling for websites asks a marketing question: does AI mention your brand? Agent readiness asks an engineering one: can an autonomous agent actually use your site? An agent that can’t discover you, can’t parse your docs, can’t work out how to authenticate, and can’t call your API will route around you — no matter how often the underlying model mentions your name. (The two disciplines are complementary, not rivals — see how Agent Ready compares to AI-visibility platforms.)
“Agent-ready” decomposes into six questions, and every one of them has concrete, testable artifacts behind it. That’s what makes agent readiness an engineering property rather than a vibe: each answer below names the files and endpoints involved, and the scanner methodology turns them into deterministic pass/fail checks. This page is the diagnostic pass; for the depth-first treatment of how agents discover and extract content, read the complete guide to agent readability.
1. Can an AI agent discover my site?
Agents and AI crawlers probe a handful of well-known locations before reading any HTML: robots.txt for crawl policy, an llms.txt at the site root for a curated content map, sitemap.xml (and its Markdown twin sitemap.md), and protocol manifests under /.well-known/ — an MCP server card, an A2A agent card, an API catalog. If none of those exist, an agent falls back to scraping rendered HTML: the slowest, most error-prone path, and the first place agents give up.
Start with the two generators that produce discovery files from what you already have: the llms.txt generator builds a spec-valid file from your sitemap, and the AI robots.txt generator writes a crawler policy that distinguishes training crawlers from the retrieval crawlers that produce citations.
2. Can an AI agent understand my documentation?
Agents parse Markdown far more reliably than JavaScript-rendered HTML. The load-bearing artifacts: a curated llms.txt (plus llms-full.txt for full content), Markdown mirrors of key pages — served at .md URLs and via Accept: text/markdown content negotiation — JSON-LD structured data naming the things on each page, and an AGENTS.md giving coding agents context on how to use your product.
Semantic structure is part of comprehension, not a nice-to-have: agents that drive a browser act through the accessibility tree, the same programmatic surface assistive technology uses. Unlabeled buttons and div-soup layouts lock out both audiences at once — which is why the scanner runs a separate 23-check WCAG 2.2 accessibility suite alongside the readability score.
3. Can an AI agent authenticate correctly?
Answer it in both directions. Agents calling your APIs need machine-readable auth: your OpenAPI spec’s securitySchemes should state exactly which header or flow a caller needs, and an agent-permissions.json can declare what agents may and may not do on your site — there’s a generator that seeds it from your real manifests.
Agents visiting your pages are the other direction: Web Bot Auth (HTTP Message Signatures, RFC 9421) lets an agent prove its identity with signed requests that you — or your CDN — verify. An ordinary website publishes nothing for it; you simply gain the ability to tell real agents from spoofed user-agent strings.
4. Can an AI agent invoke my APIs?
Only if the API surface is published somewhere an agent can find and parse. The layers, from simplest to richest: an OpenAPI spec linked from a discoverable location; an RFC 9727 API catalog — a linkset at /.well-known/api-catalog pointing at every API you offer; an agents.json manifest describing multi-step flows over your OpenAPI operations; an MCP server exposing your capabilities as tools; and an A2A endpoint for agent-to-agent calls.
Every layer is a concrete artifact the scanner validates — and most have a generator (API catalog, A2A agent card) or a validator (MCP server card), so the manifests can be valid by construction rather than hand-rolled and hoped-for.
5. Am I implementing emerging agent standards?
Most sites aren’t — State of Agent Readability data shows the large majority of scanned sites publish no agent-protocol manifest at all. That makes the standards a first-mover opportunity rather than table stakes: publishing a correct manifest today puts you in a small minority agents can actually reach.
The landscape moves fast — MCP, A2A, agents.json, agent-permissions.json, UCP, x402, NLWeb, API Catalog, Web Bot Auth, A2UI, MPP, AP2, ACP — so Agent Ready tracks it as a registry of 69 deterministic checks, each mapped to the specification it validates. Grading is discover-then-validate: a manifest you don’t publish never counts against you; one you do publish is graded on correctness.
6. What technical changes will improve agent interoperability?
Run a scan and work the fix list — every failing check comes with a concrete remediation, so the answer to “what should I change?” is a prioritised list rather than a consultancy engagement. The highest-leverage sequence for most sites: publish and curate llms.txt, ship Markdown mirrors with content negotiation, add JSON-LD structured data, and write an AGENTS.md. (The 8-step checklist walks that sequence with a verifiable check per step.)
If you expose an API, add the protocol layer next — OpenAPI first, then an API catalog, agents.json, or an MCP server card. The full scan re-runs all 69 checks in seconds, so you can verify each fix as you land it instead of waiting for the next audit.
Frequently asked questions
- Can an AI agent discover my site?
- Only if you publish the artifacts agents actually look for. Agents and AI crawlers probe a handful of well-known locations before reading any HTML: robots.txt for crawl policy, llms.txt at the site root for a curated content map, sitemap.xml (and its Markdown twin sitemap.md), and protocol manifests under /.well-known/ such as an MCP server card or an A2A agent card. If none of those exist, an agent falls back to scraping your rendered HTML — the slowest and least reliable path. Agent Ready's site-family checks probe each location and report exactly which discovery artifacts are missing.
- Can an AI agent understand my documentation?
- Agents parse Markdown far more reliably than JavaScript-rendered HTML. The load-bearing artifacts are a curated llms.txt (with llms-full.txt for full content), Markdown mirrors of key pages served at .md URLs and via Accept: text/markdown content negotiation, JSON-LD structured data naming the things on each page, and an AGENTS.md file giving coding agents context on how to use your product. Semantic HTML matters too: agents that drive a browser act through the accessibility tree, so unlabeled controls and div-soup lock them out.
- Can an AI agent authenticate correctly?
- Answer it in both directions. For agents calling your APIs, publish machine-readable auth: your OpenAPI spec's securitySchemes should state exactly which header or flow a caller needs, and an agent-permissions.json can declare what agents may and may not do on your site. For agents visiting your pages, Web Bot Auth (HTTP Message Signatures, RFC 9421) lets an agent prove its identity with signed requests that you — or your CDN — verify. An ordinary website publishes nothing for Web Bot Auth; it simply gains the ability to tell real agents from spoofed user-agent strings.
- Can an AI agent invoke my APIs?
- Only if the API surface is published somewhere an agent can find and parse. The layers, from simplest to richest: an OpenAPI spec linked from a discoverable location; an RFC 9727 API catalog — a linkset at /.well-known/api-catalog pointing at every API you offer; an agents.json manifest describing multi-step flows over your OpenAPI operations; an MCP server exposing your capabilities as tools; and an A2A endpoint for agent-to-agent calls. Each layer is a concrete artifact Agent Ready validates, and generators exist for most of them, so they can be valid by construction.
- Am I implementing emerging agent standards?
- Most sites aren't — State of Agent Readability data shows the large majority of scanned sites publish no agent-protocol manifest at all, which makes the standards a first-mover opportunity rather than table stakes. Agent Ready tracks the moving landscape (MCP, A2A, agents.json, agent-permissions.json, UCP, x402, NLWeb, API Catalog, Web Bot Auth, A2UI, MPP, AP2, ACP) as a registry of 69 deterministic checks, each mapped to the specification it validates. Grading is discover-then-validate: a manifest you don't publish never counts against you; one you do publish is graded on correctness.
- What technical changes will improve agent interoperability?
- Run a scan and work the fix list — every failing check comes with a concrete remediation. The highest-leverage sequence for most sites: publish and curate llms.txt, ship Markdown mirrors with content negotiation, add JSON-LD structured data, and write an AGENTS.md. If you expose an API, add the protocol layer: OpenAPI first, then an API catalog, agents.json, or an MCP server card. Generators can produce spec-valid artifacts from your existing sitemap and manifests, so most fixes take minutes, not sprints.
- Is agent readiness the same as AEO or AI SEO?
- No. Answer-engine optimisation (AEO/GEO) asks whether AI assistants mention or cite your brand — a marketing measurement. Agent readiness asks whether an autonomous agent can technically discover, parse, authenticate against, and transact with your site — an engineering property you can test deterministically. They're complementary: agent-readable content is easier for answer engines to retrieve and quote, but the metrics, tools, and fixes are different.
- Do I need to implement every agent protocol to be agent-ready?
- No. Agent Ready grades discover-then-validate: optional manifests you haven't published are skipped, not penalised — only what you publish is graded on correctness. A content site can score well with the fundamentals alone: discovery files, Markdown mirrors, structured data, and clean semantics. Protocol manifests earn their keep when you have an API to call or transactions an agent could complete; add them then, ideally via a generator so they're valid from day one.