Lighthouse Agentic Browsing: What It Actually Checks

Lighthouse is the auditing tool built into Chrome DevTools, the one that gives you the four colored rings for Performance, Accessibility, Best Practices and SEO. In 2026 it grew a fifth category called Agentic Browsing, which scores how ready your page is for AI agents.

The SEO coverage of it has been loud. Most of it says the same thing: implement WebMCP or watch your agentic score fall behind.

So I ran it. Four sites, real numbers, and the finding is not what the coverage says.

Every WebMCP audit in the category is weighted zero. Our own tools page scored a perfect 1.0 with no WebMCP anywhere on it.

What the category actually contains

The Agentic Browsing category ships six audits. Here is every one, with the weight Lighthouse assigns it, read straight out of the JSON report rather than the documentation.

Two of the three scored audits have been standard web hygiene for years. A well-formed accessibility tree is what screen readers have always needed. Cumulative Layout Shift has been a Core Web Vital since 2021. The genuinely new one is llms.txt, and as you will see below, it is the strangest of the three.

The scoring is not out of 100. Google’s own note is that “the standards for the agentic web are still emerging, the current focus is to gather data and provide actionable signals rather than a definitive ranking,” so what you get is a fraction of the applicable audits that passed.

The four sites I ran it on

All four run on Lighthouse 13.4.1, headless Chrome, default settings, on August 26, 2026. You can reproduce any of them in about ninety seconds.

Not one of those four pages has a single WebMCP tool on it. Two of them scored a perfect 1.0 anyway.

The arithmetic is easy to check. Our homepage passed the tree and llms.txt, and scored 0.81 on layout shift. Add those, divide by three, and you get 0.9367, which Lighthouse rounds to 0.94. The WebMCP audits are not in the sum at all.

Ahrefs is the same sum with a different denominator. The tree failed, layout shift passed, and llms.txt was not applicable, so two audits counted and one of them passed. That is 0.5 exactly.

Run it yourself

npx lighthouse@13 https://example.com \
  --only-categories=agentic-browsing \
  --chrome-flags="--headless"

One trap worth knowing. Lighthouse 12 does not have this category, and if you pass it that flag you get the four original categories with no warning that the one you asked for does not exist. Check with npx lighthouse@13 --help and look for agentic-browsing in the list of available categories.

Why layout shift is in an agent audit

Cumulative Layout Shift looks like the odd one out here. It is a Core Web Vital, it has been measured since 2021, and it is usually framed as a human annoyance. You go to tap a link, an ad loads above it, and you tap the wrong thing.

Put an agent in that sentence and it gets worse, not better.

A human notices the page moved. The button jumped, they reorient, they find it again and click the right one. It is irritating and it takes half a second. An agent that has located a target, decided to click it, and then acts on coordinates that are no longer valid does not notice anything. It clicks whatever is now in that spot and reports success.

That is the difference between a bad experience and a wrong action. On a checkout or a settings page, the wrong action is expensive, and nothing in the response tells anyone it happened.

Our homepage sits at CLS 0.13, which scores 0.81 and is the only reason we are not on a perfect score. That number was already worth fixing for ordinary reasons. The agent case just moves it up the list, because the failure mode changes from “user is annoyed” to “wrong button, silently.”

The llms.txt rule is backwards from what you would expect

This is the finding I did not see coming, and it changes the advice.

BBC News has no llms.txt file. It scored 1.0. The audit came back as “not applicable” and dropped out of the calculation entirely, so the page was scored on two audits instead of three.

Our site does have one, so the audit ran, passed, and counted. Same result, different denominator.

Read that the other way round and it is a genuinely odd incentive. Not having an llms.txt costs you nothing. Having a broken one costs you a third of your score. The audit checks that the file contains at least one H1 heading, is not too short, and contains links, which are the minimum requirements in the original llms.txt proposal. Fail any of those and you have actively made your score worse than if you had never published the file.

That does not mean skip it. It means if you publish one, publish a correct one. We wrote up what goes in an llms.txt and who actually reads it, and the honest summary there still holds: coding agents fetch these files daily, and Google’s own AI documentation says you do not need one to appear in AI Overviews. Lighthouse checking your file does not change either fact.

If you are deciding whether the file is worth it at all, llms.txt versus robots.txt covers which one actually controls anything.

Why Ahrefs scores 0.5

I ran this one twice because publishing a number about a named company on a single measurement is not good enough. It returned 0.5 both times.

