Agentic SEO: 1 of 1,419 sites published an agent card, and 55 of the 69 OAuth documents came from a platform default

What does agentic SEO actually require you to publish?

The honest answer is one file, and almost nobody is asking for it by name. The IANA Well-Known URIs registry is the list that decides whether a path under /.well-known/ means anything to a client that did not read your documentation, and it exists because RFC 8615, published in May 2019, reserved that prefix and required registration so two vendors could not quietly claim the same filename. Read at www.iana.org/assignments/well-known-uris on 19 September 2026, with the page carrying a last updated date of 2026-09-16, that registry holds 105 suffixes. One of them names an agent: agent-card.json, status permanent, change controller Linux Foundation, registered on 1 August 2025.

What goes at that path is specified. The A2A Protocol Specification, version 1.0.0 at a2a-protocol.org/latest/specification/, says in section 8.2 that a client can find an agent by requesting https://{server_domain}/.well-known/agent-card.json, and section 4.4.1 lists eight fields a card is required to carry: name, description, supportedInterfaces, version, capabilities, defaultInputModes, defaultOutputModes and skills. That is a complete, testable definition of what a site has to serve, which is more than can be said for most of what gets filed under generative engine optimization.

The Model Context Protocol, the other standard in this conversation, defines no site level discovery path at all. Its authorization specification at modelcontextprotocol.io describes a client that receives a 401, reads a WWW-Authenticate header, then fetches /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server. Both of those are registered, both are OAuth documents, and neither is an announcement that a site has anything for an agent to do. An MCP server is something a client is told about. It is not something a client finds by looking.

That gap is where the unregistered paths come from, and one of the files we found says so in its own text. Postman serves a document at /.well-known/mcp.json whose first key is a comment explaining that this is not an MCP server card, that the current draft places cards at the server's own URL under /server-card, and that domain level discovery is proposed at /.well-known/ai-catalog.json. Cloudflare's file at the same path points at a third location, /.well-known/webmcp.json, which is the interface this blog measured when Cloudflare put a WebMCP interface on any site and only a browser could find it.

One usable agent card in 1,419 hostnames

The corpus is the two seed frames committed in this repository, 1,027 industry hostnames stratified by sector and 392 chosen for the platform they run on, so it is an editorial sampling frame of large organisations and small businesses rather than a random draw of the web. Every figure below is a count of those 1,419 hostnames on one day.

Asked for the agent card, 1,375 hostnames returned an HTTP status and 44 failed at the transport layer, 25 of them timing out and 19 refusing the connection. 929 answered 404, which is the correct answer for a site with no agent. 229 answered 403 and 49 answered a 5xx, which is not an answer about agents at all: those sites refused the client. This blog has measured that refusal directly before, when 79 of 115 sites refused a crawler their own robots.txt allows, and it means every rate here is a rate among hosts willing to talk to an unfamiliar AI crawler.

131 hostnames answered 2xx. Two of those returned a parseable JSON object, and only one returned an agent card: monday.com, whose card names an MCP server at mcp.monday.com, declares one skill with the id monday-api, and carries seven of the eight required fields. The missing one is supportedInterfaces, the field version 1.0.0 introduced to replace a bare url, so the single card in the corpus is written against the older shape of the specification. The other JSON object was healthline.com, which is not a card at all.

The unregistered path did slightly better and tells you who is using it. Six hostnames returned JSON at /.well-known/mcp.json, and after removing healthline.com the five are cloudflare.com, notion.com, sentry.io, postman.com and monday.com. Every one is a software vendor that publishes an MCP server of its own, named in the file it serves. Not one is a shop, a newspaper, a hospital or a government department, which between them make up most of the corpus. Across both paths, registered and unregistered, the number of hostnames in this sample publishing a machine readable description of what an agent could do with them is six.

129 of the 131 sites that answered 200 were not answering the question

This is the part that matters for anyone writing a checker rather than a checklist. 131 hostnames returned a 2xx status at the agent card path and 129 of them returned something that was not a JSON document. 126 of those carried a text/html content type: a site's ordinary page, served with a 200, for a path that does not exist. A client that treats a 200 as discovery would record 131 agent enabled sites on this corpus. The real number is one.

The same shape has turned up in every path measurement on this blog. 33 sites answered a robots.txt request with a web page in the robots.txt validator run of 19 September 2026, and an llms.txt survey found 31 real files and one whose 75 links all 404. A soft 200 is the default behaviour of a single page application router and of several content management systems, and it converts every probe into a false positive.

healthline.com is the clearest single case, because it does return JSON. Asked for the agent card, for mcp.json and for the OAuth document, it returned the same three line file each time, a Global Privacy Control signal reading gpc true with a lastUpdate of 2023-12-15. That is a valid document at the wrong three addresses, and a parser that checks only that the bytes are JSON would count healthline.com as an agent, an MCP server and an OAuth protected resource on the strength of a privacy preference set in 2023.

126 hostnames answered 2xx at all three well-known paths, and on 121 of them not one response parsed as JSON. So the test that separates a discovery document from a decorated 404 is not the status code and not the content type. It is parsing the body and checking that the fields the specification requires are present, which is the same difference that separates a page carrying a script tag from a page whose structured data actually parses into the type it claims.

The one interface with real deployment arrived as a platform default

70 hostnames served a parseable document at /.well-known/oauth-protected-resource, and removing healthline.com leaves 69. This is the registered path from RFC 9728, published in April 2025, which defines how a client learns which authorization server guards a protected resource, and it is the first document an MCP client fetches after a 401. Its presence is the strongest available signal from outside that a host has something an agent authenticates to.

