# ard.json: the Agentic Resource Discovery manifest and the ai-catalog.json rename
> ARD v0.91 asks sites to serve /.well-known/ard.json instead of ai-catalog.json. The fields, what Lighthouse 13.5 reads, and how this scanner checks it.
- Source: /learn/ard-json-agentic-resource-discovery
- Updated: 2026-10-27
- Reading time: 7 minutes
- Tags: ARD, ai-catalog.json, Lighthouse, discovery
---
`ard.json` is the manifest that the Agentic Resource Discovery (ARD) specification asks a site to serve at `/.well-known/ard.json`. Its `entries` array lists the MCP server cards, A2A agent cards and skills the site offers, one entry for each. Version 0.91 of the spec, dated 26 August 2026, calls `/.well-known/ai-catalog.json` the predecessor path and tells publishers to move off it. Lighthouse 13.5.0, the release that added an ARD audit, still reads only the old names.
## What is Agentic Resource Discovery?
Google announced ARD on [17 June 2026](https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/) as an open specification for finding and verifying tools, skills and agents across the web. The [specification](https://agenticresourcediscovery.org/spec/) names Junjie Bu of Google, R.V. Guha and Shaun Smith of Hugging Face as its authors. It marks v0.91 as a Proposal under the Apache 2.0 licence.
ARD has 2 halves. Publishers host a catalog on their own domain. Registries crawl those catalogs, index them and answer search requests, which the spec defines as `POST /search`. This article covers the publisher half, because a site owner controls it and a scan can see it.
ARD describes none of the resources itself. Each entry names a media type, such as `application/mcp-server-card+json`, and the document behind its `url` follows the MCP or A2A specification. For those formats, read [MCP server cards](/learn/mcp-server-card) and the [A2A agent card example](/learn/a2a-agent-card-example).
## Is the file ard.json or ai-catalog.json?
It is `ard.json`, and the older name is still around. The Google announcement tells publishers to host an `ai-catalog.json` file at a well-known path. The specification of 26 August names `/.well-known/ard.json` in section 5.1 and calls the old path and the `ai-catalog` link relation the predecessor.
The consumer rule has 3 parts. A consumer MUST fetch `/.well-known/ard.json` and MUST honour a `rel="ard"` link. It MAY also read the predecessor names, which the spec calls a courtesy to earlier resources and not a conformance requirement. A resource left only at the old path may not be found, so a publisher there SHOULD move.
The spec lists 5 ways to point at entries. They are the well-known URI, JSON-LD embedded in a page, an `Agentmap:` line in `robots.txt`, `` in a page head, and DNS service binding records. It lists no HTTP `Link` header.
## What goes in an ard.json file?
The manifest needs 1 member, `entries`, and the [schema](https://github.com/ards-project/ard-spec/blob/main/spec/schemas/ard-entry.schema.json) requires nothing else. The spec says ARD ignores any other top-level member. This example follows the entry terms of section 4.2 and the examples of section 4.4:
```json
{
"specVersion": "1.0",
"entries": [
{
"identifier": "urn:air:example.com:mcp:docs",
"displayName": "Example docs search",
"type": "application/mcp-server-card+json",
"url": "https://example.com/mcp/server-card",
"description": "Search and read the public documentation of example.com.",
"representativeQueries": [
"find the rate limits in the example.com API docs",
"how do I authenticate with the example.com API"
]
},
{
"identifier": "urn:air:example.com:a2a:orders",
"displayName": "Order status agent",
"type": "application/a2a-agent-card+json",
"url": "https://example.com/.well-known/agent-card.json",
"description": "Answers questions about the status of orders placed on example.com.",
"representativeQueries": [
"where is my example.com order",
"when will order 10432 arrive"
]
}
]
}
```
Each entry takes these terms:
| Term | Requirement | What it holds |
|---|---|---|
| `identifier` | MUST | A handle of the form `urn:air::[:]`, where the publisher is a domain you control |
| `displayName` | MUST | A human-readable name |
| `type` | MUST | The IANA media type of the artifact, such as `application/a2a-agent-card+json` |
| `url` or `data` | MUST, exactly 1 | A link to the artifact, or the artifact inline. Not both |
| `representativeQueries` | SHOULD | 2–5 questions the resource can answer. A registry builds its search index from them |
| `capabilities` | MAY | Short tokens for structured filtering |
| `description`, `tags`, `version`, `updatedAt`, `metadata`, `trustManifest` | Optional | Descriptive terms |
`specVersion` is not an ARD v0.91 term. It is in the example because the Lighthouse 13.5.0 validator requires it, and the catalog examples of the [MCP server card extension](https://github.com/modelcontextprotocol/experimental-ext-server-card/blob/main/docs/discovery.md) carry it. ARD ignores it.
Trust goes in the optional `trustManifest`. ARD defines no signing scheme of its own, so verification follows the framework the manifest names. The one rule it adds: the domain in `trustManifest.identity` must match the publisher in the `urn:air:` identifier.
## What does Lighthouse's ard-schema audit read?
Lighthouse 13.5.0 added the `ard-schema` audit on 18 September 2026 and grouped it with the `llms.txt` audit under agent discovery, per its [release notes](https://github.com/GoogleChrome/lighthouse/releases/tag/v13.5.0). Chrome's agentic browsing documentation has no page for it, so the source is the reference. This section comes from the [gatherer](https://github.com/GoogleChrome/lighthouse/blob/v13.5.0/core/gather/gatherers/agentic/ard.js), the [audit](https://github.com/GoogleChrome/lighthouse/blob/v13.5.0/core/audits/agentic/ard-schema.js) and the [validator](https://github.com/GoogleChrome/lighthouse/blob/v13.5.0/third-party/ard/ard.js) at the v13.5.0 tag.
The released audit works from the old names:
- It takes the catalog URL from an `Agentmap:` line in `robots.txt`, then from a `` with `rel="ai-catalog"`, then from a `Link` header with `rel="ai-catalog"`. Otherwise it uses `/.well-known/ai-catalog.json`.
- It does not request `/.well-known/ard.json` by itself, and it ignores `rel="ard"`.
- With none of those 3 signals and no 200 at the catalog URL, the audit does not apply. Its code returns `notApplicable`.
- A catalog that loads goes through the validator, which reports the findings in the next table.
- Any error scores 0. Warnings alone score 0.9. A clean manifest scores 1.
| Finding in the catalog | Result |
|---|---|
| No root `specVersion` | Error |
| No `identifier`, `displayName` or `type` in an entry | Error |
| An `identifier` that is not a `urn:air:` URN | Error |
| Neither or both of `url` and `data` in an entry | Error |
| A root `collections` array | Error |
| No `representativeQueries`, or a count outside 2–5 | Warning |
| A media type outside the validator's list | Warning |
A site that follows v0.91 and publishes only `/.well-known/ard.json` therefore gets no result in 13.5.0. The same file at the old path, without `specVersion`, scores 0.
Issue [17251](https://github.com/GoogleChrome/lighthouse/issues/17251), "ard-schema not updated for ARD v0.91", was opened on 22 September. Pull request [17258](https://github.com/GoogleChrome/lighthouse/pull/17258) closed it on 9 October. On the main branch, the gatherer now tries `rel="ard"` and `/.well-known/ard.json` first and the old names last.
A manifest found only through an old name gets a low-severity warning and a score of 0.9. The validator follows the v0.91 schema, `specVersion` is optional and `collections` is a warning.
The [releases page](https://github.com/GoogleChrome/lighthouse/releases) listed no Lighthouse version after 13.5.0 on 27 October 2026, so the fix is on main and in no release yet. This is how the 4 readers compare:
| Signal | ARD v0.91 spec | Lighthouse 13.5.0 | Lighthouse main | This scanner |
|---|---|---|---|---|
| `/.well-known/ard.json` | Consumer MUST fetch | Not requested | First well-known path | Read |
| `/.well-known/ai-catalog.json` | Consumer MAY read | The only well-known path | Last, with a warning | Read |
| `` | Consumer MUST honour | Not read | Read | Read |
| `Link` header, `rel="ard"` | Not listed | Not read | Read | Read |
| `Agentmap:` in `robots.txt` | Listed | Read | Read | Not read |
In 13.5.0 the `` and `Link` header rows apply to `rel="ai-catalog"` instead.
## How does AgenticWebScore check ard.json?
The [ARD manifest check](/checks/ard-manifest) is an unscored agent convention marked experimental. It earns no points and gates no level. A site is asked for it only when the scan found an API or agent surface.
The scan requests the manifest that a homepage `` or `Link` header points at on the same site. It then tries 4 paths in order: `/.well-known/ard.json`, `/.well-known/agent-resources.json`, `/.well-known/ai-catalog.json` and `/ard.json`. The last 2 are not in v0.91. The first 2xx JSON document with a non-empty `entries` array is the manifest.
- **Present.** Every entry has `identifier`, `displayName` and `type`, plus exactly 1 of `url` or `data`.
- **Served with an error.** An entry lacks one of those terms, an entry carries both `url` and `data`, or JSON at a manifest path has no `entries`.
- **Out of scope.** The homepage links no manifest and all 4 paths answer 4xx. The Lighthouse audit does not apply in that case either.
- **Not measured.** A path did not answer, or answered 406 to the scan's `Accept` header.
The check reads the manifest and nothing it points at. It skips what Lighthouse validates: the `urn:air:` form of `identifier`, the media type, `representativeQueries` and `trustManifest`.
An entry written for the MCP extension has `identifier`, `type` and `url`, and no `displayName`, as the extension's own examples show. By the ARD rule it is incomplete, so a catalog of such entries reads Served with an error. The records of 20 October 2026 show that result for github.com and resend.com: 1 entry at `/.well-known/ai-catalog.json`, 0 complete. The records do not say which term is missing.
The same records show vercel.com with 6 entries at the old path, all complete, which reads present. All 3 manifests the scan read sit at `/.well-known/ai-catalog.json`.
The record of cloudflare.com shows 404 on all 4 paths, and so does this site's record of 25 October. Both read out of scope, and this site publishes no manifest. MDN was not asked, because the scan found no API or agent surface there.
## How do you publish ard.json?
1. Write the file from the example. Add 1 entry for each MCP server card or agent card you serve, with a domain you control in each `identifier`.
2. Serve it as JSON at `/.well-known/ard.json`.
3. Add `` to the homepage ``. The spec and this scanner both read it.
4. Decide about the old path. The spec says there is no need to serve it. Lighthouse 13.5.0 and the MCP extension's discovery notes still read `/.well-known/ai-catalog.json`, so serving the same file at both paths covers every reader for now. Generate both from one source so they cannot drift apart.
5. Check the result with curl:
```sh
curl -sS https://example.com/.well-known/ard.json \
| jq -c '.entries[] | {identifier, displayName, type, url}'
```
For the example above, that prints:
```json
{"identifier":"urn:air:example.com:mcp:docs","displayName":"Example docs search","type":"application/mcp-server-card+json","url":"https://example.com/mcp/server-card"}
{"identifier":"urn:air:example.com:a2a:orders","displayName":"Order status agent","type":"application/a2a-agent-card+json","url":"https://example.com/.well-known/agent-card.json"}
```
The spec also describes an official conformance tool in appendix D.4. It validates a manifest, or resolves a domain the way section 5.1 does.
## What ARD does not settle
ARD v0.91 is a Proposal. The spec's own note says media type registration is pending and the formats may change.
Whether a registry or an agent product reads `ard.json` today is not measured here. The 17 June announcement said native ARD support in Google's Agent Platform would arrive in the coming months. This article does not know whether it has. This site's rubric records no effect on Google Search for the check.
A manifest entry is a claim. The card it names still has to be served, and the server behind the card still has to answer. [Testing an MCP server with curl](/learn/test-mcp-server-curl) covers the second part.
To see how your own site reads, [scan it](/scan). The [methodology](/methodology) lists what each check requests.