How to Pass the PageSpeed Agentic Browsing Audit

It is live. The Agentic Browsing audit, the new Lighthouse category that scores whether an AI agent can read and act on your site, has landed in Google PageSpeed Insights, the public web tool. No Chrome Canary, no Beta channel, no experimental flags. You paste a URL, click Analyze, and there it is in the score row next to Performance, Accessibility, Best Practices, and SEO.

When I first wrote this, the only way to see the category was a pre-stable Chrome build with DevTools. That whole process is gone now. I ran this site through PageSpeed Insights and it scored 3/3 on Agentic Browsing alongside its other categories:

This is the first time Google has folded "is my site ready for AI agents" into the same panel teams already open for performance and SEO, and now it sits in the tool everyone already uses. Here is what the category checks, how to run it, and the exact rule behind each pass or fail, the detail the headline write-ups skip.

Run it in PageSpeed Insights (about 30 seconds)

This is the whole process now:

1. Go to pagespeed.web.dev.
2. Paste your URL and click Analyze.
3. When the report loads, look at the score row. Agentic Browsing sits at the end with a fraction like 3/3. Click it to jump to the breakdown.

That is it. PageSpeed Insights runs Lighthouse on Google's servers and returns every category, including this one, for any public URL. No install, nothing to configure.

The breakdown lists each audit with a green dot for a pass, and groups the inactive ones under Not Applicable:

If you want to run it locally instead (offline, on a staging URL behind auth, or scripted in CI), the same category is in Chrome DevTools' Lighthouse panel on a recent build and in the Lighthouse CLI:

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

But for a quick check of a live page, PageSpeed Insights is now the fastest route, and the one you can hand to anyone.

What the Agentic Browsing audit checks

The category is often described 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 in PageSpeed Insights because Google's servers do not run with WebMCP enabled. So in PSI the score comes down to three things: the accessibility tree, CLS, and llms.txt. That 3/3 is what a clean site shows (a site with no llms.txt file lands on 2/2 instead, since a missing file is Not Applicable rather than a fail).

The checks, with the rule behind each one

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

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.

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.

WebMCP: why it shows Not Applicable in PageSpeed Insights

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. But in PageSpeed Insights all three stay Not Applicable, because the browser only reports WebMCP support when the feature is switched on, and Google's PSI servers do not run with it enabled. The only way to exercise the WebMCP audits today is locally, in Chrome DevTools or the CLI, with the chrome://flags/#enable-webmcp-testing flag turned on (or, for a production site, the WebMCP origin trial). For everyone scoring through PageSpeed Insights, WebMCP is greyed out and 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. PageSpeed Insights labels the category 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 now drops it into the panel you already open to check your site.

A short history: from DevTools experiment to PageSpeed Insights

The category moved quickly from a hidden experiment to a tool anyone can run. The timeline:

• May 5, 2026 — Agentic Browsing debuts as a new Lighthouse category in the Chrome 148 DevTools release.
• May 7, 2026 — it lands in Lighthouse's default configuration in version 13.3.0, so a recent Lighthouse surfaces it without any extra setup.
• June 2, 2026 — Chrome 150 reaches the Beta channel. Until this point, actually running the category required a pre-stable Chrome build (Beta or Canary). That hoop, install Canary, open DevTools, flip the WebMCP flag, is the one this article originally walked through.
• June 2026 — Google exposes the category in public PageSpeed Insights (running Lighthouse 13.4.0), so anyone can score a live URL with no special browser. That is where we are now.

The direction of travel is clear: a check that began as a developer-only experiment is being normalized into the same tool every team already opens for performance and SEO. The category still flags that it is "under development and subject to change," so expect the audits and the scoring to keep shifting, WebMCP especially, as the agentic-web specs mature. I will keep this page current as they do.