ardregistry.net

Guide

The Lighthouse ARD audit

A new Chrome audit that checks the old path. Here is how to pass it and the spec at once.

Lighthouse 13.5 validates your Agentic Resource Discovery catalog in its experimental Agentic Browsing category. It follows a pointer if you give one, and otherwise reads /.well-known/ai-catalog.json, the path ARD v0.91 replaced with /.well-known/ard.json. Serve the same file at both paths and add a pointer, and you pass Lighthouse and the specification together.

Check your site now

Enter a domain. The check reads the pointer locations the specification defines, then both manifest paths, and tells you two separate things: whether Lighthouse 13.5 should find a valid catalog, and whether a client following ARD v0.91 will.

What the audit is

Lighthouse version13.5, released 18 September 2026
CategoryAgentic Browsing (experimental), not SEO
ScoringPass or fail per audit, no 0 to 100 score
Where it looksA catalog pointer first; without one, /.well-known/ai-catalog.json
Current spec path/.well-known/ard.json, since ARD v0.91 on 26 August 2026
What it validatesThe catalog against the schema the ARD project publishes

Sources: Chrome's documentation of the ARD audit, how the Agentic Browsing category is scored, and Search Engine Journal's reading of the 13.5 source.

Why a site on the current spec can fail

ARD v0.91 made /.well-known/ard.json the normative path and kept /.well-known/ai-catalog.json as the predecessor a consumer may consult. Lighthouse 13.5 went the other way round: with no pointer to follow, it fetches the predecessor. So the sites most likely to fail are the ones that migrated early and removed the old file.

The fix that satisfies both Serve the same manifest at both paths, and add a pointer. Then Lighthouse finds it through the pointer or the old path, and every ARD v0.91 client finds it at the new one.

The three changes, copy and paste

1. Serve the file at both paths. In nginx:

nginx
location = /.well-known/ard.json        { alias /var/www/ard.json; default_type application/json; }
location = /.well-known/ai-catalog.json { alias /var/www/ard.json; default_type application/json; }

2. Point to it from every page, in the head:

HTML
<link rel="ard" href="https://example.com/.well-known/ard.json">

3. And from robots.txt, one line:

robots.txt
Agentmap: https://example.com/.well-known/ard.json

Recipes for Apache, Netlify, Vercel, Cloudflare, Next.js, FastAPI, Express, Django and WordPress are on the publishing guide. After the change, run the check above again, then validate the file itself against v0.91.

Questions

Does the Lighthouse ARD audit affect my Google ranking?
No evidence says so. The audit sits in Lighthouse's experimental Agentic Browsing category, separate from SEO, and Search Engine Journal found no link to Google Search in the 13.5 release notes. It tells you whether agents can find your resources, which is a different question.
Why does my site fail when I serve /.well-known/ard.json?
Lighthouse 13.5 looks for a pointer to your catalog first and, finding none, falls back to /.well-known/ai-catalog.json. ARD v0.91 moved the default to /.well-known/ard.json on 26 August 2026, so a site that only serves the new path and has no pointer is checked at the old path.
Should I serve both ard.json and ai-catalog.json?
Yes, with the same entries. The specification lets consumers consult the predecessor path, Lighthouse 13.5 reads it, and current ARD clients read ard.json. Serving one file at two paths costs nothing and satisfies both.
Is there a score?
Not out of 100. Chrome's documentation says the Agentic Browsing category is scored as audits passed rather than a weighted average, and the category is marked experimental.
Where do I see the audit?
In Lighthouse in Chrome DevTools and, per the 13.5 release notes, in PageSpeed Insights.

Last reviewed 2026-11-01. Checked against ARD v0.91 (Proposal, 2026-08-26).