Lighthouse Can Now Score Your Site for AI Agents: A Practical Guide

In the last guide, I split search into two channels: discovery engines that hand you a list of links, and answer engines that synthesize a response and may never send anyone to your site at all. There's a third channel worth adding to that picture now, and it's a different kind of visitor entirely — not something reading your page to answer a question, but something trying to use your page. Fill in a form. Compare two products. Complete a checkout. An agent, acting on a person's behalf.

Google has started building tooling to measure how ready a site is for that kind of visitor. Lighthouse — the same auditing tool that's scored your Performance, Accessibility, Best Practices, and SEO for years — added a new category: Agentic Browsing. ^[1] It's built directly on top of WebMCP, a new web standard for letting sites expose their own actions to agents, which Google gave an official showcase at I/O in May 2026. ^[2] Both are new. Neither is a side project — but neither is settled yet either. Here's what's actually in it.

A score that isn't a score

Every other Lighthouse category gives you a weighted average from 0 to 100. Agentic Browsing doesn't. Because the standards for how agents browse the web are still being written, Google is deliberately not producing a definitive ranking yet — the goal right now is data and actionable signals, not a grade. ^[1]

What you get instead:

• A fractional score — a ratio of how many agentic-readiness checks your site passes, not a weighted composite.
• Pass/fail status on individual audits, which can surface as errors or warnings when something like WebMCP schema validity is broken.
• A pass ratio at the category level, mostly useful for tracking whether you're trending up or down over time. ^[1]

If you're used to chasing a 100 on Performance, recalibrate. There's no 100 here. There's just "more of your site is legible to an agent than it was last month, or less."

What the audits actually check

The category currently covers six audits, grouped into three areas:

WebMCP integration

Registered WebMCP tools, forms missing declarative WebMCP, and WebMCP schema validity. Lighthouse calls into Chrome's DevTools Protocol to watch whether your page registers tools for agents, checking both tools declared directly in HTML and ones registered dynamically via JavaScript. ^[1]

WebMCP is worth understanding properly, since three of the six audits are really about it. The core idea: instead of an agent inspecting a button or field and guessing its purpose from the DOM — what Google calls actuation, the agent simulating clicks and typing the way a human would — a site can explicitly declare a tool with a name, a purpose, and a schema. checkout, filter_results, submit_application. The agent calls the tool directly instead of reverse-engineering your UI. ^[2]

Three things WebMCP standardizes:

• Discovery — a standard way for a page to register its tools with an agent.
• JSON Schemas — explicit definitions of inputs and outputs, so an agent isn't guessing what a field expects and hallucinating a value that doesn't fit.
• State — a shared, real-time understanding of what's actually available to act on in the current page context. ^[2]

There are two ways to build this: the Imperative API, plain JavaScript for defining tools around form input, navigation, or state management; and the Declarative API, which is just annotations added to standard HTML forms. ^[2] That split is exactly why Lighthouse checks both — a form with no declarative annotations and no imperative registration is invisible to an agent no matter how well-designed it is for a human.

The use cases in Google's own docs are concrete rather than hypothetical: a support flow where a tool routes an agent straight to the right form and pre-fills known fields, a multi-city travel booking completed in fewer round trips, or a date_pick tool that bridges a date picker built for human eyes into something an agent can actually operate. ^[2]

Worth knowing before you get excited: WebMCP tools currently require an open browser tab or webview — there's no headless support, so an agent can't call your tools without a visible browsing context. Complex interfaces need real refactoring work to expose meaningfully, and tools are only discoverable by an agent that visits your site directly. ^[2] This isn't a drop-in.

Agent-centric accessibility

Accessibility for agents. Lighthouse pulls a specific slice of the existing accessibility audit suite that matters most for machine interaction: whether every interactive element has a programmatic name, whether roles and parent-child relationships in the accessibility tree are structurally valid, and whether content that's interactive is actually exposed to that tree rather than hidden from it. ^[1] The reasoning: an agent's primary model of your page isn't the rendered pixels, it's the accessibility tree. That's the "machine-eye view" it's actually navigating.

This is the one piece of genuinely good news in this whole category. If you've already invested in semantic HTML and proper ARIA labeling for screen reader users, that work is doing double duty now. Nothing new to build — just a second customer for the same work.

Stability and discoverability

Layout stability and llms.txt. Cumulative Layout Shift shows up here because agents rely on element positioning to interact reliably; a shift between when an agent locates a button and when it tries to click it breaks the interaction the same way it breaks a human's fat-fingered tap on mobile. ^[1] And Lighthouse now directly checks for the presence of a machine-readable llms.txt file at your domain root — the same file the last guide's quarterly checklist already had you thinking about, now with an automated audit behind it. ^[1]

Why your results will bounce around

Unlike Performance, where a slow score usually points to one clear culprit, Agentic Browsing results are deterministic in method but noisy in practice. Three known causes:

• Registration timing. If tools are registered via JavaScript rather than declared in HTML, whether Lighthouse's snapshot catches them depends on exactly when in the page lifecycle they register. ^[1]
• Accessibility tree variability. Meaningful changes to DOM size or complexity reshape the accessibility tree between runs, which is the core structure this whole category leans on. ^[1]
• Layout shift from things you don't fully control. Ads, images without explicit dimensions, and injected third-party content can all move elements around between page load and interaction. ^[1]

The practical takeaway: don't treat a single run as a verdict. Run it repeatedly, or in CI, and watch the trend rather than the number.

What to actually do about it

For dev teams, the honest priority order right now:

1. Ensure a sound accessibility tree first. Semantic HTML and correct ARIA labeling are the highest-leverage thing here, and they're not agent-specific work — it's accessibility work you should already be doing. ^[1]
2. Reduce layout shift. Specify image dimensions, reserve space for injected content, audit any third-party embeds that load late. This is standard Core Web Vitals hygiene, not a new discipline.
3. Try WebMCP locally before committing to it. You don't need the origin trial to experiment — a Chrome flag (chrome://flags/#enable-webmcp-testing) turns it on for local development. ^[2] Worth a spike if agent-driven task completion — booking, support, checkout — is core to your product. For a typical marketing site or blog, it's a "keep an eye on it" item rather than a "ship it this sprint" one, given the browsing-context and refactoring overhead involved.

For marketing and content teams, the ask is smaller and mostly extends what the last guide's checklist already had you doing:

• Confirm llms.txt still exists and is current at your domain root — it's now a specific, automated audit, not just a good habit.
• When reviewing new pages before publish, spot-check that buttons and links have real accessible names, not just icons or ambiguous "click here" text.
• If your dev team is testing WebMCP, ask what actions they're exposing as tools — it's a useful prompt for thinking about which flows on your site an agent would actually want to complete on a user's behalf.

Add it to your quarterly checklist

If you're running the SEO health check from the last guide, these are worth appending:

• Run Lighthouse's Agentic Browsing category (Chrome 150+) and note the pass ratio, not just the raw number
• Confirm llms.txt is present and current at the domain root
• Spot-check new pages for accessible names on interactive elements before publish
• If experimenting with WebMCP, verify registered tools actually show up in the Lighthouse report

The thread connecting this to everything in the last guide is the same one: the work that makes a page legible to an agent — clean semantics, stable layout, an honest llms.txt — is mostly the same work that already made it good for screen readers, good for search crawlers, and good for humans in a hurry. Lighthouse just started keeping score on the newest visitor.

---