Lighthouse agentic browsing: Google’s New AI Agent Readiness Audit Explained

Why agents are reading your site now

If you run lighthouse agentic browsing on a schedule and just noticed a new category in your report, here is the shift it reflects. For most of the web's history, the automated visitors that mattered were search crawlers. They read text and indexed what they found by following links. They never touched your forms or your checkout flow.

That is changing fast. Browser-based autonomous browsing agents like Perplexity's Comet and OpenAI's Atlas accounted for roughly 71% of observed agentic traffic in April 2026, and Comet alone led at 48.12%. These agents click buttons and fill fields as they complete tasks on a user's behalf.

So an agent getting stuck on a layout shift or an unlabeled button is now a measurable failure, the same way a slow Largest Contentful Paint score is. The frustrating part for anyone who has watched these tools work is how brittle they are. Anthropic reported that unmitigated agents fall for 24% of prompt injection attacks, and success rates on real purchase flows have been poor enough that OpenAI shut down Operator in August 2025 after it failed to reliably complete web purchases.

The new Lighthouse agentic browsing category is a formalization of something accessibility teams have argued for years: clean, well-structured markup is what machines need to understand a page. Now there's a tool that measures it.

What lighthouse agentic browsing measures

Lighthouse 13.3, released May 7, 2026, introduced the Agentic Browsing category. It evaluates how well a site is built for browser automation and machine interaction through deterministic checks that mostly pass or fail. Matt Zeunert of DebugBear notes that the category is still marked as "under development", and a plain site like example.com gets a green 2/2 result, so you won't fail it just for skipping new AI features.

The lighthouse agentic browsing category bundles four areas into two groups. Two of them, the accessibility tree and Cumulative Layout Shift, reuse data Lighthouse already collects. The other two, WebMCP and llms.txt, are newer checks aimed specifically at agents.

That split matters because of where it puts you. If you have already invested in accessible markup and stable layouts, half of this audit is work you've largely done. The H3 sections below break down each check so you can act on it.

Accessibility tree integrity

The accessibility tree is a simplified, structured representation of the page that the browser builds from the Document Object Model (DOM). According to web.dev's accessibility guide, it contains objects for markup elements and text nodes with their attributes, and assistive technologies read it through platform accessibility APIs. An autonomous browsing agent can process this tree far more efficiently than raw HTML or a screenshot, because it strips the page down to what's there and what each thing does.

The audit checks that the tree is well-formed. Every interactive element needs a programmatic name, and roles have to be valid with sensible parent-child relationships. It also flags content that is hidden from the tree while still being interactive, which is a trap for any agent walking the structure.

Why does an accessible name matter so much? Because, as the NZ Government accessibility guide puts it, "interactive elements always need an accessible name." An agent walking the tree to find the right button has nothing to act on if the node is unnamed. This lighthouse agentic browsing audit reuses Lighthouse's existing accessibility checks, so if you already run them, you've framed this work as accessibility. Now it's also agent infrastructure.

WebMCP for browser automation

WebMCP is a proposed web standard that lets a site expose a menu of named, typed actions with descriptions instead of forcing an agent to guess intent from the DOM. A site registers tools with the new navigator.modelContext API, authored by engineers from Microsoft and Google through the W3C Web Machine Learning Community Group. Each tool has a name and a JSON input schema with a description, which the Lighthouse audit validates.

The point is to fix browser automation at its weakest link. Right now, an agent booking a flight has to read your page and work out each field's purpose before it can hope to get the date format right. With WebMCP, your site declares a tool and the agent calls it as a function. The same logic applies to any browser automation task that currently depends on fragile pixel-math and DOM-guessing.

Be honest with your roadmap about its status. WebMCP shipped as an early preview in Chrome Canary in February 2026 and sits behind a flag. The developer Dejan Petrovic put the skepticism plainly: it is "metadata duct taped onto the UI" with "no cross browser consensus" and "no defined security model for malicious agents." This is the most forward-looking check in the category and the least production-critical for most sites today.

Layout stability and llms.txt

The stability and discoverability checks belong together. Cumulative Layout Shift (CLS) measures how much visible content moves around unexpectedly during load, and Google considers values up to 0.1 a good score, with shifts of 0.15 and higher consistently perceived as disruptive. For an agent, a shift mid-action is worse than an annoyance. If the page moves after the agent has located a target, it misclicks.

