Agentic Browsing in PageSpeed Insights: What It Is and Why It Matters

I recently ran my blog through PageSpeed Insights. Performance, accessibility, best practices and SEO all came back at 100, which is nice. But next to those four familiar categories there was a fifth one: Agentic Browsing. I decided to figure out what it is, because it looks like the web has quietly gained a new kind of visitor.

What AI agents are and why the browser matters

Not long ago, language models mostly generated text. Now they increasingly open websites and complete tasks themselves: find a product and compare prices, book a doctor's appointment, fill in a form, place an order. An agent like that doesn't "see" a page the way a person does. It needs to understand what is on the page, what can be done with it, and how not to make a mistake.

Google describes this as a move towards "agent-ready" websites: sites that give agents predictable, machine-readable signals so they can reliably finish a task. The new Lighthouse category checks exactly how ready a site is for that.

Where the category comes from

The category lives in Lighthouse, so it shows up both in PageSpeed Insights and in the Lighthouse panel in Chrome DevTools. Full testing requires Chrome 150 or later. Chrome explicitly calls the category experimental: it is based on proposed standards and may change.

What it actually checks

The checks fall into a few groups.

1. Agent-focused accessibility

This is a subset of the regular accessibility audits. The point is that an agent's main model of a page is the accessibility tree, not the picture on the screen. So it checks:

• names and labels: every interactive element has a programmatic name (button text, aria-label, a field label);
• tree integrity: element roles and parent-child relationships are valid;
• visibility: interactive elements aren't hidden from the accessibility tree.

An icon button without a label is still understandable to a person from context, but to an agent it's just a "button" with no meaning.

2. Layout stability (CLS)

Cumulative Layout Shift measures how much elements jump around while the page loads. For a person it's just annoying, but for an agent it can mean a misclick: it decided to press a button, and while it was clicking, something else moved into that spot.

3. Discoverability: llms.txt

Lighthouse checks whether the site has an /llms.txt file. It's a short Markdown summary of the site written specifically for language models: what the site is and where its key pages are. The format was proposed by Jeremy Howard in September 2024, and the spec lives at llmstxt.org.

One important detail: if the file is missing (404), the audit is marked Not applicable rather than failed, because it's optional for now. A failure is when the server responds with an error.

A minimal example for a blog could look like this:

# Zhurbiy Tech

> A personal blog about frontend, building products and everything I learn along the way.

## Articles

- [How I Moved My Blog to Railway](https://zhurbiy.com/en/articles/moving-to-railway): deploying Nuxt, Postgres and Cloudflare
- [Understanding Who the Product Is Really For](https://zhurbiy.com/en/articles/who-is-this-product-for): about target audiences

## Optional

- [About the author](https://zhurbiy.com/en/about)

The only required part is the level-one heading. Then comes a blockquote with a short summary, followed by sections with lists of links. The "Optional" section holds secondary links that an agent can skip if it's short on context.

4. WebMCP

This is the most interesting and newest part. WebMCP is a proposed web standard that lets a site declare tools to an agent directly: "here is the booking form, here is search, here is the cart". Instead of clicking around the page and guessing, the agent calls a ready-made tool with a description and a parameter schema. According to Chrome, this noticeably improves task completion accuracy.

Here Lighthouse checks whether tools are registered on the page, whether there are forms without declarative WebMCP markup, and whether the parameter schemas are valid.

WebMCP has two APIs. The declarative one works through attributes on a regular HTML form:

<form toolname="createSupportRequest" tooldescription="Submits a request for customer support.">
  ...
</form>

The imperative one lets you register a tool from JavaScript. For example, blog search could look roughly like this:

await document.modelContext.registerTool({
  name: 'search_articles',
  description: 'Search blog articles by keyword',
  inputSchema: {
    type: 'object',
    properties: { query: { type: 'string', description: 'Search phrase' } },
    required: ['query']
  },
  execute: async ({ query }) => {
    const res = await fetch('/api/articles?q=' + encodeURIComponent(query))
    return JSON.stringify(await res.json())
  }
})

Right now WebMCP is available as an origin trial starting with Chrome 149, and for local experiments there's the chrome://flags/#enable-webmcp-testing flag. The API is still being discussed and changing: older examples use navigator.modelContext instead of document.modelContext. So check the current documentation before using it.

The docs also put a separate emphasis on security. Tool registration is gated by the tools permissions policy: by default it only works for your own origin, and a cross-origin iframe needs allow="tools". For sensitive actions like payments, they recommend asking the user to confirm. And keep in mind that browser extensions can also see and call these tools.

How it's scored

There's no familiar 0-100 here. The result is shown as a fraction of passed checks, for example 3 out of 3, and each check is either passed or failed. Checks marked Not applicable (for example, a missing llms.txt) don't count as failures. Chrome itself calls the score "informational and unbenchmarked": these are signals for developers, not a ranking.

As far as I can tell, this category doesn't affect Google Search rankings right now. It's better seen as a hint about where the web is heading than as yet another metric to chase.

How to check your site

• PageSpeed Insights: the category appears next to the others.
• Chrome DevTools: the Lighthouse tab, Agentic Browsing category (requires Chrome 150+).
• Lighthouse CLI: lighthouse https://example.com --only-categories=agentic-browsing.
• Chrome DevTools for agents: if you work with an AI coding agent, it can run a Lighthouse audit on the open tab by itself.

What I've done and what I plan on my blog

Funnily enough, part of this category overlapped with what I'd been doing right before. I had just fixed CLS on the home page: because of two different versions of the same library, server data wasn't being reused and whole sections disappeared for a moment. Now CLS is zero on every page. Icon buttons on the site have labels for screen readers, so the accessibility tree is fine too.

I added llms.txt while writing this article. It is generated automatically from the list of published posts, so it is always up to date: zhurbiy.com/llms.txt. I'll hold off on WebMCP for now. A blog doesn't have many scenarios for it, maybe article search, and the standard itself is still experimental.

Wrapping up

Agentic Browsing isn't another score for the sake of a score. It's a signal that websites now have a new kind of visitor. The nice part is that most of the requirements overlap with ordinary quality work: semantic markup, decent accessibility and a stable layout matter to people and agents alike. llms.txt and WebMCP are the next step, worth keeping an eye on while the standards mature.

Useful links: how the category is scored, the llms.txt audit, the toolkit for agent-ready websites, WebMCP documentation.