The cause is not exotic. The accessibility tree audit fails on “Buttons must have discernible text,” and the failing element is a button in the footer. Layout shift was a clean 0. There is no llms.txt, which as we just established costs nothing.

So an SEO company’s blog scores half marks on Google’s agentic readiness audit because of one unlabeled footer button. That is not a criticism of their SEO, which is excellent. It is the clearest possible demonstration of what this category is really measuring.

It is an accessibility audit wearing a new name. An agent parsing your page hits exactly the same wall a screen reader hits. A button with no accessible name is unusable to both, for the same reason, and it has been a WCAG failure for twenty years.

What the tree audit is really testing

agent-accessibility-tree is not one check. It is a bundle, and Chrome groups the pieces into three ideas.

Names and labels. Every interactive element needs an accessible name. A button whose only content is an SVG icon has none unless you give it one. This is the single most common failure, and it is what caught Ahrefs.

Tree integrity. ARIA roles have required parents and required children. A role="listitem" floating outside a list, or a role="tab" with no tablist above it, produces a tree that does not describe a coherent interface.

Visibility. Elements that are visually present but hidden from assistive technology, or the reverse. An agent reading the tree sees a different page from the one on screen, and acts on the wrong one.

The practical version is short. Run the ordinary Lighthouse accessibility category, fix what it reports, and this audit follows. There is no separate agent-specific work to do, which is either disappointing or excellent news depending on how much accessibility debt you are carrying.

What the WebMCP audits actually do

They are not useless. They are just not scored.

Run the audit in a default Chrome and all three come back “not applicable.” Run it with the WebMCP feature flag enabled and two of them switch to “informative” and report what they found. Neither state affects the number.

We tested that the direct way afterwards: we turned WebMCP on for this site and re-ran the audit. The score was 0.94 before and 0.94 after, and the three WebMCP audits were still “not applicable.” The weights do exactly what they say.

That is a reasonable design. WebMCP is an origin trial running from Chrome 149 to 156, which means it is off by default for most of your visitors. Scoring sites on an experimental API almost nobody can use yet would produce a league table of nothing.

The one genuinely forward-looking audit is webmcp-form-coverage, which lists forms on your page that could carry WebMCP annotations. Think of it as a to-do list Google is offering rather than a test you can fail. If and when the standard ships properly, that audit is sitting there ready to start counting.

The documentation for the registered tools audit confirms the intent in its own words: it is informational, and lists what it finds. The advice attached to it is about writing clear tool names and descriptions, not about passing anything.

So what should you actually do

In priority order, based on what the numbers above say rather than what the category is called.

Fix your accessibility tree first. It is a full third of the score, it is the audit that actually fails in the wild, and every fix helps real people using screen readers today. Run the standard Lighthouse accessibility category alongside this one. They overlap heavily.

Then look at layout shift. It is the other third, it is measured the same way as the Core Web Vital you already track, and for an agent the failure mode is a wrong click rather than a moment of irritation.

Publish an llms.txt only if you will maintain it. One H1, real links, not too short. A stale or malformed file is worse than no file under this audit, which is a genuinely new consideration.

Do not implement WebMCP for this score. It cannot move it. There may be good reasons to build WebMCP tools, and the declarative form attributes are cheap enough to be worth an experiment on a high-friction checkout. Lighthouse is not one of those reasons, and any post telling you otherwise has not read the report.

If you want the same three questions answered without installing anything, our free GEO audit checks the accessibility signals an agent relies on, your llms.txt, and your robots.txt rules per crawler, from a URL.

Worth repeating the boring part: none of this is a ranking factor. Lighthouse is a diagnostic tool and always has been. Google has not said Agentic Browsing feeds search, and the category’s own documentation frames it as data gathering. If you want the broader picture of what actually is changing, we covered how AI agents are changing SEO separately.

The bit that is genuinely new

Strip out the accessibility and the layout shift and one idea is left standing, and it is a good one.

Google has started measuring websites on how machine-legible they are, and shipped it inside the tool every developer already runs. That is a signal about direction, whatever the current audits weigh. The category documentation is explicit that it is gathering data first.

The reasonable read is that the weights will move. When WebMCP leaves origin trial and a real browser agent ships to a real user base, three audits sitting at zero become three audits that count. Nothing about the category needs to change for that to happen, which is presumably the point of building it now.

Until then, the honest advice is dull and cheap. Label your buttons. Stop your layout jumping. If you publish an llms.txt, keep it correct. That is the whole test today, and it will still be worth having done when the test gets harder.