Lighthouse Agentic Browsing: How Sites Score for AI Agents

Last updated June 17, 2026 · feature is experimental

Google just added an Agentic Browsing category to Lighthouse, the same tool your team already runs on every site, so it now checks how ready your pages are for AI agents. The useful surprise is that most of what it rewards is technical hygiene you may already have in place, with only two genuinely new things to add.

If you run Lighthouse, and almost everyone shipping a website does, Google just quietly handed you a new way to look at your site, this time through the eyes of an AI agent rather than a human visitor. Sitting alongside the familiar Performance, Accessibility, Best Practices, and SEO categories there is now an experimental fifth one called Agentic Browsing, and what it measures is how well your pages are built for machines to read, navigate, and act on. It is early, it needs a recent build of Chrome, and parts of it rest on standards that are still being proposed, but the direction it points in is worth understanding right now, because it is the clearest checklist anyone has published for what an agent ready site actually looks like.

What Google actually added

The new Agentic Browsing category evaluates, in Google’s framing, how well your site is constructed for machine interaction, and it does so through a set of deterministic audits, which simply means the checks are reproducible rather than fuzzy, so you can wire them into your build pipeline and get the same answer every time. The interesting design choice is what it deliberately does not do. Unlike every other Lighthouse category, it gives you no single score from 0 to 100. Instead of a number you get a fractional score, a ratio of how many agent readiness checks your site passes, along with pass or fail status on specific audits, because Google is upfront that the standards here are still emerging and would rather hand you actionable signals than a falsely precise grade.

The idea that should reframe how you think about this

Here is the line in the documentation that is worth more than all the rest combined. Google describes the accessibility tree, the structured model a browser builds of your page, as the agent’s primary data model, and it calls clean semantic HTML and proper labeling the “machine-eye view” of your page. Sit with that for a second, because it quietly rewrites years of how our industry has treated accessibility. The same semantic structure and labeling that most teams have filed under compliance, the thing you do so a screen reader works and a lawyer stays away, turns out to be precisely how an AI agent perceives and operates your site. Accessibility just stopped being only an obligation and became a competitive readiness signal.

What it actually checks

Underneath, the category sorts its signals into a few clear buckets. The first is WebMCP, a proposed standard for exposing your site’s logic and forms to agents, where Lighthouse watches whether you register tools an agent can call, both the declarative kind defined in your HTML and the imperative kind defined in JavaScript. The second is agent centric accessibility, a filtered subset of the accessibility audits that matter most for machines, checking that every interactive element carries a real programmatic name, that roles and their parent and child relationships are valid, and that nothing stays interactive while being hidden from the accessibility tree. The third bucket is stability and discoverability, which measures Cumulative Layout Shift, because an agent that located a button a moment ago needs it to still be there when it goes to click, and which also checks for llms.txt, a machine readable summary published at the root of your domain.

The good news most coverage will miss

Read that list again with a practical eye and something genuinely reassuring jumps out. Most of what makes a site agent ready is technical work you may already have done. A clean accessibility tree is the same thing accessibility specialists have been pushing for years. Low Cumulative Layout Shift is a Core Web Vitals metric you have probably been chasing since 2021. If your technical foundation is solid, a real share of your agent readiness is already paid for, and you are mostly being rewarded for hygiene you practice anyway. The genuinely new work is narrow, and it comes down to two things, publishing an llms.txt file, which is close to trivial, and adopting WebMCP, which only matters if your site has forms or actions an agent would actually want to use.

Accessibility just stopped being only an obligation and became a competitive readiness signal.

Why there is no score, and why that is the right call

It is tempting to be annoyed that there is no tidy number to chase, but the absence of one is the most honest thing about this release. The standards underneath, WebMCP in particular, are experimental and ride on an origin trial, the feature needs Chrome 150 or later, and a weighted score from 0 to 100 would imply a settled science that does not exist yet. Treat the category for what it is, a checklist of signals to watch and improve, not a leaderboard to game. Your results will also wobble a little between runs, because the timing of JavaScript tool registration, changes in the size of your DOM, and layout movement from ads or unsized images can all change what Lighthouse manages to capture in a single snapshot, so read the trend across several runs rather than fixating on any one.

What to actually do, in priority order

If you want a sane order of operations, start with the durable signals that will matter no matter how the proposed standards shake out. Tighten your accessibility tree first, since names and labels, valid roles, and nothing interactive being hidden are an accessibility win and an agent win in a single pass. Bring your Cumulative Layout Shift down next, for the same double benefit. Publish an llms.txt at your root after that, because it is cheap and it is the one discoverability signal here that is simple to ship today. Then, and only if your site has meaningful forms or actions, evaluate WebMCP, going in clear eyed that you are stepping into an origin trial and a moving target, which is fine to pilot but not yet something to bet your roadmap on.

What it means for founders, CMOs, and SEOs

For a founder, the reassuring read is that agent readiness is mostly an extension of technical quality you should want anyway, so it is less a new budget line and more a fresh reason to finally fund the accessibility and performance work that kept slipping down the list. For a CMO, the reframe is the valuable part, because the accessibility investment that has always been hard to justify on revenue grounds just picked up a second, future facing rationale, and the same goes for site speed and stability. For an SEO, this lands squarely in your lane, since Lighthouse is already your tool and the accessibility tree and Cumulative Layout Shift are already things you touch, which means the new skills to pick up are narrow and learnable, llms.txt today and WebMCP as it matures. It also sits neatly alongside the discovery layer Google is building with Agentic Resource Discovery and the separate work of getting cited by ChatGPT and Perplexity, and together with the 90 day AI Search framework we run for SaaS clients, these pieces are starting to sketch a coherent picture of what being ready for the agentic web really takes.

None of this calls for a scramble, because here the smartest move is also the calmest one. Run the audit, take the easy and durable wins that double as accessibility and performance gains, ship an llms.txt, and keep WebMCP on your watch list rather than your critical path. The agentic web is still being drafted, but Google just told you, inside a tool you already trust, what a site that is ready for it looks like, and most of that readiness turns out to be the quality work you already knew you ought to be doing.

Frequently asked questions