The first time I ran the new category against our own site, we got 2 out of 3. The failure wasn't a missing file or a slow server. It was `llms.txt`, a file we had already published, formatted the way a human would write a list of links. Lighthouse read it and said: "File does not appear to contain any links."
That's the personality of this audit in one line. Tiny, picky, and perfectly happy to fail you for something you thought was done.
Most write-ups about it are guesses. This one is the source code and the actual runs. Here's every audit in the Lighthouse agentic browsing category, which ones fire on a stock browser, and what fixing each failure involves.
Where the Lighthouse agentic browsing category came from
Google shipped it in Lighthouse v13.3.0 on 2026-05-07, with a release note as unglamorous as it gets: "New agentic browsing category added to default config" (PR #17002). It landed in Chrome 150 DevTools when that went stable on 2026-06-30, and in PageSpeed Insights around the same time.
The category id is `agentic-browsing`. Three places to find it:
| Surface | How you get there |
|---|---|
| PageSpeed Insights | pagespeed.web.dev, run a URL, look for the Agentic Browsing block |
| Chrome DevTools | Chrome 150+, Lighthouse panel, tick the Agentic Browsing category |
| CLI | npx lighthouse <url> --only-categories=agentic-browsing |
One thing to get straight before you screenshot a score for a stakeholder deck: this category is not scored 0–100. It reports a fraction, like 2/3. And the denominator moves depending on which audits apply to your page, which trips people up constantly.
Google's own framing, from the scoring docs: "the current focus is to gather data and provide actionable signals rather than a definitive ranking." Their June 2026 agent-ready toolkit post is blunter still, calling Agentic Browsing "informational and unbenchmarked." Take that seriously. Nobody has shown this score moves traffic. What it does do is point a flashlight at real defects.
The six audits in the Lighthouse agentic browsing category
Straight from `core/config/default-config.js`:
| Audit | Type | What it checks |
|---|---|---|
| agent-accessibility-tree | Pass/fail | 38 axe rules (button-name, label, link-name, document-title, tabindex, autocomplete-valid, various aria-*). Any single violation scores 0. |
| cumulative-layout-shift | Scored | Standard CLS, same metric as Performance |
| llms-txt | Pass/fail | Format of the file, not whether you have one |
| webmcp-form-coverage | Informative | Forms missing toolname / tooldescription |
| webmcp-registered-tools | Informative | WebMCP tools the page registers |
| webmcp-schema-validity | Pass/fail | Errors in your WebMCP JSON Schema |
Google groups these into three concerns: accessibility, stability, and WebMCP integration.
Why you only ever see three of them
On a stock Chrome install, all three WebMCP audits return N/A. WebMCP is still an origin trial (Chrome 149 through 156, expiring around late October 2026), so unless you have explicitly registered tools behind that trial, there is nothing for those audits to look at. If you want the full story on that API and whether it's worth piloting, we covered it separately in WebMCP explained.
So in practice this is a three-check test:
- Accessibility tree
- CLS
- llms.txt format
And it can shrink to two. When we benchmarked real sites on 2026-08-26 with Lighthouse 13.4.1, airbnb.com scored 1/2. The denominator dropped because it has no llms.txt, which makes that audit N/A rather than a failure. Stripe scored 3/3. Shopify scored 2/3, failing the accessibility tree on ARIA role and button-name violations. Two of the most engineering-heavy sites on the internet, and one of them fails on buttons without names.
What the accessibility tree audit actually tests
This is the audit that matters most, and the one people keep misreading as an SEO checkbox.
Agents don't see your CSS. Per Google's own guidance on building agent-friendly sites, they read a page in three ways: screenshots, raw HTML, and the accessibility tree, which Google describes as "a high-fidelity map that ignores the visual 'noise' of CSS." If your button is a `<div>` with a click handler, the tree has no idea it's a button. The agent doesn't either.
Under the hood, `agent-accessibility-tree` is the axe rule set. Same engine as the free tier of axe DevTools, which is the cheapest way to iterate before re-running Lighthouse. The scoring is unforgiving: 38 rules, and one violation anywhere on the page takes the audit to zero. There's no partial credit, no "97% of your buttons are fine."
What fixing it usually means, in rough order of how often we hit it:
- Use `<button>` and `<a>` instead of `div` and `span` for anything clickable. Where you genuinely can't, add the right `role` plus `tabindex`.
- Give every control an accessible name. An icon-only button with no `aria-label` is the single most common failure we see.
- Wire up `<label for>` on every form field. Placeholder text is not a label.
- Fix `autocomplete` values that don't match the spec. Easy to get wrong, easy to fix.
- Keep interactive elements above roughly 8 square pixels of visible area, and kill transparent overlays sitting on top of your controls. Ghost overlays are miserable to debug and they break agents cold.
Worth saying plainly: Google does not ask for perfect semantic HTML, and their docs explicitly tell you not to worry about perfect code. This audit isn't a purity test. It's a floor.
Why CLS shows up in an agent audit
Same metric as Performance, different reason. Lighthouse's own rationale: "Agents that take screenshots will likely be confused if your website layout is constantly shifting."
For humans, layout shift is annoying: you go to tap something and it moves. For an agent working from screenshots, a shifting layout means it clicks the wrong thing, or clicks nothing at all. Google's guidance uses the example of an add-to-cart button that sits in a different place depending on the product category. A human adapts in a fraction of a second. An agent doesn't adapt at all.
If you've already done CLS work for Core Web Vitals, this one is free. If you haven't, the fix list is the standard one: reserve dimensions for images and embeds, stop injecting banners above existing content, and preload fonts you swap.
The llms.txt audit: format, not presence
This is the audit most likely to bite you, so here it is in full detail.
The logic, read from the Lighthouse source:
| Situation | Result |
|---|---|
| /llms.txt returns 404 | N/A. The audit is optional and simply drops out of your denominator. |
| File exists and passes all format checks | Pass |
| File exists and fails any format check | 0 |
Read that table again. A malformed llms.txt scores worse than no llms.txt at all. Publishing one is a decision that can only hurt your score if you get the format wrong.
The three format checks:
- It needs a Markdown H1, matched with the regex `/^\s*#\s+.+/m`. On its own line, hash, space, actual text.
- It needs at least one Markdown link, matched with `/\[.+\]\(.+\)/`. This is the one that got us. Plain-text URLs don't count, and neither do bare bullets. It has to be `Text` syntax.
- It needs to clear 50 characters. A near-empty stub fails.
Our fix was mechanical. Every line went from a plain-text bullet to:
- About Us: One-line description of the page.
Two things I want to be honest about. First, passing this audit says nothing about whether llms.txt does anything for you. Google Search ignores the file entirely, which is Google's own documented position, and the largest study to date found 97% of llms.txt files received zero traffic in the month sampled. We went through that evidence properly in does llms.txt actually work. Second, and despite all that: if you're going to ship the file, ship it format-correct. Lighthouse is grading it now, and a broken one is strictly worse than an absent one.
How to run the Lighthouse agentic browsing audit yourself
Fastest path, no install:
- Go to pagespeed.web.dev, paste your URL, run it.
- Scroll to the Agentic Browsing section. You'll see something like "2/3".
- Expand each failed audit. The accessibility tree audit lists the specific axe violations with the offending elements.
Local, and better for iterating:
npx lighthouse https://example.com --only-categories=agentic-browsing --view
That opens the HTML report in your browser. Drop `--view` and add `--output=json --output-path=./report.json` and you have something you can assert against in CI, which is honestly where this belongs. An accessibility regression is exactly the kind of thing that sneaks in on a Tuesday deploy and nobody notices for a month. If you already think in terms of regression testing, treat this as one more gate rather than a quarterly audit ritual.
In DevTools, Chrome 150 or newer, open the Lighthouse panel, tick Agentic Browsing, and run it against your local dev server. Handy for staging environments Google can't reach.
Two more free tools worth pairing with it: the Elements → Accessibility panel in DevTools to inspect the tree directly, and `https://r.jina.ai/<your-url>` to see roughly what a text-only agent extracts from your page. The second one is uncomfortable reading the first time.
What the score is actually worth
Three checks, one of them optional, on a category Google itself labels unbenchmarked. That's the honest summary. If you're hoping for a number that predicts AI referral traffic, this isn't it, and anyone selling it that way is guessing.
What it is: the first time Google has shipped a machine-readable opinion on what makes a page usable by an agent. And every single thing it checks is something you should have fixed anyway. Google closes its own agent-friendliness guide with exactly that point — everything suggested to make a site agent-ready also makes it better for humans. Named buttons and stable layouts were never an agent feature.
The score is a smoke test. Passing it means you cleared the floor, not that you built anything. If you want the wider picture of what to measure once you're past it, start with AI visibility.
And if you'd rather someone else read your axe violations line by line, we run a free agent-readiness audit. It goes past the three Lighthouse checks into the parts a CDN shim can't fix: form semantics, and whether an agent can actually finish a job on your site.
