Site Agent Readiness Checker

Scan a public site for machine-readable signals that help AI agents discover content, understand access policy, find protocols and, where relevant, transact.

Public HTTP/HTTPS URLs only. The scan does not log in or submit forms.
The profile controls which categories count toward the score. All checks are still explained below.
How the score works: established standards carry more weight than emerging conventions. Draft, experimental and proposal checks are deliberately down-weighted so the score does not imply that every new agent protocol is mandatory.
Five audit categories

What the checker looks for

Discoverability
robots.txt, sitemap discovery, HTTP Link headers and the DNS-AID draft.
Content Accessibility
Whether the scanned page can negotiate a text/markdown representation.
Bot Access Control
AI crawler rules, Content Signals and Web Bot Auth discovery.
Protocol Discovery
API Catalog, OAuth metadata, Auth.md, MCP Server Cards, Agent Skills, WebMCP and ARD.
Commerce
Public implementation signals for x402, MPP, UCP and ACP. These are relevant only when the site wants agents to transact or pay programmatically.

Why site agent readiness matters

An ordinary website is primarily designed for a human using a browser and for crawlers discovering documents. An agent may need to do more. It may need to discover a machine-readable representation, understand whether automated access is allowed, identify an API, discover an authorization server, find callable tools, or complete a transaction. Agent readiness is the technical layer that makes those capabilities easier to discover without prior integration.

The important distinction is maturity. Some signals are established web standards. RFC 9309 standardizes robots.txt. RFC 8288 standardizes Web Linking. RFC 9727 defines API Catalog discovery, while RFC 8414 and RFC 9728 define OAuth discovery metadata. These should not be treated the same as protocols that are still drafts or proposals.

Discoverability: can an agent find the machine-readable surface?

Discoverability begins with durable web fundamentals. robots.txt gives crawlers standardized access rules, while a sitemap provides URL discovery hints. HTTP Link headers can advertise typed relationships without requiring a client to parse the page body. For API publishers, RFC 9727 takes this idea further with a standardized /.well-known/api-catalog discovery point.

DNS-AID is more experimental. The current IETF Internet-Draft proposes an organization-level agent index at _index._agents.<domain> using SVCB records. Internet-Drafts are works in progress, so a missing DNS-AID record should not be interpreted as a technical defect.

Content accessibility: can an agent request a cleaner representation?

HTML is designed for browsers and can include navigation, scripts, styling hooks and other markup that is not always useful to an agent extracting the main information. Cloudflare Markdown for Agents uses standard HTTP content negotiation so a client can send Accept: text/markdown and receive a Markdown representation when the site supports it. This is optional and emerging, but it demonstrates how the same URL can expose a lower-overhead machine representation without creating a second content system.

Bot access control: policy is different from identity

robots.txt communicates crawler access preferences, but RFC 9309 explicitly says it is not an authorization mechanism. Cloudflare's Content Signals proposal adds another policy layer by expressing preferences such as search, ai-input and ai-train. These signals are useful for policy communication, but they do not cryptographically prove who is making a request.

That is the problem Web Bot Auth is trying to address. The current IETF draft uses HTTP Message Signatures and a Signature-Agent identity mechanism so an origin can verify automated traffic more confidently than from a user-agent string alone. Cloudflare's implementation documents a public key directory at /.well-known/http-message-signatures-directory. This remains work in progress, so the checker labels it Draft.

Protocol discovery: moving from reading to acting

For an agent to act on a service, it needs more than readable content. It may need to discover an API and learn how authentication works. RFC 9727 provides API Catalog discovery. RFC 9728 provides Protected Resource Metadata for a resource server, and RFC 8414 provides authorization-server metadata. Together, these standards can reduce the amount of hard-coded configuration needed before a client can understand a protected API.

Several newer agent-specific discovery mechanisms build on the same idea. The MCP experimental Server Card extension describes domain-level discovery through an AI Catalog at /.well-known/ai-catalog.json. The project explicitly labels Server Cards experimental, so the tool does too. A Cloudflare-led Agent Skills discovery draft proposes /.well-known/agent-skills/index.json.

WebMCP takes a different approach by proposing browser-mediated tools that a page can register for an agent. Agentic Resource Discovery proposes federated resource discovery through /.well-known/ard.json, HTML/HTTP links and other mechanisms. Both remain evolving specifications, so their presence is useful evidence of experimentation rather than a requirement for an agent-ready site.

Commerce: can an agent transact without imitating a human checkout?

Agentic commerce is developing along several paths. x402 uses HTTP 402 to support programmatic payments between clients and servers. Machine Payments Protocol can expose payment offers through OpenAPI metadata such as x-payment-info. Universal Commerce Protocol publishes a business profile at /.well-known/ucp so platforms can discover capabilities and payment handlers.

Agentic Commerce Protocol defines programmatic checkout interfaces for agents and sellers. Its public documentation currently says discovery mechanisms are still being developed. For that reason the ACP row in this checker is informational and does not penalize the readiness score when no public marker is found.

What the score should change

The useful output is not the number by itself. A low Discoverability score suggests that machine clients have difficulty finding the site's public control or discovery surfaces. A weak Bot Access score means automated-access policy or bot identity mechanisms are not explicit. A low Protocol Discovery score matters primarily when the site exposes APIs or agent-callable actions. A low Commerce score matters only when the business intends agents to purchase or pay programmatically.

For AEO, SEO and GTM teams, this creates a practical separation between content optimization and machine interoperability. Strong content can still be difficult for an agent to act on if the API, authentication or commerce surface is not discoverable. Conversely, excellent protocol metadata does not make weak content more authoritative or more likely to be cited. Both layers matter, but they solve different problems.

