# 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.

- Source: /learn/lighthouse-agentic-browsing-vs-agent-readiness
- Updated: 2026-10-27
- Reading time: 8 minutes
- Tags: 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](https://developer.chrome.com/docs/lighthouse/agentic-browsing) 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](https://github.com/GoogleChrome/lighthouse/releases/tag/v13.5.0) 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](https://github.com/GoogleChrome/lighthouse/blob/main/core/config/agentic-browsing-config.js) lists 7 audits with equal weight, under the key `agentic-browsing`. The table sets each against the scanner's rubric v0.9.

| 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](/checks/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](/checks/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](/checks/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](/checks/llms-txt) | The rules differ. See the next section. |
| `ard-schema` | Validates an ARD manifest with the ARD conformance tests. | [ard-manifest](/checks/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](https://github.com/GoogleChrome/lighthouse/blob/main/core/audits/agentic/llms-txt.js) 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](/checks/llms-txt) 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.

| 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](https://developers.google.com/search/docs/fundamentals/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](/learn/llms-txt-guide) covers who does read it.

## How do the ARD audit and the manifest check differ?

The [ARD specification](https://agenticresourcediscovery.org/spec/), 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](https://www.searchenginejournal.com/google-lighthouse-ai-agent-resource-discovery-audit/590274) 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](/checks/ard-manifest) 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.

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

```text
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](https://developer.chrome.com/docs/lighthouse/seo).

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.

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

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