What Lighthouse's Agentic Browsing Audit Actually Checks

For its whole life, Lighthouse has graded your site for humans. Performance: how fast a person sees something. Accessibility: whether a person using a screen reader can get through it. SEO and Best Practices: whether the page is well-formed enough for a crawler and safe enough for a visitor. Four scores, each a number out of a hundred, each ultimately about a person on the other end.

In 13.3, Google quietly added a fifth thing to grade — and the thing on the other end isn't a person anymore. It's an agent: a model browsing your site to do something on a user's behalf. The new category is called Agentic Browsing, and the most interesting decision Google made about it is the one that's easy to miss: it refuses to give you a score out of a hundred.

Every other category is a weighted average from 0 to 100. This one isn't. It hands you a fraction — a pass-ratio, like 2/4 — plus a list of pass/warn/fail checks. The docs say why, more or less directly: the standards for the agentic web are still forming, so the goal right now is to surface signals rather than rank you. That's the part worth sitting with. Google is telling you this matters enough to measure but is still too early to score, and the rest of this post is about which of those applies to each check.

Why this exists now

The short version: agents have started browsing. The push at I/O 2026 was the "agentic web" — models that open your page, read it, and act on it instead of answering from training data alone. When a model fills out your contact form or pulls your pricing, it never sees your design; it reads a machine-readable version of your page. Agentic Browsing is Lighthouse's first attempt at asking whether that version is any good.

There are four checks. Two of them you've probably been doing for years under a different name. One is cheap and worth doing. One is a genuine bet.

1. llms.txt — cheap insurance

The first check looks for an llms.txt file at your domain root, and then checks that it isn't useless: it wants an H1, enough content to be worth reading, and actual links. A file that's present but empty fails the same as no file at all.

llms.txt is a proposed convention — a Markdown file that gives a model a curated map of your site, the same way robots.txt gives a crawler a set of rules. The idea is that instead of an agent guessing your site's structure from the nav, you hand it a clean index: here are my important pages, here's what each one is.

This site serves one. Mine is generated, not hand-maintained — an endpoint walks the journal collection and emits a fresh /llms.txt on every build, so it can't drift out of sync with what's actually published. That's the right way to do it: a stale map is worse than no map.

Here's the honest part, and Google says it out loud in the audit itself — llms.txt is not widely used by AI tools currently. You are writing a file for an audience that mostly isn't reading yet. So the verdict is: do it, because it's cheap and content-versioned and costs you nothing to keep current, but don't expect it to move anything today. It's insurance against a future that may or may not arrive, priced at about twenty minutes of work.

Verdict: Cheap insurance. Ship it, automate it, then forget it.

2. WebMCP — the genuine bet

This is the new one, and the only check here that asks you to build something you didn't already have.

WebMCP is an API that lets your page explicitly expose actions to an agent — not "here's some HTML, good luck," but "here is a function called add-to-cart, here's exactly what it expects, call it." It's the front-end cousin of the Model Context Protocol that powers tool use in assistants, except it runs in the visitor's own browser session, against your live page, with their auth.

There are two paths, and Lighthouse audits both.

The imperative path registers tools in JavaScript. The shape looks like this:

navigator.modelContext.registerTool({
  name: "add-to-cart",
  description: "Add a product to the shopping cart",
  inputSchema: {
    type: "object",
    properties: {
      productId: { type: "string", description: "Product identifier" },
      quantity:  { type: "number", description: "How many to add" },
    },
    required: ["productId"],
  },
  async execute({ productId, quantity = 1 }) {
    await cart.add(productId, quantity); // the same code your button calls
    return { content: [{ type: "text", text: `Added ${quantity}× ${productId}` }] };
  },
});

The agent reads the description and inputSchema, decides this is the tool it needs, and calls execute. The key discipline: execute should route through the same logic your UI already uses. A tool that re-implements your cart will drift out of sync with it. Expose the function you've already got rather than maintaining a second copy.

The declarative path annotates your existing <form>s so an agent can discover and submit them without you writing any JavaScript at all. Lighthouse has a specific audit for this — Forms missing declarative WebMCP — and another, WebMCP schema validity, that checks your annotations actually parse. The appeal is obvious: most of what an agent wants to do on a site is "fill this form and submit it," and if your form is already marked up, you get agent-readiness for nearly free.

