Lighthouse's New Agentic Browsing Score: What It Measures and Whether You Should Care

If you ran PageSpeed Insights on any site after roughly May 21, 2026, you will have seen a new category in the report titled Agentic Browsing. It sits alongside Performance, Accessibility, Best Practices, and SEO, and it looks different from the others in two ways. First, it is scored as a pass ratio (for example, 2 of 4), not the familiar 0 to 100 score. Second, it is labeled 'under development' in the report itself. The official scoring documentation explains why: Google is publicly building this category in the open, and the checks inside it can change from one Lighthouse release to the next.

If you are a site owner who has never heard of agentic browsing before opening PSI last month, this post is the plain-English version of what you are looking at.

The Agentic Browsing category has moved fast. Lighthouse 13.2 shipped on April 30, 2026, with the category available behind an experimental flag. Lighthouse 13.3 shipped on May 7, 2026, and made the category on by default. PageSpeed Insights picked up the new Lighthouse version around May 21, which is when most site owners first saw the score appear in their reports without any action on their part.

If you use Lighthouse locally through Node or the Chrome DevTools panel, you have had access to this category since April 30. If you rely on PSI, you inherited it in late May.

Right now, the Agentic Browsing category runs four checks. Google has said more will be added, so treat this as a snapshot of mid-2026, not a fixed set.

Accessibility tree well-formedness. An AI agent that browses your site does not render pixels; it reads the accessibility tree that browsers expose. This check verifies that your headings, landmarks, buttons, links, and form controls are labeled and nested correctly, so an agent can build an accurate map of the page. Sites that already pass the Accessibility category usually pass this check for free.

WebMCP validation. WebMCP is the Web Model Context Protocol, an emerging standard for exposing site-native actions to AI agents (add to cart, subscribe, search). This check validates that any WebMCP manifest you publish is well-formed. If you do not publish a WebMCP manifest, the check is skipped, not failed. You are not penalized for opting out.

llms.txt presence and validity. llms.txt is a text file at your site root that describes your site to language models, in a format similar in spirit to robots.txt. See our llms.txt glossary entry for a deeper explanation. This check confirms that if you publish one, it parses. Again, missing the file is skipped, not failed.

Layout stability for agents (CLS). This is the check most closely tied to classic Core Web Vitals. Agents that read pages over time can be confused by layout shifts the same way users are. The check runs a CLS-like measurement scoped to agent-relevant interactions.

Two of the four checks are true opt-in features. Two overlap directly with work you should already be doing.

Three things happened at Google I/O 2026 that make this timing less surprising. Google announced its agentic web push, including deeper integration of Gemini agents with Chrome. WebMCP entered a Chrome origin trial in Chrome 149, which means production sites can now experiment with exposing native actions to agents. And the web.dev team published a set of agent-friendly UX guidelines that reads as the design partner to this Lighthouse category.

Put together, the Agentic Browsing category is Google seeding the tooling for the ecosystem it wants to enable. It is not a stealth ranking factor, and Google has not framed it as one.

The most important thing to know is what is not happening. Agentic Browsing is not a Search ranking signal in 2026. Google has not announced it as one, and independent analysis from DebugBear confirms there is no evidence of the score influencing rank position.

Skipping WebMCP and llms.txt does not hurt you. Two of the four checks pass by default if you have solid accessibility and low CLS, which any site that cares about Core Web Vitals already has. The score exists to help you plan for agent traffic, not to punish you for not being early.

That said, agent traffic is real and growing. ChatGPT, Perplexity, Claude, and Gemini all send agent-driven visits to public pages now, and the pattern of that traffic is different from human search traffic: shorter sessions, deeper content extraction, and less tolerance for UI that only makes sense to human eyes. Building for that traffic is a hedge on the next two years, not an emergency for this quarter.

The most useful takeaway is that the layout stability check in this category is the same CLS work your performance team is already doing. If your CLS is below 0.1 at the 75th percentile in CrUX, this check passes without any extra investment. If your CLS is above 0.1, fixing it earns you Core Web Vitals credit and agent-readiness credit at the same time. Our core web vitals optimization service handles the classic CLS work, and the agent-readiness score improves as a side effect.

Accessibility is the other overlap. A well-formed accessibility tree helps screen reader users and helps agents. The two audiences are aligned. If you have been treating accessibility as a compliance line item, this is one more reason to treat it as an investment.

We now include the Agentic Browsing checks in every audit as an information-only line, alongside the traditional Performance and Core Web Vitals sections. If your accessibility tree is broken or your CLS is bad, we call it out. If you want to publish a WebMCP manifest or an llms.txt file, we can help scope it, but we do not treat missing them as a defect. Come back in a year and we may. For now, get CLS below 0.1 and get the accessibility tree clean. That is the highest-value work regardless of what the AI ecosystem does next.