Lighthouse's New Agentic Browsing Score

I ran Lighthouse on one of my projects the other day and noticed a category I had not seen before, sitting next to the usual Performance, Accessibility, Best Practices, and SEO circles: Agentic Browsing.

Instead of a 0–100 score, it shows a fraction — mine reads 2/2 — and a short description:

These checks ensure high-quality, browsable websites for AI agents and validate the correctness of WebMCP integrations. This category is still under development and subject to change.

That last sentence is important, so I will repeat it up front: this is experimental. But it is a clear signal of where browser tooling is heading, so it is worth understanding what it measures.

What “Agentic Browsing” is trying to measure

The traditional Lighthouse categories ask whether a page is good for a human: is it fast, is it accessible, is it discoverable by search engines.

Agentic Browsing asks a different question:

How well is this site constructed for a machine to navigate and operate?

The “machine” here is an AI agent — something driving a browser on a user’s behalf, reading the page, filling forms, clicking through flows. The category evaluates that with a set of deterministic audits, the same way the other categories do.

How it is scored

This is where it differs from the categories you know.

The familiar categories give you a weighted 0–100 number. Agentic Browsing does not. Instead you get:

• a fraction in the header (2/2, 3/5, and so on) counting how many applicable readiness checks passed
• pass/fail status on individual audits, which emit an error or a warning when a requirement is not met
• audits that can come back as not applicable when they simply do not apply to your site yet

Google is explicit that the current goal is to gather data and give you actionable signals, not to hand out a definitive ranking. So do not treat the fraction like a Performance score to grind toward 100. Treat it as a checklist of readiness signals.

That also explains my tidy-looking 2/2. It does not mean my site is fully “agent-ready.” It means two audits applied and both passed. The other four did not apply.

The audits

The category splits into two groups: checks that make a normal site legible to an agent, and checks tied to WebMCP, a newer opt-in API.

Group 1: is the page legible to a machine?

These apply to any site, no special integration needed.

• Accessibility tree is well-formed. The same tree screen readers rely on is what an agent reads to understand the page. Elements need programmatic names, the tree needs to be intact, and things need to actually be visible. Good accessibility work pays off twice here.
• Cumulative Layout Shift. Yes, CLS again — but for a different reason. If the layout jumps around while an agent is working, the element it was about to click can move out from under it. Stability is not just a human comfort thing anymore; it is correctness for automation. Mine reports a CLS of 0.

These two are the ones that passed for me, and they are the ones every site can influence today without adopting anything new.

Group 2: WebMCP

The other four audits check for WebMCP — Web Model Context Protocol.

WebMCP is a proposed API that lets a site explicitly expose its logic and forms to AI agents, instead of making the agent guess by scraping the DOM. You can declare it in HTML or wire it up in JavaScript. The audits are:

• WebMCP tools registered — are agent-callable tools declared on the page?
• WebMCP form coverage — do your forms expose a declarative WebMCP integration?
• WebMCP schemas are valid — if you do declare tools, are their schemas correct?
• llms.txt follows recommendations — is there a machine-readable summary file at the domain root, in the expected shape?

On my site all four show up under Not applicable, because I have not adopted WebMCP and the audits have nothing to evaluate. “Not applicable” is not a failure — it is the audit telling you it did not run because the precondition was not met.

Why “not applicable” is the honest answer for most sites right now

WebMCP is early. It relies on proposed standards, needs a recent Chrome, and expects sites to opt in through an origin trial. Almost no production site has it today, so almost everyone will see those four audits as not applicable — which is exactly why the score is a fraction of applicable checks rather than a flat percentage. It does not punish you for skipping a standard that barely exists yet.

That framing tells you what to actually do with this category today.

What I would act on, and what I would just watch

The split is convenient, because one group is real work you should already be doing and the other is a bet on where things are going.

Act on now:

• A clean, well-formed accessibility tree. This has been worth doing for a decade for human users; agents just add another reason.
• Low CLS. Same fixes as always — set image and media dimensions, reserve space for anything injected late.

Watch for now:

• WebMCP. Interesting, plausibly important, but experimental and origin-trial-gated. I would not rebuild forms around it yet. I would keep an eye on it, because “let agents call your site’s real actions instead of scraping” is a genuinely better model than the screen-scraping most agents do today.

The caveat, restated

The results can even fluctuate between runs — tool registration timing, how the accessibility tree gets built, and layout shift from late-loading content can all move the numbers. Google labels the whole thing experimental and subject to change, and that is fair.

But I like that it exists. For years the question was “is my page good for people and good for search crawlers.” A third audience is now showing up in the tooling: agents acting for people. Right now the best preparation is boring and familiar — a solid accessibility tree and a stable layout. The rest is a standard still being written, and this score is Lighthouse starting to keep track of it.