Lighthouse's new Agentic Browsing category, explained

In May 2026 Google’s Lighthouse, the audit engine behind PageSpeed Insights and the Chrome DevTools Lighthouse panel, grew a fifth category. Next to Performance, Accessibility, Best Practices and SEO sits Agentic Browsing, and it scores something none of the others do: how well an AI agent, not a human and not a search crawler, can read your page and act on it. This is the reference version of what it contains: every audit by name, what each one checks, why it reports a pass ratio instead of a score, and the Chrome-version caveats that trip people up.

01 · OriginWhere it came from

The category shipped in Lighthouse 13.3 and was promoted into the default configuration in early May 2026. It exists because AI agents now browse through Chrome, so Google is positioned to measure whether a site is built for them, and it is labelled experimental and “under development” on purpose. The web standards it leans on are young, and Google has been clear about what this is not: it is not a Search ranking signal. A perfect ratio will not move you up a results page, and a poor one will not push you down.

What it does give you is an honest, deterministic read on agent-readiness, expressed as a small set of pass/fail checks. That framing, deterministic checks rather than a fuzzy grade, is the key to reading it correctly.

02 · ScoringWhy it is a pass ratio, not a score

Every other Lighthouse category rolls dozens of weighted audits into a single number from 0 to 100. Agentic Browsing does not.

The reason is candour. A weighted score implies Google knows the relative importance of each signal, and for an emerging area like the agentic web it does not yet. So instead of pretending, the category reports the raw tally and lets you see exactly which checks passed. One practical consequence: the denominator changes with your environment. Run it in PageSpeed Insights and you see three checks; run it in Chrome 150 with the WebMCP origin trial enabled and a fourth appears. The ratio is only meaningful once you know how many audits actually ran.

03 · What it checksThe four audits

Here is the whole set, by their Lighthouse titles, and what each one is really testing.

Accessibility tree. This reuses Lighthouse’s existing accessibility machinery (names and labels, tree integrity, visibility) but reframes it for machines. Agents rely on the accessibility tree as their primary model of the page, so an unlabelled <div>-as-button that a sighted human can still guess at is, to an agent, invisible. If you have done real accessibility work, you mostly pass this for free.

Layout shift. The same Cumulative Layout Shift metric from the Performance category, judged by a different standard. A human tolerates a button that jumps once the ad loads; an agent that already computed where to click does not. Reserve space for images, embeds and late content so nothing reflows after load.

llms.txt. The audit checks that a file exists at your root and meets three quality rules: it has an H1, it contains at least one Markdown-formatted link ([label](https://…), not a bare URL), and it runs longer than 50 characters. Miss any one and it fails. The deeper honest guide to whether llms.txt is worth shipping at all lives here; for this audit, the bar is simply “present and well-formed.”

WebMCP validation. The newest and most speculative. It looks for WebMCP tools you have declared, whether through annotated HTML forms or navigator.modelContext.registerTool, and validates them against the expected schema. This is the one audit you cannot pass without opting into an origin trial.

04 · The caveatsWhat you need to run the full set

This is where the confusion clusters, so be precise about it.

• The full category needs Chrome 150 or later. Older Chrome (and the Lighthouse baked into your current DevTools) may not show the category at all, or shows a partial version.
• WebMCP validation needs the origin trial. Even on Chrome 150+, that audit stays dark until you register for the WebMCP origin trial and serve the trial token. Without it you top out at three of four.
• PageSpeed Insights runs the three defaults. PSI cannot opt your site into an origin trial, so it reports the accessibility tree, layout shift and llms.txt checks. That is the version most people will see first, covered in its own guide.

05 · Running itHow to run it

Three practical routes, fastest first:

npm install -g lighthouse@latest
lighthouse https://yoursite.com --view
# Opens the full report, Agentic Browsing category included.

• PageSpeed Insights (pagespeed.web.dev): zero install, shows the three default checks. Best for a quick read.
• Lighthouse CLI (above): always the latest category, and the only easy way to also test WebMCP if you have the origin trial running locally.
• DebugBear or similar: third-party runners tracked Lighthouse 13.3 early and expose the category in a friendlier UI.

Note that the Chrome DevTools Lighthouse panel uses whatever Lighthouse ships inside your installed Chrome, which often lags. If DevTools does not show the category, that is why; reach for the CLI or PSI instead.

06 · PrioritiesWhat to fix first

Fix in order of payoff, not audit order. The accessibility tree and layout-shift checks are the two that also help your human visitors, your search ranking, and your Performance and Accessibility scores, so they earn their keep even if the agent era arrives slowly. Do them first. llms.txt is a fifteen-minute win that also clears the check. WebMCP is genuinely optional: only chase it if agents are a real channel for your product, because it is early, needs an origin trial, and buys you nothing with human users.

Where Nilkick fits: it scores the discoverability and protocol half of agent-readiness (llms.txt, markdown negotiation, crawler rules, WebMCP tool registration), while Lighthouse’s category adds the on-page render half (accessibility tree, layout stability). They overlap by design and complement each other; neither is the whole picture.