AgenticWebScore
Scan

Learn

Lighthouse agentic browsing vs agent readiness: what each of the 7 audits checks, one by one

What Lighthouse's Agentic Browsing audits check, mapped to AgenticWebScore's checks, with what a rendered page shows that an HTTP scan cannot, and the reverse.

8 min read 1291 words

  • Lighthouse
  • agentic browsing
  • WebMCP
  • llms.txt

Lighthouse's Agentic Browsing category is an experimental set of 7 audits that run in Chrome 150 or later. They check the accessibility tree, WebMCP tools, layout shift, llms.txt and an ARD manifest, and report a pass ratio, not a 0–100 score. AgenticWebScore reads 3 of the same subjects over plain HTTP, plus files the category never requests. Lighthouse sees the rendered page, and the scan sees what a server sends.

What is Lighthouse agentic browsing?

Chrome's documentation calls the category experimental and based on proposed standards. It has no weighted 0–100 score. The report shows a fraction, described as the ratio of checks a site passes.

The releases page shows how fast it has moved:

  • v13.2.0, 1 May 2026: the category and its first audits.
  • v13.3.0, 7 May: the category joins the default config.
  • v13.4.1, 20 July: the WebMCP gatherers check document.modelContext, and the viewer enables the category through the PSI API.
  • v13.5.0, 18 September: the ard-schema audit, a new "agent discovery" group for the llms.txt and ARD audits, and changes to two WebMCP audits.

The 13.5.0 notes say the release should reach Chrome 156 DevTools and PageSpeed Insights within 2 weeks. The category page was last updated on 5 May 2026 and does not mention ARD.

For the audit details below I read the sources on the Lighthouse main branch on 27 October 2026. Main can be ahead of the release you run.

How do Lighthouse's audits map to agent readiness checks?

The category config lists 7 audits with equal weight, under the key agentic-browsing. The table sets each against the scanner's rubric v0.9.

How do Lighthouse's audits map to agent readiness checks? — Lighthouse audit, What it does, Scanner check, How they differ
Lighthouse audit What it does Scanner check How they differ
agent-accessibility-tree Counts violations of 33 axe rules in the rendered page, such as button-name, link-name and label. Scores 1 with none, otherwise 0. None The scan runs no browser. The meta check reads the served <title>, the one overlap, with document-title.
webmcp-registered-tools Lists the tools registered when it runs. Informational. Warns above 40 tools. webmcp The scan counts registerTool( in the homepage HTML. A tool a script registers at runtime is invisible to it.
webmcp-form-coverage Lists forms with neither toolname nor tooldescription. Informational. webmcp A homepage with forms and no declared tool reads Not used. With no form and no call it is out of scope.
webmcp-schema-validity 0 for a form with only one of the two attributes, or a required field without a name. 0.5 for warnings. webmcp A call or form missing a piece earns half points. The scan does not check form fields.
cumulative-layout-shift Measures layout shift while the page loads. None It needs a rendered page.
llms-txt Fetches /llms.txt and checks its content. llms-txt The rules differ. See the next section.
ard-schema Validates an ARD manifest with the ARD conformance tests. ard-manifest The check is unscored here: it earns no points and never fails.

Chrome's pages and the code differ on one point. The documentation says the form audit flags a form that lacks either attribute. The code lists a form only when it lacks both. A form with just one is caught by the schema audit instead.

Lighthouse also marks several states notApplicable. That is its own term, and it is not the scanner's out of scope.

How do Lighthouse and the scan read llms.txt differently?

The Lighthouse audit marks a 404, or any 4xx but 429, notApplicable. A 5xx, a 429 or a failed fetch scores 0. Otherwise it needs a line that starts with # , one markdown link, and at least 50 characters.

The scan's llms-txt check wants a 2xx answer served as text/plain or text/markdown, with an H1 on the first line. It then requests up to 6 same-origin links the file names. A 404 reads Not used, and a dead link reads served with an error.

Applied to the same file, the published rules give different answers. This comes from reading both rule sets, not from a run.

How do Lighthouse and the scan read llms.txt differently? — File, Lighthouse, Scan
File Lighthouse Scan
Only # Acme, 6 characters Fails: no link, too short Present: it needs an H1
H1 on line 3, after other lines, file otherwise valid Passes Served with an error: the H1 is not first
H1 and a link to a same-origin page that answers 404 Passes Served with an error
/llms.txt answers 404 notApplicable Not used

Google's AI optimization guide says Google Search ignores llms.txt, so a Lighthouse pass tells you nothing about Search. What llms.txt is and what it is not covers who does read it.

How do the ARD audit and the manifest check differ?

The ARD specification, v0.91 of 26 August 2026, names /.well-known/ard.json for the manifest. It lists ai-catalog.json as the predecessor path. An entry needs identifier, displayName, type and exactly one of url or data.

In a report of 21 September 2026, Search Engine Journal read the 13.5 source. The fallback path was /.well-known/ai-catalog.json, and it found no reference to ard.json. The main-branch audit I read on 27 October lists ard.json and rel="ard" as current, and ai-catalog.json as legacy. It scores 0.9 for a manifest that has warnings or comes from a legacy source.

The scan's ard-manifest check reads a rel="ard" link, a Link header, and 4 paths: /.well-known/ard.json, /.well-known/agent-resources.json, /.well-known/ai-catalog.json and /ard.json. It does not read an Agentmap line in robots.txt, which the Lighthouse audit lists as a signal.

On 20 October 2026 the scan found a manifest at /.well-known/ai-catalog.json on vercel.com, with 6 complete entries. This site has none.

curl -sSL -o /dev/null -w 'ard.json %{http_code} %{content_type}\n' "$ORIGIN/.well-known/ard.json"

ard.json 404 text/html; charset=utf-8

What can Lighthouse see that the scan cannot, and the reverse?

Lighthouse loads the page in Chrome. It can see the accessibility tree, the layout shifts, and the WebMCP tools the browser holds after scripts have run. A scan over HTTP sees none of these. It reports a bare JavaScript shell as not measured.

The scan reads files and headers the agentic category never requests. The category has no audit for:

  • the 18 AI crawler tokens in robots.txt, or a sitemap;
  • ETag and 304 answers, or the status of a missing page;
  • markdown negotiation;
  • an MCP handshake, a server card, OAuth discovery or an OpenAPI file;
  • a status page.

Lighthouse's separate SEO category does cover a valid robots.txt, a canonical link and the HTTP status of the page, according to its documentation.

The two also differ in reach. Lighthouse runs in a browser on one page at a time, and can run on your own machine. The scan reads one origin from the outside and reports a score and a level.

How to use both

Run Lighthouse on your key pages and read the WebMCP and accessibility audits. Run the scan on the origin and read the file and header checks. Where they overlap, trust the one that can see the subject: Lighthouse for tools a script registers, the scan for the files at the root.

The readme says --only-categories takes category ids, and the config names this one agentic-browsing. That gives the command below. I did not run it. The WebMCP audits also need Chrome's origin trial.

lighthouse https://example.com/ --only-categories=agentic-browsing

For the other side, scan your site. Cloudflare and Lighthouse compared puts both next to the scanner. WebMCP vs MCP covers the 3 WebMCP audits in more depth, and how to make your website agent-ready lists the HTTP steps.