Discovery
Well-known endpoints, Link headers, sitemap entries, and API catalogs give agents deterministic URLs to inspect instead of guessing from page text.
Field Guide
This demo treats agent readiness as a deployment discipline. Each tier adds the smallest useful public artifact, verifies it on the live URL, and moves on only after the scanner sees the change.
It starts with the current public score and the scanner evidence. If the site lacks basic crawl files, it adds only the Level 1 surface. If that passes, it proceeds to bot policy, markdown variants, well-known discovery, then native access metadata.
This matters because agent readiness is not one file. It is the relationship between visible content, crawl permissions, machine-readable structure, action discovery, and access control.
Well-known endpoints, Link headers, sitemap entries, and API catalogs give agents deterministic URLs to inspect instead of guessing from page text.
Markdown negotiation, JSON-LD, Open Graph, AGENTS.md, and llms.txt reduce extraction noise and preserve the intended page meaning.
MCP, Agent Skills, A2A, OpenAPI, and WebMCP explain what actions are available, what inputs they accept, and where agents should call them.
OAuth metadata, protected resource metadata, Content-Signal policy, and Web Bot Auth describe who can access what and under which rules.
robots.txt, sitemap.xml, Link headers, canonical URLs, Open Graph, JSON-LD.
Markdown negotiation, AGENTS.md, llms.txt, security.txt, content usage policy.
MCP server card, A2A agent card, agent-skills index, api-catalog, OpenAPI.
OAuth authorization metadata, protected resource metadata, Web Bot Auth key directory.
WebMCP tool registration for in-page actions that a browser agent can discover at runtime.
Scan the public URL and read the evidence, not just the headline score.
Choose report only, patch after approval, or report then patch.
Add the smallest platform-specific surface that can pass the next readiness layer.
Deploy, re-scan production, and continue only when the public evidence improves.
| Platform | How It Ships |
|---|---|
| Next.js | App Router routes, Pages Router middleware, or Vercel headers depending on the artifact. |
| Astro | Static public files plus middleware for markdown negotiation when server output is available. |
| SvelteKit | static/ files for public artifacts and hooks.server for headers or Accept negotiation. |
| Remix and React Router 7 | Resource routes for well-known JSON, loader headers for Link, and document routes for markdown. |
| Cloudflare Pages | public/ files, _headers, Pages Functions, and optional Web Bot Auth through the platform. |
| Cloudflare Workers | Route handling for every artifact, headers, markdown variants, and self-hosted well-known JSON. |
| Vercel and Netlify | vercel.json, _headers, _redirects, middleware, and framework routes depending on the host. |
| Plain HTML, Jekyll, Hugo | Static files first, host-level headers second, generated sitemap dates from real content changes. |
Cloudflare, SiteDex, IndexedAI, HubSpot, WordLift, and GEO scoreboards are moving toward the same visible signals.
It is cheap to publish, but adoption is mixed. JSON-LD, sitemap freshness, canonical URLs, and markdown access carry more durable value.
Both can turn readiness checks into platform features. The framework stays host-neutral so the site owner keeps the playbook.
x402, MPP, UCP, ACP, and AP2 stay opt-in unless the site actually sells products or exposes paid agent flows.
This site is a public proof page, not a shop. Shipping x402, MPP, UCP, ACP, or AP2 without a real payment or product flow would make the site noisier and less honest. The framework keeps those files behind an explicit commerce track.