The llms.txt check looks for a machine-readable summary at the domain root. The audit confirms its presence and basic quality, including an H1 and enough length, with links present. It works like robots.txt, but instead of telling crawlers where to go, it tells models what your site is.

If you think in SEO terms, treat llms.txt as a readiness signal for machine discovery. Google's John Mueller compared it to the keywords meta tag: "none of the AI services have said they're using LLMs.TXT (and you can tell when you look at your server logs that they don't even check for it)." So pass the check because it's cheap, and don't expect a traffic bump from it.

How to run the audit

If you've run Lighthouse before, the mechanics of lighthouse agentic browsing are familiar and the only new part is the category itself. You need Lighthouse 13.3 or later, where the category ships in the default configuration.

From Chrome DevTools, the steps are short:

1. Open DevTools and check the "Agentic Browsing" category in the Lighthouse tab settings.

2. Run the audit on the page you want to test and read the pass/fail panel that appears.

WebMCP detection needs one extra step on older Chrome builds. If you're on Chrome 130 to 149, enable chrome://flags/#enable-webmcp-testing and relaunch. On Chrome 150 and later the category appears without that flag.

For a command-line run, point the Lighthouse npm package at your URL with the agentic-browsing category. Whichever path you pick, fold this into the scheduled Lighthouse run you already maintain. The category is one more box to check, and the report lands beside your existing performance and accessibility data.

How to read the results

This is where the audit trips people up. The 0-100 Performance score gives way here to pass-ratio coverage. The lighthouse agentic browsing header shows a ratio of how many readiness checks your site passes, with per-audit pass or fail marks and warnings; informational counts appear beside them.

So a small movement in that fractional ratio is not comparable to gaining Performance points. Going from 2/4 to 3/4 means you cleared one more check. If you wire this into a dashboard, treat the number as check coverage and set alerts from individual check changes.

Results also fluctuate between runs, and the reasons are worth knowing before you chase a phantom regression:

• WebMCP tools register at different moments in the page lifecycle, so a tool that loads late can read as absent on a fast run.

• The accessibility tree shape depends on what rendered, so dynamic content changes the nodes Lighthouse sees.

• Layout shift during the synthetic run varies, and lab CLS measurements can come in lower than what a real user experiences.

If you own monitoring, the practical move is to track which checks pass over time. A flapping CLS audit is noise from the test environment far more often than it's a real defect you introduced.

Which fixes matter most

Don't chase every check. The lighthouse agentic browsing category rewards durable structure, and the work sorts cleanly into tiers, so you can decide what to do Monday morning instead of treating all four signals as equal.

Start with the accessibility tree and CLS. These deliver the most value now because they help humans and agents at the same time, and they build on work you've already started. A button that gets a programmatic name becomes usable by a screen reader and an agent in the same commit. Cutting layout shift below 0.1 improves your Core Web Vitals and stops agents from misclicking. This is the same engineering you'd do for users who never touch an AI tool.

Here is a sensible default order of attack:

1. Fix accessibility tree problems first, since they overlap with accessibility work and serve the largest share of real autonomous browsing agent traffic.

2. Bring CLS under control next, because layout stability protects both human reading and agent action.

3. Add llms.txt as a quick, low-effort pass because it's a readiness file for machine discovery.

4. Treat WebMCP as a deliberate, quarter-scale investment once the standard stabilizes and your product has flows worth exposing as tools.

The framing that keeps this sane is to see it as ordinary engineering. A usable, machine-navigable web is the same foundation as a usable human one, which means none of this is a separate compliance project bolted onto your real work. It is your real work, scored against a new audience.

Building for the agent-ready web

Pull the four checks together and the message is consistent. A site built for agents is a site built well, and the audit simply made an existing principle measurable. Clean names and valid roles, backed by stable layout and an honest summary of what your site does, are things careful teams were already shipping.

The standards are still emerging. WebMCP is an early preview, and the category itself is under development while llms.txt still has no confirmed consumer. So the goal right now is durable structure that can survive spec changes next quarter.

Fold lighthouse agentic browsing into the Lighthouse cadence you already run, with fixes for the accessibility and stability signals that help everyone; revisit WebMCP as it matures into something production-ready.