Agentic Browsing is a new Lighthouse category that measures how easily an AI agent can read and use your page. WebMCP is the part that lets you hand agents real actions, like Book a Table or Add to Cart. Here is what each audit checks and how to pass it.
Agentic Browsing is a Lighthouse category that measures how well your site is built for machine interaction, meaning how easily an AI agent can read, understand, and use your page. It groups several checks: WebMCP tools, an llms.txt file, agent-friendly accessibility, and a stable layout. WebMCP is the piece that lets you expose real actions on your site to agents, such as booking an appointment or adding an item to a cart. You can read the official rules in Chrome’s Agentic Browsing scoring guide.
What Is the Agentic Browsing Category in Lighthouse and PageSpeed Insights?
The Agentic Browsing category evaluates how well your site is constructed for machine interaction through a set of deterministic audits. A growing share of the traffic hitting websites comes from AI agents rather than humans, and most of those agents struggle on pages built only for human eyes. The category is experimental and based on proposed standards, so treat it as helpful site hygiene and a head start, not an emergency. Testing it fully requires Chrome 150 or later, and the WebMCP audits need you to register for the WebMCP origin trial.
How Is the Agentic Browsing Category Scored?
The Agentic Browsing category does not give a weighted 0 to 100 score like the other Lighthouse categories. Because the standards for the agentic web are still emerging, Google built it to gather data and hand you useful signals instead of one final grade. The report shows a fractional score, which is a ratio of how many readiness checks your site passes, plus a pass, fail, or warning on each individual audit, and an informational pass ratio in the header so you can track progress at a glance. The checks are deterministic, so they give the same result each time and are safe to add to a CI/CD pipeline.
The Agentic Browsing category and WebMCP support are experimental and based on proposed standards. You will not be penalized in search rankings just for missing the newer agent features, and a clean, accessible site already passes several checks. The goal right now is data and a head start, not a penalty to dodge.
What Is WebMCP and How Does It Expose Your Site to AI Agents?
WebMCP is a way to tell AI agents exactly what actions they can take on your page, instead of making them guess from the layout. Each action you expose is called a registered tool, for example “Book a Table” or “Add to Cart.” Lighthouse talks to Chrome to watch which tools your page registers and checks that they are set up correctly. Think of WebMCP as a clear menu of buttons an agent is allowed to press, written in a language the agent understands. You can learn the full API in the WebMCP documentation.
How Do You Register WebMCP Tools (Declarative vs Imperative)?
You register WebMCP tools in one of two ways: the Declarative API or the Imperative API. The Registered WebMCP tools audit simply lists every tool it finds, so it is informational. The Declarative API is the easy route: you add toolname and tooldescription attributes straight onto your <form> element. The Imperative API uses JavaScript and navigator.modelContext.registerTool for more dynamic cases. Use clear, action-style names and describe what the tool does and when an agent should use it.
<!-- Declarative API: add attributes to a form -->
<form toolname="book_appointment"
tooldescription="Books an appointment for a given date and time">
...
</form>
// Imperative API: register a tool with JavaScript
navigator.modelContext.registerTool({
name: "book_appointment",
description: "Books an appointment for a given date and time"
});What Does the “Forms Missing Declarative WebMCP” Audit Check?
The “Forms missing declarative WebMCP” audit flags forms on your page that have no WebMCP metadata attached. A plain form works fine for a human, but an agent cannot tell what the form does or what counts as a successful submission. You fix it by adding the toolname and tooldescription attributes to those forms, which turns each one into a tool the agent can call on purpose. The full audit and examples live in Chrome’s forms audit guide.
What Is the WebMCP Schema Validity Audit?
The WebMCP schema validity audit checks that your tool definitions are written correctly, and it can emit errors or warnings when they are not. A tool with a broken or incomplete definition is one an agent cannot trust, so this audit protects you from quietly shipping something that looks registered but does not actually work. Validate your tool definitions against the spec, fix any reported errors, and re-run the audit to confirm. See Chrome’s schema validity guide for the details.
What Does the llms.txt Discoverability Audit Check?
The llms.txt audit checks for a machine-readable summary file at the root of your domain. An llms.txt file is a simple text file that gives agents a short, structured map of your most important content and links, so they do not have to crawl your whole navigation and hope for the best. Adding one is quick and low-risk, and it helps agents find the right pages faster. You can read what Lighthouse looks for in Chrome’s llms.txt audit guide.
Why Does Agent-Centric Accessibility Matter for AI Agents?
AI agents rely on the accessibility tree as their main view of your page, so good accessibility is also good agent readiness. The accessibility tree is the structured version of your page that assistive technology and agents read instead of the pixels on screen. Lighthouse checks a focused subset of accessibility rules for agents: every interactive element needs a programmatic name, roles and parent-child relationships need to be valid, and interactive content must not be hidden from the tree. You earn this by using semantic HTML and proper ARIA labeling, which the W3C WAI-ARIA standard defines. Chrome’s accessibility for agents guide lists the exact checks.
Why Does Layout Stability (CLS) Matter Even More for Agents?
Layout stability matters even more for agents because an agent often picks an element, then clicks it a fraction of a second later. If your page shifts in that gap, the agent can miss the target or hit the wrong control. Agents also move faster than people, so shifts that happen while content is still loading are more likely to break them. This is why Cumulative Layout Shift (CLS) is part of the Agentic Browsing checks, as explained in Chrome’s layout stability guide. Fix it the same way you fix it for humans: reserve space for images and ad slots, and avoid injecting content above what is already on screen. For the full CLS playbook, see our guide on Core Web Vitals in plain English.
Why Do Agentic Browsing Results Fluctuate Between Runs?
Agentic Browsing results can change between runs even though the audits are deterministic, and there are three common reasons. First, dynamic tool registration: if you register WebMCP tools with JavaScript, the timing can decide whether Lighthouse catches them in its snapshot. Second, accessibility tree variability: big changes in DOM size or complexity reshape the tree that agents depend on. Third, layout shift: ads, images without dimensions, or injected content can move elements between the moment an agent spots them and the moment it tries to interact. Cutting CLS and registering tools early in page load both make your results steadier.
| Audit | What it checks and how to pass | Group |
|---|---|---|
| Registered WebMCP tools | Lists the tools your page exposes to agents. Informational. Register with toolname and tooldescription, or with registerTool. | WebMCP |
| Forms missing declarative WebMCP | Flags forms with no WebMCP metadata. Add toolname and tooldescription attributes to the form. | WebMCP |
| WebMCP schema validity | Checks your tool definitions are valid. Fix reported errors or warnings, then re-run. | WebMCP |
| llms.txt | Checks for a machine-readable summary file at your domain root. Add a simple llms.txt file. | Discoverability |
| Accessibility for agents | Names and labels, valid roles, visible interactive elements. Use semantic HTML and ARIA. | Accessibility |
| Layout stability (CLS) | Measures visual stability so agents do not misclick. Reserve space for images and ads. | Stability |
How Do You Run the Agentic Browsing Audit?
You can run the Agentic Browsing audit through PageSpeed Insights or Chrome DevTools, the same places you already run Lighthouse. Open PageSpeed Insights, enter your URL, and the Agentic Browsing results show up next to Performance, Accessibility, Best Practices, and SEO. For the WebMCP audits specifically, you need Chrome 150 or later and the WebMCP origin trial enabled, so most sites can review the accessibility, layout, and llms.txt checks first and come back to WebMCP later. Because the checks are deterministic, you can also wire them into an automated testing pipeline and track the pass ratio over time.
What Should You Do First to Improve Agentic Readiness?
Start with the work that helps both humans and agents, then add WebMCP last. Chrome’s own advice is to adopt WebMCP to expose your logic and forms, keep a sound accessibility tree with semantic HTML and ARIA, and reduce layout shifts so agents can interact reliably. A practical order looks like this: fix your CLS, clean up your accessibility tree, add an llms.txt file, and only then register WebMCP tools for your key forms and actions. Adding clear structured data on top gives agents extra context about what each page is. If you want this handled end to end, our technical SEO service and answer engine optimization service cover the full checklist.
Agentic Browsing is an experimental Lighthouse category that measures how well your site is built for AI agents to read and use. It runs a set of deterministic audits covering WebMCP tools, an llms.txt file, agent-centric accessibility, and layout stability. It became available through PageSpeed Insights and Chrome DevTools alongside the usual Performance, Accessibility, Best Practices, and SEO categories.
WebMCP is a way to expose specific actions on your site to AI agents, called registered tools, such as Book a Table or Add to Cart. You register tools either declaratively, by adding toolname and tooldescription attributes to a form, or imperatively, using navigator.modelContext.registerTool in JavaScript. It gives agents a clear, machine-readable menu of what they can do on your page.
No. The Agentic Browsing category is experimental and is not a ranking factor. Google built it to gather data and give site owners useful signals while the standards for the agentic web are still being defined. You will not lose rankings for missing newer agent features. The value is that its checks overlap with accessibility and stability work that already helps real users.
Because the standards for the agentic web are still emerging, the category reports a fractional score, a ratio of checks passed, plus a pass, fail, or warning per audit. The current focus is gathering data and giving you actionable signals rather than a single definitive grade. A pass ratio in the header lets you track progress as you fix issues.
Declarative WebMCP adds toolname and tooldescription attributes directly to your HTML form elements, which is the simplest method for standard forms. Imperative WebMCP uses JavaScript and navigator.modelContext.registerTool, which suits dynamic cases where tools are created at runtime. Lighthouse detects both, but tools registered late with JavaScript can sometimes be missed in the snapshot, so register them early.
You need Chrome 150 or later for the full category, and the WebMCP audits also require registering for the WebMCP origin trial. The accessibility, layout stability, and llms.txt checks are easier to act on right away, so many sites start there. WebMCP support and the wider category are experimental and based on proposed standards, so expect changes over time.