Important: Site agent readiness is not a published ranking factor for Google, ChatGPT, Claude or another answer engine. The checker measures technical coverage of public standards and emerging conventions. Implement only the capabilities that match the site's product and operating model.

Primary technical references

Frequently asked questions

A site agent-readiness check looks for machine-readable signals that can help automated agents discover a site, retrieve content, understand bot-access preferences, locate APIs or authentication metadata, and discover supported commerce protocols. It is broader than SEO because an agent may need to read, call or transact with a service rather than only index a page.

Enter a public website URL, choose the site profile that best matches the property, and run the scan. Content Site scores discoverability, content accessibility and bot access. API / Application also scores protocol discovery. Commerce scores all five categories. All Checks is useful for technical teams exploring the full emerging agent-web surface.

The score is a Hota Digital heuristic based on the checks applicable to the selected site profile. Established standards receive more weight than drafts and experimental conventions. Use the category scores and individual evidence to decide what is relevant to implement. The score is not a standards-compliance certificate or an AI ranking score.

No. These checks are not published ranking factors for Google, ChatGPT, Claude or other answer engines. They measure technical discoverability and interoperability signals. Search and answer visibility still depend on content quality, relevance, authority, indexing, retrieval systems and platform-specific behavior.

robots.txt is standardized by RFC 9309 and gives crawlers access rules for URI paths. It is useful for communicating crawler preferences, but the RFC explicitly states that robots.txt is not an access-authorization mechanism. The checker also looks for explicit rules for several commonly used AI crawler user agents.

A sitemap helps crawlers discover canonical URLs and changes at scale. The checker looks for Sitemap directives in robots.txt and the common /sitemap.xml location. A sitemap is a discovery hint, not a guarantee that a search engine or agent will fetch every listed URL.

HTTP content negotiation allows a client to ask for a preferred representation. Cloudflare Markdown for Agents uses Accept: text/markdown and can return a text/markdown response. This can reduce HTML overhead for agents, but it is an optional emerging capability rather than a requirement for every website.

Content Signals is a Cloudflare-proposed extension to robots.txt for expressing preferences such as search, ai-input and ai-train. It is distinct from the standardized allow and disallow rules in RFC 9309. The checker labels it as emerging so its absence is not treated like a broken web standard.

Web Bot Auth uses HTTP Message Signatures so automated clients can cryptographically identify themselves. The current IETF work defines a Signature-Agent mechanism and key discovery, while Cloudflare documents a key directory at /.well-known/http-message-signatures-directory. It remains work in progress, so this checker labels it as Draft.

DNS-AID is an active Internet-Draft proposing SVCB-based discovery for agents, including an organization index at _index._agents.example.com. It is not an RFC. The checker reports whether related DNS records are visible and treats the result as an experimental discovery signal rather than a requirement.

RFC 9727 defines /.well-known/api-catalog and an api-catalog link relation to help clients discover APIs published by an organization. For API and application sites, this is one of the more mature machine-discovery signals checked by the tool.

RFC 8414 defines OAuth authorization-server metadata and RFC 9728 defines OAuth 2.0 Protected Resource Metadata. Together they let clients discover how a protected API identifies itself, which authorization servers it uses and what authentication endpoints or scopes are available.

auth.md is an emerging WorkOS protocol that publishes human and agent-readable authentication guidance at /auth.md. WorkOS describes RFC 9728 Protected Resource Metadata as the authoritative structured source, with auth.md acting as a prose companion.

An MCP Server Card is an experimental discovery document describing a remote Model Context Protocol server and how to connect to it. The current MCP experimental extension recommends discovering cards through an AI Catalog at /.well-known/ai-catalog.json. It is not part of the stable MCP core specification yet.

Agent Skills package domain-specific instructions and supporting resources for agents. A Cloudflare-led draft proposes discovery through /.well-known/agent-skills/index.json. Because that discovery mechanism is still a draft, the checker reports it as an emerging interoperability signal.

WebMCP is a W3C Web Machine Learning Community Group proposal for web pages to expose callable tools to browser agents through a model-context API. This checker can only inspect static HTML for recognizable WebMCP markers, so a negative result is not definitive when a site registers tools dynamically in JavaScript.

Agentic Resource Discovery, or ARD, is a 2026 proposal for federated discovery of agentic resources such as MCP tools, A2A agents and skills. The proposal defines /.well-known/ard.json and rel=ard discovery. It is labeled Proposal in this checker and should not be confused with an IETF or W3C standard.

These protocols address different parts of agentic commerce and machine payments. x402 uses HTTP 402 for internet-native payments, MPP publishes payment offers in API descriptions, UCP publishes commerce capabilities at /.well-known/ucp, and ACP defines programmatic checkout interfaces. They are relevant primarily to commerce or paid APIs, not to every content website.

No. A content publisher does not need agentic checkout protocols, and an API may not need Markdown conversion. Choose the site profile that reflects the actual business. The value of the audit is identifying relevant gaps while distinguishing established standards from optional and experimental capabilities.

The checker makes public HTTP and DNS requests only. It does not log in, submit forms, execute browser JavaScript, test live MCP calls, validate cryptographic Web Bot Auth signatures or complete payments. Some capabilities can therefore exist without being detectable by this static server-side scan.

Why this output matters

Agent readiness shows how much machine-readable infrastructure a site exposes beyond ordinary human browsing. The output helps AEO, web, product and GTM teams separate durable web standards from emerging agent protocols, identify relevant discovery gaps and decide where machine-readable access, authentication or commerce support is worth implementing.

Related AEO tools

View AEO tools