About CanAgentUse
A simple crawler can tell you whether a file exists. CanAgentUse goes deeper. It fetches the agent-facing resources, parses their structure, checks the fields agents depend on, verifies URLs and relationships, and turns each failure into a fix a product or engineering team can ship.
Current scanner coverage
Why it exists
Human visitors still matter. Search still matters. But websites are now inspected by systems that fetch pages, read metadata, compare structured data to visible content, inspect API contracts, look for authentication metadata, and decide whether a task can be completed safely. CanAgentUse shows what those systems can discover today and where the site breaks down.
The scanner requests real URLs such as /robots.txt, /llms.txt, /.well-known/api-catalog, /.well-known/oauth-protected-resource, /auth.md, agent cards, MCP metadata, and DNS-AID records. A link in the HTML is not enough. The resource has to resolve cleanly and carry useful content.
CanAgentUse parses JSON-LD, OpenAPI, OAuth/OIDC metadata, Web Bot Auth directories, MCP server cards, WebMCP hints, A2A agent cards, skills indexes, sitemap files, and link headers. It looks for required fields, bad URLs, weak descriptions, missing auth hints, and broken relationships.
For APIs and agent-facing protocols, the report is not a badge for publishing a file. It checks whether agents can understand available operations, auth requirements, transports, scopes, tool metadata, payment hints, and safe fallback paths before they try to act.
Failed checks include the resource that was inspected, the status code or parsed field that caused the failure, why it matters, and a concrete fix. The goal is a patchable issue, not a vague SEO score.
What the scanner validates
The useful question is not "does this site have a standards-looking file?" The useful question is whether an agent can trust that file enough to use it.
Coverage
Agent readiness is not one protocol. A site can have great schema and still fail bot access. It can publish OpenAPI and still hide auth requirements. It can pass Lighthouse and still give agents no safe way to discover actions. CanAgentUse keeps those checks together because the failure usually sits between teams.
46
The primary checks shown as report sections and listed in the public catalog.
robots.txt, llms.txt, Structured data, OpenAPI, OAuth discovery, MCP server card, WebMCP, Agent commerce
44
Step-level checks that appear inside richer report sections when the scanner validates a resource or analyzes AI SEO readiness.
Fetch discovery resource, Validate resource body, Verify advertised endpoints, Check machine-usable API details, AI crawler accessibility, Answer-first sections
47
Browser-based technical audit signals in scan reports: category scores, grouped audit families, and focused direct audits.
Performance score, Accessibility score, SEO score, Best-practices score, Loading performance, Image optimization, Focused browser audit findings
Standards and conventions
The scanner tracks practical agent-facing surfaces: robots.txt, sitemaps, llms.txt, ai.txt, TDMRep, Content Signal, API catalogs, OpenAPI, OAuth/OIDC discovery, OAuth Protected Resource Metadata, Auth.md, HTTP Message Signatures, MCP, WebMCP, A2A cards, skills indexes, x402, MPP, UCP, ACP, schema.org, and JSON-LD.
How to use it
Built for implementation
Every report is meant to help product, SEO, engineering, and AI platform teams agree on the same thing: which agent-facing surface failed, what evidence proves it, which standard or convention applies, and what needs to change before the next scan.
