---
title: "Agentic Browsing Score in Lighthouse: What the Fraction Tells You"
description: "Chrome added an agent readiness category to Lighthouse, and it reports a fraction rather than a grade. Here is every audit behind it, and the claim it cannot support."
author: "Team"
category: "Search & AI Visibility"
date: 2026-10-12T09:25:50.329Z
canonical: "https://contentagents.dev/blog/agentic-browsing-score-lighthouse-what-it-measures"
---

# Agentic Browsing Score in Lighthouse: What the Fraction Tells You

![lighthouse, ebb, beach](https://cdn.pixabay.com/photo/2022/01/04/16/01/lighthouse-6915406_1280.jpg?w=1200&q=75)

> Chrome added an agent readiness category to Lighthouse, and it reports a fraction rather than a grade. Here is every audit behind it, and the claim it cannot support.

Run Lighthouse in a recent Chrome build and a category appears that prints a fraction where every other category prints a number. That fraction is the Agentic Browsing Score. Chrome's own reference calls the category informational and unbenchmarked, which makes it a repair list rather than a result.

This explainer is for site owners and marketers who saw the fraction in a report and wanted to know whether it earns a row in a monthly dashboard. Lighthouse is the auditing panel that ships inside Chrome DevTools. Nothing below requires code.

## Agentic Browsing Score, defined

Put simply: the category counts how many agent readiness audits a URL passed and divides that by how many ran. It became available with Chrome 150. The question underneath is narrow and concrete. If software arrived on a reader's behalf, could it locate the content and operate the controls? A report that prints "3/3" is telling you three audits applied and none failed.

Chrome for Developers introduced the surrounding tooling in an [announcement by Kasper Kulikowski and Michael Hablich](https://developer.chrome.com/blog/agent-ready-toolkit), who describe it as a set of "deterministic audits" plus a framework for testing. Both halves of that phrase matter. Deterministic means the audits inspect facts about the markup. A testing framework is something a developer runs during a build, which is a different object entirely from a public benchmark that sites compete on.

## Why a browser vendor started grading this at all

People now delegate small errands to software: compare two prices, submit a form, hold a seat, lift a figure out of a table. Software working through an errand never sees the visual design at all. It works from the accessibility tree, the structured inventory of labels and controls that screen readers have relied on for decades.

Which means a button built as a styled div, carrying an icon and no label, does not exist in that inventory. It is not a styling problem or a nice-to-have. The control is absent. Chrome shipped the category so a team can catch that during development rather than in a support ticket.

Honestly, the fraction is the least interesting part. The signal worth reading is that the company shipping the browser now treats a visit by software as ordinary traffic, and has started publishing audits for it.

That framing changes who the work belongs to. An accessibility backlog has historically been argued on compliance grounds, which means it competes with the roadmap and usually loses. The same backlog argued as agent readiness competes with nothing, because no engineering lead wants to explain why the pricing page refuses to answer a question. The repairs are identical either way.

## The four things the audits look at

The [documentation for the category](https://developer.chrome.com/docs/lighthouse/agentic-browsing) sorts its audits into four groups. Not one of them is new advice. All four have a new audience.

### The accessibility tree, the only map software gets

Some of Lighthouse's accessibility checks reappear here, among them whether an interactive element carries a name that code can read. Anything absent from that tree is absent from the model software builds of the page. The longer argument runs in our piece on [what happens when software reads your site instead of a person](/accessibility-and-how-ai-agents-actually-read-your-site-8oqw).

### Layout that holds still

Cumulative Layout Shift, written CLS, records how far elements travel while a page settles. It belongs here for a mechanical reason. Software picks a target, then acts on it a fraction of a second later. A consent banner that drops in between those two instants converts a correct choice into a misfire.

### A file at the root that summarises the site

One audit looks for llms.txt, a plain-text description of the site, served from the domain root. The audit establishes that the file is reachable. It does not demonstrate, and cannot demonstrate, that any assistant fetched it or changed behaviour because of it. What goes in the file is covered in our [explainer on llms.txt](/llmstxt-what-it-is-whether-it-matters-and-how-to-generate-one-3d29).

### Registered tools, which hardly any site has

Under the WebMCP proposal, a page can publish named actions for software to call instead of leaving it to infer the interface from the markup. Lighthouse reads those registrations through the Chrome DevTools Protocol, covering both the declarative form written into HTML and the imperative form registered from script. For the overwhelming majority of sites today, the honest count is none.

### Worked through on a contact page

Take an unremarkable B2B contact page. A visitor sees three labelled boxes and a button that says Send. Software sees only what the accessibility tree reports. Where the boxes are divs wearing CSS, the tree may report no form fields whatsoever. Where Send is a bare icon with nothing naming it, the tree reports an unnamed control sitting next to nothing.

Those two cases are precisely what the audits surface, and the remedy is dull. Use the elements the platform already provides for inputs, labels and buttons, and give every control a name. Accessibility specialists have asked for exactly this for twenty years. The change is that a second class of visitor now fails without it.

## How the fraction compares with the Performance number

PerformanceAgentic Browsing

OutputOne weighted number, 0 to 100Audits passed over audits run
Comparable between sitesYes, and compared constantlyNo, published as unbenchmarked
Underlying questionDoes this feel fast to a person?Can software drive this page?
Documented ranking effectPage experience signals are publishedNothing published

Chrome's [page on how the category is scored](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring) says the difference without hedging: this category, alone among Lighthouse categories, produces no weighted average between zero and a hundred. So a flawless fraction on a thin page may only be telling you that very little applied.

A separate [analysis published by blogseo](https://www.blogseo.io/blog/agentic-browsing-score-lighthouse-reports) marks the ceiling. Because the audits run against a single URL, a pass cannot establish anything about "every workflow across your site". That write-up also finds no demonstrated effect on Google rankings, on citations inside AI answers, or on what assistants recommend to a buyer.

## Turning a fraction into a repair list

Work the failures. Discard the ratio.

- **Audit three templates rather than the home page alone.** Take the home page, one content or product page, and the form where contact details change hands. Write down each failing audit by name.

- **Begin with controls that have no name.** A nameless control is invisible to a screen reader and to software at the same moment, so one repair serves two visitors.

- **Hold space for anything that loads late.** Consent prompts, support widgets and unsized images are the usual reason a layout moves under a cursor.

- **Leave the WebMCP work alone unless money changes hands on your site.** A booking or checkout flow is a reasonable pilot. A publisher can let the proposal mature.

- **Give software one genuine errand.** Ask it to fetch a price or complete the form, then watch exactly where it stops. A single refusal teaches more than any ratio, and the repairs belong in your [routine for revisiting published pages](/how-to-optimize-existing-content-for-ai-search-results-pr7q).

That last step is the one most teams skip, and it is the only one that produces evidence. A fraction describes the markup. An errand describes the experience. When software stalls halfway through a form, you learn which of your four failing audits actually mattered and which were noise on that template.

Two limits deserve stating plainly. The documentation does not set out how each audit is weighted inside the category, and third-party summaries do not agree on how many audits exist. Before anyone quotes a count in a meeting, open the official reference.

The second limit is scope. Audits inspect one URL at a time, so a site with twelve templates needs twelve runs before the result means anything at the site level. Pick the three templates that carry revenue and ignore the rest until those are clean.

## Read the two drafts the audits point at

Two of the four audit groups test for something defined outside Chrome, and both documents moved this year. Ten minutes with them is worth more than a second Lighthouse run.

The llms.txt proposal belongs to Jeremy Howard, and the [current write-up is version two](https://llmstxt.org/), first published in September 2024 and last changed in August 2026. It asks for a Markdown file rather than a bare list of addresses, and the mandatory part is tiny: an H1 carrying the site name. Everything after that is optional. A blockquote summary, a few lines of context, then H2 sections holding link lists written as a name and a URL with an optional note after a colon. One section may be titled Optional, and an agent short of room is told it may skip that section entirely.

Two details in that document are missing from most summaries of it. The file need not sit at the root: a copy under a documentation path covers the addresses beneath that path, and an agent is told to prefer the most specific file it can find. And the proposal travels with a second convention, where a page offers a clean Markdown twin at its own address with .md appended, advertised through a rel="alternate" link. Lighthouse looks only for the root file, so a passing audit says nothing about whether the rest of the convention exists on your site.

WebMCP sits further from settled. The [draft is a Community Group Report dated 9 October 2026](https://webmachinelearning.github.io/webmcp/), edited by Brandon Walderman of Microsoft with Khushal Sagar and Dominic Farolino of Google, and it states on its own cover that it is neither a W3C Standard nor on the standards track. The mechanics are nonetheless specific. A page calls registerTool with a name, a description and an input schema. An agent calls getTools to see what is exposed to it and executeTool to run one. Access sits behind a policy-controlled feature named tools, whose default allowlist is the page's own origin. The project's [repository marks the work experimental](https://github.com/webmachinelearning/webmcp) and says the HTML form of registration is not part of the specification at this time.

## Finish three audits. Let the fourth one fail.

Here is the position. Treat the accessibility, layout and llms.txt audits as work to close this month. Treat the WebMCP audits as a line you are entitled to fail for the next year or longer. The reason sits in the paragraph above: Lighthouse checks for a declarative HTML form of tool registration that the WebMCP draft describes as future exploration and keeps outside the specification. A browser testing for something the draft has not adopted is not a standard anyone can build against. It is a vendor trying an idea in public, which is a fair thing for a vendor to do and a poor thing to spend a quarter of engineering time on.

The advice circulating now runs the other way: register tools early, arrive first, collect the agent traffic. That advice skips the bill. Registered tools are a second interface onto your product, with their own schemas, their own failure modes and their own security surface, and the draft carries a permissions policy precisely because exposing tools across origins is not obviously safe. Teams that ship a second interface before the first one is dependable tend to end up maintaining two unreliable things, and the one customers use is usually the one that gets starved.

Being late starts to cost something in two situations. If the declarative form lands in the specification proper and a second browser engine commits to shipping it, being late starts to carry a real cost. And if a reader can buy, book or cancel on your site without speaking to anyone, the sum is already different: that flow is exactly what an errand-running agent aims at, and a tool definition you wrote beats leaving software to guess its way through your checkout.

## Treat the badge as a prompt, not a result

Chrome calls the category informational, and nothing published connects it to rankings or to citations. That makes it a useful inventory of things to repair and a weak thing to report upward. Clear the failures, hand software one real errand, and the same work improves the page for people too.

## FAQ

### Does the Agentic Browsing Score affect Google rankings?

Nothing published supports that. Chrome labels the category informational, and the blogseo analysis of these reports finds no demonstrated effect on rankings, on AI citations or on assistant recommendations.

### Which Chrome version added the category?

Chrome's documentation and its agent-ready toolkit announcement both place it at Chrome 150 onward.

### What sits inside the category?

Per Chrome's documentation: part of the accessibility audit set, Cumulative Layout Shift, an llms.txt file at the domain root, and WebMCP tool registration.

### Can a page pass everything and still defeat software?

Yes. The audits run against one URL and report only on what applied there. Modal dialogs, validation messages and multi-step checkout can still fail.


---
Source: https://contentagents.dev/blog/agentic-browsing-score-lighthouse-what-it-measures