Google’s New Agentic Browsing Score, and What It Means for Your Website
Google’s Lighthouse tool has quietly added a new category to its website audits: Agentic Browsing. It sits alongside the familiar Performance, Accessibility, and SEO scores you might already check. But it measures something different. It measures whether an AI agent can actually use your website.
If that sounds abstract, stick with us. Within a few years, a meaningful share of the traffic hitting your site won’t be a human clicking around. It’ll be an AI assistant, booking an appointment, comparing prices, or filling in a contact form on someone’s behalf. Google is already scoring for it.
What is Agentic Browsing, exactly?
Every webpage you build gets rendered by the browser into two things: the visual layout people see, and a structural map underneath it called the accessibility tree. Screen readers have used this tree for decades to describe pages to blind and visually impaired users. AI agents now read the same tree to understand what’s on a page and what they can do with it.
Chrome’s own documentation calls the accessibility tree an agent’s “primary data model.” An agent doesn’t study your page like a person does. It reads the tree, works out which elements are buttons, which are links, which are form fields, and acts on that structure directly.
Lighthouse’s Agentic Browsing category checks four things:
- Accessibility tree integrity — are your interactive elements named properly, and do your roles and parent-child relationships make sense?
- Cumulative Layout Shift (CLS) — does your page stay visually stable, or do elements jump around after an agent has already “looked” at them?
- llms.txt — do you have a machine-readable summary file at your domain root?
- WebMCP — have you registered any tools an agent could call directly?
Unlike Performance or SEO, this category doesn’t produce a 0–100 score. Google scores it as a simple pass/fail ratio, because the standards here are still forming. A score of 2/4 means your site passed two of the four checks.
Why “accessibility tree is not well-formed” is the one to fix first
Of the four checks, this is the one worth your immediate attention. The other three — CLS, llms.txt, WebMCP — are either things you’ve likely already addressed for Core Web Vitals, or genuinely optional extras still finding their footing. The accessibility tree check is different. It fails for concrete, fixable reasons, and fixing it helps real users too, not just hypothetical agents.
Common causes include:
- Icon-only buttons and links with no accessible name. A social media icon or a hamburger menu that’s just an image, with nothing telling a screen reader (or an agent) what it does.
- ARIA attributes with nothing behind them. A search box carrying aria-expanded and aria-haspopup without the role=”combobox” that’s supposed to justify them. Visually, nothing looks wrong. Structurally, it’s a contradiction that trips up anything reading the tree.
- Contentless elements with labels. A <div aria-label=”Promotional banner”> that’s otherwise empty. The label promises information that doesn’t exist underneath it.
- Broken parent-child relationships. A list item that isn’t inside a list, or a menu item outside a menu — small nesting errors that don’t affect how a page looks, but do affect how it’s read.
None of these are exotic problems. They’re the same issues that WCAG accessibility audits have flagged for years. If your site has already had accessibility-focused UX/UI work done, you likely have a head start.
How to check your own site
You don’t need to wait for Google’s public tools to catch up (PageSpeed Insights hasn’t rolled this category out everywhere yet). Two options work right now:
- Open your site in Chrome, open DevTools, click into the Elements panel, and press a. This opens the accessibility tree directly, and broken or missing nodes show up as warnings.
- Run Lighthouse locally through npm, or use a checker that already supports the newer Lighthouse version, to get the full Agentic Browsing report with specific line-by-line flags.
Either way, you’ll get a list of the exact elements causing the failure, rather than a vague category score.
Should you panic about this?
No. Google has been explicit that this category is still under development, and that the goal right now is gathering signals, not producing a definitive ranking. You won’t lose search visibility overnight because of a low Agentic Browsing score.
What we’d say instead: treat this the way you’d treat any early warning. The businesses that clean up their accessibility tree and layout stability now will have already done the work by the time agentic traffic becomes a meaningful slice of the pie. The ones that wait will be retrofitting under pressure.
And the honest upside is that almost everything this category rewards, you should be doing anyway. Named buttons, valid ARIA, stable layouts. That’s not a new checklist written for robots. It’s the same web accessibility standard that’s existed for years, just with a new audience reading it.
If you want a second pair of eyes on where your site stands, our free website audit covers this alongside the usual performance and SEO checks. Get in touch and we’ll walk you through exactly what’s holding your score back, and what’s worth fixing first.