How to Pass the PageSpeed Lighthouse Agentic Browsing Audit

Chrome introduced a new Lighthouse category called Agentic Browsing in the Chrome 148 DevTools release (May 5, 2026), and it now ships in Lighthouse's default config. It is the same Lighthouse that powers Google PageSpeed Insights and the performance and SEO reports you already run, pointed at a different question: can an AI agent read your page, find the interactive parts, and act on them without guessing? Instead of a 0 to 100 score it gives you a small fraction, like 3/3, of the checks your page passes. It is the first time Google has folded "is my site ready for AI agents" into Lighthouse itself, the same panel teams already open for performance and SEO.

I have followed this since the Chrome 148 announcement, and once a Chrome 150+ build was available I ran it against this site (on Canary 151) and scored 3/3. Here is what the category actually checks, how to run it today, and the exact rule behind each pass or fail, the detail the headline write-ups skip.

What the Agentic Browsing audit checks

The category is often described in passing as a handful of checks. It actually defines six audits, each weighted equally, grouped under two headings plus Core Web Vitals:

The score is a fraction, not a percentage. Lighthouse counts how many of the scorable, applicable audits pass and shows it as n/n. Two of the WebMCP audits are informative only (they list things, they never fail you), and all three sit out as Not Applicable until the browser reports WebMCP support. So on a normal site the score comes down to three things: the accessibility tree, CLS, and llms.txt. That 3/3 is what most published screenshots show (a site with no llms.txt file lands on 2/2 instead, since a missing file is Not Applicable rather than a fail).

You need Chrome 150+ (Beta or Canary, for now)

The category first showed up in the Chrome 148 DevTools notes on May 5, 2026, and landed in Lighthouse's default config with version 13.3.0 two days later, on May 7. But the official requirement to actually run it is blunt: "Testing this category requires Chrome 150 or later." As of mid-June 2026 that means the Beta or Canary channel: Chrome 150 reached Beta on June 2, 2026, and has not hit stable yet (I ran it on Canary 151 with Lighthouse 13.4.0, the current release). If the Agentic Browsing checkbox is not in your DevTools yet, your channel is simply too old.

• Get Chrome Canary or the Beta channel (Canary installs alongside your normal Chrome, does not replace it).
• The category ships in the default Lighthouse config from 13.3.0 on, so on a recent enough build it appears in the Lighthouse panel on its own.

And no, you will not find it in PageSpeed Insights yet. PageSpeed Insights runs Lighthouse on Google's servers, but Google does not run this experimental category there, so a PageSpeed Insights scan will not return an agentic browsing score today. If and when the category graduates from experimental, PageSpeed Insights is the obvious home for it, but Google has not announced a date. For now the agentic browsing checks live in Chrome 150+ DevTools and the Lighthouse CLI. So if you searched for a "PageSpeed agentic browsing" score, this is the audit you want. You just run it in Chrome, not the PageSpeed web tool, for now.

Turn on the experimental WebMCP flag

The category itself is on by default in Chrome 150+, but the WebMCP audits stay dark until the browser has WebMCP active. That is an experimental feature you flip in settings:

1. Open chrome://flags/#enable-webmcp-testing in Canary (paste it into the address bar).
2. Set WebMCP for testing to Enabled.
3. Click Relaunch. The flag does nothing until Chrome restarts.

On earlier builds, before the category landed in the default config, this flag was also what surfaced Agentic Browsing at all. On Chrome 150+ you only need it for the WebMCP audits. For a real production site rather than local testing, you activate WebMCP by registering for the WebMCP origin trial instead. Either way, leave WebMCP for later, see the WebMCP section below for why.

Run it in about a minute

In DevTools:

1. Open the page you want to test in Chrome Canary.
2. Open DevTools (Cmd+Option+I on macOS, F12 on Windows) and click the Lighthouse panel.
3. Tick Agentic Browsing in the categories list. Pick Mobile or Desktop.

4. Click Analyze page load.

I prefer the CLI because it is reproducible and scriptable. Point Lighthouse at the Canary binary and ask for the one category:

export CHROME_PATH="/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary"

npx lighthouse@latest https://your-site.com/ \
  --only-categories=agentic-browsing \
  --output=html --output-path=./agentic.html

Use lighthouse@latest (you need 13.3.0 or newer) and point CHROME_PATH at a Chrome 150+ binary. The CLI needs both: upgrading only the npm package while it drives an older Chrome will not surface the category. Add --preset=desktop for the desktop run. The HTML report uses the same Lighthouse rendering as the DevTools panel.

Here is what a passing run looks like. I ran this site on both the mobile and desktop presets, and the result was 3/3 either way:

The checks, with the rule behind each one