So why call it a bet and not a recommendation? Because it's a spec in motion. The API surface, the attribute names, the exact schema — all of it is young enough that what you ship today may need rewriting next quarter, and the audience that can use it is still small. If you run a transactional site where an agent completing a purchase or a booking is real near-term money, WebMCP is worth prototyping now. If you run a portfolio or a blog, it's worth understanding and worth watching — but building it today is paying for a road before the cars arrive. Read the current docs before you write a line; anything I pin down here has a shelf life.

Verdict: Real, and the most interesting thing in the category — but a moving spec. Prototype it if agent actions are near-term revenue; otherwise watch it.

3. Agent-centric accessibility — you should be doing this anyway

Here's where the category stops being about agents and starts being about something you already owe your users.

When an agent reads your page, it doesn't parse your raw HTML and it usually doesn't look at a screenshot — both are expensive and noisy. It reads the accessibility tree: the same stripped-down, semantic representation of your page that a screen reader uses. Names, roles, states, the parent-child structure of what's interactive. It's a far cheaper signal than pixels, and it's already there in every browser. The agent is just reading the API your markup has been exposing all along.

So the checks here are the accessibility checks you already know, pointed at a new beneficiary. Are interactive elements named and labelled? Are roles valid and the tree well-formed? Google's own framing is blunt: a missing label blocks both a user with a visual disability and an agent from finishing the task.

This is the part of the category I'd act on first, and it has nothing to do with agents. Semantic HTML and real labels are the highest-leverage work you can do on a page, full stop — they help screen reader users, they help your regular accessibility score, and now they happen to help the machines too. There is no version of the future where this work is wasted.

Verdict: Do it regardless. The same change helps your human users, your accessibility score, and agents.

4. Layout stability — already on your radar

The fourth check reuses a metric you already track: Cumulative Layout Shift. The reasoning is small and sensible — an agent that does fall back to screenshots gets confused when your layout jumps around as ads load, images pop in without reserved dimensions, or content injects late. A stable page is easier for that screenshot to read, just as it's easier on human eyes.

You were already fighting CLS for Core Web Vitals, because layout shift is one of the things Google's ranking signals and your actual users both hate. Agentic Browsing just gives you one more reason to set width/height on your images and reserve space for anything that loads late.

Verdict: No new work — it's the Core Web Vitals optimization you're already doing.

Running it yourself

It's already in your toolchain. Open Chrome DevTools → Lighthouse, and the Agentic Browsing category sits alongside the familiar four. Or from the command line:

pnpm dlx lighthouse --view https://your-site.com

One thing to expect: the results jitter more than the other categories. Tools registered late by JavaScript, an accessibility tree that shifts as the DOM settles, CLS that varies with what loads when — all of it makes the pass-ratio less stable run-to-run than a Performance score. Treat it as a rough signal — which is how Google is treating it too.

What's real and what's premature

Line the four up and the category sorts itself cleanly:

• Accessibility and CLS are timeless. They predate agents, they outlive whatever happens to WebMCP, and you should do them for reasons that have nothing to do with this audit. The fact that agents benefit is a bonus on work that was always worth it.
• llms.txt is cheap enough that the expected-value math works even against a small chance it matters. Automate it and move on.
• WebMCP is the only real bet — high ceiling, young spec, small current audience. The audit's value here isn't the pass/fail; it's that it puts the idea on your radar before you need it.

And the tell that ties it together is the missing 0–100 score. Google measures plenty of things it's confident about with a hard number, and it declined to here. The honest reading: worth watching, too early to grade.

What you end up with

Most of "making your site agent-ready" turns out to be making your site good, by standards that already existed. Three of the four checks are work you should do — or were already doing — for human beings: label your controls, keep your layout still, and hand visitors (now including the machine kind) a clean map of your content. Only WebMCP asks something genuinely new, and it asks it of the sites where it actually pays.

That's the quietly reassuring thing about the agentic web, at least so far. The accessibility tree was always an API, and semantic markup was always a contract. Agents didn't change the work; they just became a new reader of it.