55 of the 69 were emitted by a platform. 39 name an authorization server at shopify.com, one per storefront, with a numeric shop identifier in the path and the store's own origin as the protected resource. 16 declare a resource at /wp-json/mcp/mcp-oauth-server, the WordPress REST API namespace, and scope it to a value literally called mcp. The remaining 14 are bespoke and they read like it: gitlab.com declares /api/v4/mcp, huggingface.co declares /mcp, and sourcegraph.com, sentry.io, circleci.com and monday.com each declare their own.

The clearest number in this measurement is the platform one. 33 of the 34 Shopify storefronts in the platform frame served the document, every one of them in the shopify.com pattern, and the single exception was hiutdenim.co.uk. All 39 of the Shopify pattern files carry the same three fields and declare the store origin as the protected resource, with 13 of them naming a custom account subdomain ahead of the shopify.com address, so what varies between them is the shop identifier and nothing else. That is the signature of a file shipped by the platform, in the same way it ships the server rendered Liquid theme described in our Shopify fix guide, and it is how the last two machine readable surfaces spread as well: 38 Shopify stores served 1,112 products as open JSON because the storefront emits /products.json, and 16 of 24 WordPress sites named no AI crawler in robots.txt because the default file names none.

Two qualifications, because this document is easy to over-read. It is an OAuth document, not an agent manifest: 22 of the 69 mention MCP anywhere in their bytes, and the 39 Shopify files do not mention it at all, declaring only that the origin is a protected resource with an authorization server. And publishing it says nothing about what an agent can then do, which this blog has measured on the other side of the connection: MCP labels stop at the MCP server.

How a client gets from a URL to a tool call, and where a site can be seen

Putting the specifications end to end explains why the deployment numbers look the way they do. There are two routes into a site and they are not equally visible from outside.

The A2A route is a single request. A client that knows a domain asks for /.well-known/agent-card.json, and the card it gets back names the interfaces, the skills and the security schemes in one document. That is a discovery protocol in the ordinary sense: nothing had to tell the client anything except the domain. It is also the route with one deployment in 1,419 hostnames.

The MCP route starts somewhere else. A client already holds a server URL, from a directory, a configuration file or a human, and it sends a request. The server answers 401 with a WWW-Authenticate header naming its resource metadata, the client fetches /.well-known/oauth-protected-resource, follows that to the authorization server metadata, completes an OAuth flow and then makes its first real call. Every step is specified, and the first step is not discovery. It is authentication for something the client had already been handed.

The practical consequence for a site owner is that the popular protocol leaves almost no trace a third party can see, so any count of MCP adoption taken from the outside, including this one, is a count of the door rather than the building. The one artefact that does show up is the OAuth document, which is why the number 69 is both the largest here and the least meaningful. It measures how many hosts have an authenticated resource of some kind, with 39 of them measuring Shopify's decision rather than any merchant's.

There is a second consequence worth stating plainly for anyone acting on an agentic SEO checklist. A card at a registered path is cheap, testable and visible to any client that looks, and the reason to publish one has nothing to do with rankings. It is the only way a site currently has to say, in a form a machine can read without being told where to look, that it has something for an agent to do.

What to check on your own site, and what this measurement does not show

The crawler vendors are not ahead of the corpus here, which is worth knowing before acting on anyone's advice. Lantad requested the same paths from the nine documentation hosts named in this repository's crawler registry plus the apex of each, 17 hostnames in all, on 19 September 2026. One served an agent card: docs.perplexity.ai, and it carries all eight required fields while declaring protocolVersion 0.3 rather than 1.0. Its companion mcp.json names an endpoint at a mintlify.me address, which is the documentation platform rather than Perplexity, so that card reached the web the same way the Shopify files did. The other 16 hosts returned 404 at all three paths, including google.com, openai.com, claude.com, apple.com and amazon.com.

Three checks a site owner can run today, none of which needs a vendor. Request your own /.well-known/agent-card.json and confirm you get a 404 rather than your home page with a 200, because a soft 200 there is the same defect as a soft 200 anywhere and it will make every external checker wrong about you. If you run Shopify or WordPress, request /.well-known/oauth-protected-resource and read what your platform is already declaring on your behalf. And if you publish a card, validate it against the eight required fields rather than against a vendor's blog post, since the one card in this corpus fails that test.

What this measurement does not show is large and worth naming. No agent was observed. Nothing here says any client fetched any of these files, and the absence of a documented reader is a fact about documentation, not about behaviour, exactly as it was when we found 86 of 762 sites declaring an RSS feed that no crawler vendor documents reading. Neither does it measure MCP adoption, for the reason set out above: a server whose clients are configured by hand publishes nothing a stranger can count. The corpus is an editorial frame, 278 hosts refused this client outright, and 44 never answered.

One more limit belongs to this scanner rather than to the web, and it is the same admission the llms.txt evidence post made about a file we ship a tool for. Lantad does not check any of these paths. A scan reads robots.txt per crawler, fetches the page as a crawler would and grades what is extractable, which you can see with what GPTBot sees, and it reports on an llms.txt. It has nothing to say yet about an agent card, on a measurement where 302 of these hosts publish the unregistered llms.txt and one publishes the registered card. The full method behind every figure here is the one described in our scan methodology, and the corpus frames are the same ones used for web bot authentication key directories and for the 2,209 crawler user agent tokens counted in 1,004 robots.txt files.