The interesting part is what actually makes each audit go green. Below I lay out the exact pass/fail condition you have to meet for each audit, the precise rule Lighthouse enforces, not a paraphrase of the docs.

llms.txt: it is parsed, not just pinged

The llms-txt audit fetches https://your-domain/llms.txt and grades the response:

• No response / the fetch fails → fail ("Fetch of llms.txt failed").
• HTTP 500 or higher → fail, with the status code shown.
• HTTP 400 to 499 (a 404, most commonly) → Not Applicable. The file is optional right now, so missing it does not hurt your score.
• HTTP 200 (or any status below 400 that returns a body) → Lighthouse reads the content. This is the part people miss: it is not enough for the file to exist. To earn "llms.txt follows recommendations" the body must contain an H1-style heading line (a line beginning with # ), at least one Markdown-style link, and be at least 50 characters long. Lighthouse checks these with simple regexes, it does not fully parse the Markdown. Fail any of the three and the audit flips to "does not follow recommendations."

So the minimum file that passes is genuinely small, but it must look like the llms.txt spec intends:

# Example Site

> One line on what this site is.

- [Getting started](https://example.com/start)
- [API reference](https://example.com/api)

There is a real point of confusion worth clearing up. Google Search says you do not need an llms.txt file ("You don't need to create new machine readable files... to appear in generative AI search"), yet Chrome's Lighthouse checks for one. Both are true. They are different teams shipping for different jobs: Google Search ranking does not consume llms.txt, while the Chrome team is scoring agent-readiness against an emerging community convention. Treat llms.txt as a free, low-effort signal for agents and crawlers that support it, not as a Google ranking factor. If you publish one, make it valid (H1 + links + substance), because a malformed file now fails an audit that a missing file would have skipped.

Accessibility tree: a focused subset, not the full a11y audit

Agents do not look at pixels. They read the accessibility tree, the browser's structured view of the DOM where each element carries a role, name, state, and value. If a button has no accessible name, a sighted human guesses from the icon; an agent (and a screen-reader user) is stuck.

The agent-accessibility-tree audit does not run the entire accessibility category. It runs a curated subset of 33 rules that specifically block an agent from identifying or operating a control, and passes only when none of them are violated. The ones that bite most often:

• button-name, input-button-name, link-name, select-name, label — every control needs an accessible name.
• image-alt style rules: input-image-alt, svg-img-alt.
• document-title — the page needs a real <title>.
• The aria-* family: aria-valid-attr, aria-allowed-role, aria-required-children, aria-required-parent, aria-command-name, and more.
• tabindex and autocomplete-valid.

If your page already passes a normal accessibility review, this one comes for free. If it does not, this audit is the most useful thing in the category, because the fix helps assistive-technology users and agents in the same stroke.

Layout stability (CLS): a moving target is a missed click

The category reuses the Cumulative Layout Shift metric from Core Web Vitals. The reasoning is mechanical: an agent locates an element, then clicks where it was. If a late-loading ad, image, or web font shoves the layout after the agent has decided, the click lands on the wrong thing. A low CLS is not just a human comfort metric here, it is the difference between an agent completing a task and fat-fingering it. This site scored a CLS of 0, which is the number to aim for.

WebMCP: why almost every site shows Not Applicable

WebMCP (the open spec lives at webmcp.dev) is the web counterpart to the Model Context Protocol: a way for a page to declare tools an agent can call (submit this form, run this search) instead of forcing the agent to reverse-engineer your UI. The three WebMCP audits check whether you register tools, whether your forms are annotated, and whether the tool schemas are valid.

Two of them (webmcp-registered-tools, webmcp-form-coverage) are informative: they list findings and never affect your score. Only webmcp-schema-validity actually scores (and it can return pass, a half-credit warning, fail, or Not Applicable). All three stay Not Applicable until the browser reports WebMCP support at all, which you turn on with the testing flag for local runs or the origin trial in production. That is why the WebMCP rows are greyed out in essentially every report screenshot so far, and why a low WebMCP result today says nothing about your site. The spec is still moving. Do not burn time chasing it before the accessibility tree and CLS are clean, those help agents that act on your site regardless of WebMCP.

What a passing score means (and what it doesn't)

A 3/3 means the three scorable, applicable checks passed: a well-formed accessibility tree, a stable layout, and a valid llms.txt. It does not mean an agent can transact on your site, and it does not measure whether the data the agent reads is trustworthy. The category description says so plainly: it is "still under development and subject to change." Read the fraction as "the readable surface is clean," not "agent-complete."

The encouraging part: the two checks you can act on today, the accessibility tree and CLS, are the same fundamentals that have always made a site better for humans. The agentic web did not invent new homework. It put a score on the homework you were already supposed to do, and dropped it into a panel you already open.