Google just added a new Lighthouse category at Google I/O 2026. Not for performance. Not for accessibility. Not for SEO.
For AI agents.
The new Agentic Browsing audit checks whether your site is navigable by machines, not just humans. It is experimental and it does not give you a 0 to 100 score. It gives you a pass/fail ratio across a set of deterministic checks. And some of those checks are things most developers have never thought about.
I added llms.txt to this site today partly because of this. Let me explain what the audit actually checks, why it matters, and what you need to implement.
Table of Contents#
- What the Agentic Browsing Audit Actually Is
- The Three Things It Checks
- llms.txt: The AI Equivalent of robots.txt
- WebMCP: Exposing Your Site Logic to Agents
- AI Accessibility: Not the Same as Human Accessibility
- How the Scoring Works
- What You Should Actually Do Right Now
- Why This Matters More Than It Looks
- FAQ
What the Agentic Browsing Audit Actually Is#
Lighthouse has always been about measuring how well a page serves users. Performance, accessibility, SEO, best practices. All of these optimize for a human sitting in a browser, clicking around, reading content.
The Agentic Browsing category asks a different question: what happens when a non-human agent tries to navigate your site?
AI agents browse the web now. They fill out forms, extract structured information, navigate multi-step flows, and take actions on behalf of users. Claude, GPT-4o, Gemini, and dozens of specialized agents are being pointed at websites constantly. Most websites are built with no thought given to this audience.
The audit makes that gap visible. It runs a set of deterministic checks and tells you, concretely, which ones your site passes and which it fails. The documentation is clear that the current goal is not to rank sites but to gather data and give developers actionable signals.
Think of it less like a score and more like a compliance checklist. You either have llms.txt or you do not. Your accessibility tree either has proper programmatic naming or it does not. These are binary facts, not opinions.
The Three Things It Checks#
1. Discoverability for AI Agents#
This covers whether AI agents can find out what your site does before they start navigating it.
The main check here is the presence of llms.txt at your domain root. This is the AI equivalent of robots.txt. Where robots.txt tells crawlers what they are allowed to access, llms.txt tells language models what your site contains and how to navigate it effectively.
The llms.txt specification is straightforward. It is a markdown file. It has one required element: an H1 heading with your site or project name. Everything else is optional but genuinely useful. A blockquote summary, organized sections of links to key pages, descriptions of what each section contains.
The idea is that an LLM processing your llms.txt should be able to answer "what is this site, what does it contain, and where should I go to find specific things?" without having to crawl dozens of pages to build that understanding.
2. WebMCP Integration#
This is the more technical check, and the one most developers are least familiar with.
WebMCP is Model Context Protocol implemented in the browser. MCP is Anthropic's open standard for connecting AI models to external tools and data sources. The web version of this, WebMCP, lets websites expose structured tools to AI agents directly through the browser.
When an agent navigates to a page that implements WebMCP, it can discover what actions the page supports: searching for products, submitting a form, filtering results, navigating to a checkout. Instead of the agent trying to figure out your interface by reading the DOM and guessing where to click, you are telling it exactly what it can do and how.
Lighthouse monitors WebMCP tool registration through Chrome DevTools Protocol. It captures both declarative tools (defined in HTML) and imperative tools (registered via JavaScript). The audit checks whether tools are registered, whether they are valid, and whether they are available at the right time.
This is early. Most sites do not implement WebMCP yet. But the pattern is directionally clear. The sites that make it easy for agents to take actions will see more agent-driven traffic than sites that do not. The audit is giving you early warning that this is coming.
3. AI Accessibility#
Human accessibility is about whether people with disabilities can use your site. Screen readers, keyboard navigation, contrast ratios, focus management.
AI accessibility is related but distinct. It is about whether the accessibility tree of your page is structured in a way that allows a machine to correctly understand what every element is and does.
The specific checks include:
Programmatic naming. Every interactive element needs a name that a machine can read. Buttons with only icon content and no aria-label. Form fields with no associated label. Links with text like "click here" that conveys nothing about the destination. These are problems for screen readers, and they are equally problematic for AI agents trying to understand what a button does.
Role validity. Elements need roles that correctly describe their function. A div that looks like a button but has no role="button" and no keyboard handling is invisible as a button to the accessibility tree. An agent trying to click it may not recognize it as an interactive element at all.
Visibility confirmation. The audit checks whether elements that appear visible to users are also visible within the accessibility tree. Elements hidden with visibility: hidden or display: none are correctly excluded. Elements that are visually present but accidentally hidden from the accessibility tree create mismatches that confuse agents.
Cumulative Layout Shift. This one connects to reliability rather than comprehension. If your page shifts around during load, an agent that targets an element at one position may end up clicking something else entirely after a layout shift. The CLS check in the Agentic Browsing category is specifically concerned with whether agents can reliably interact with elements they have located.
llms.txt: The AI Equivalent of robots.txt#
Since the llms.txt check is the most actionable thing you can implement right now, it is worth going deeper on the format.
The file lives at the root of your domain: https://yourdomain.com/llms.txt. It is plain markdown. Serve it as text/plain or text/markdown.
The spec defines this structure:
# Your Site Name
> One paragraph summary of what this site is and who it is for.
## Section Name
- [Page Title](https://yourdomain.com/page): Brief description of what this page contains.
- [Another Page](https://yourdomain.com/other): What an agent will find here.
## Optional
- [Less critical pages](https://yourdomain.com/archive): Can be skipped in shorter contexts.
The sections under ## Optional are explicitly intended for agents working in constrained contexts. An LLM with a small context window can load your llms.txt, process everything above ## Optional, and get a useful understanding of your site without reading every link.
The format is intentionally simple. It is markdown, not JSON, not XML, not a schema. The goal is that a human can write it by hand and an LLM can read it naturally.
A few things worth including that are often missed:
Describe the audience. Not just "this is a blog about AI" but "this blog targets engineers building production agent systems." That context helps an agent decide whether your site is relevant to the query it is trying to answer.
Explain the structure. If your site has distinct sections with different purposes, say so. Blog contains long-form technical writing. AgentX is an interactive pattern library. Workflows has code examples. An agent navigating your site cold has to figure this out by crawling. Your llms.txt can just tell it.
Link to the machine-readable versions of your content. RSS feed, sitemap, API endpoints if you have them. Agents prefer structured data when it is available.
Keep it current. A llms.txt that lists ten articles when you have forty is less useful than one that is maintained. Treat it like your README. Update it when your site changes.
WebMCP: Exposing Your Site Logic to Agents#
WebMCP is currently in early adoption. The Chrome DevTools Protocol implementation captures tool registrations, but most sites do not register any tools yet.
The basic idea is that you declare what your page can do in a way that agents can discover at runtime. A search page might expose a search tool. A booking flow might expose check_availability and create_reservation. A form might expose submit_inquiry.
Declarative registration looks like a <meta> tag or a script block in your HTML. Imperative registration happens via JavaScript at runtime.
The benefit is not just discoverability. It is reliability. When an agent knows it can call search(query) instead of trying to locate a search input, type into it, and submit, the interaction is deterministic rather than fragile.
This is still early enough that implementing WebMCP today will make you an early adopter. Whether you do it depends on whether your site has actions that agents might reasonably want to take. For content sites, the priority is lower. For apps with forms, searches, and transactional flows, the payoff from clear tool exposure is higher.
AI Accessibility: Not the Same as Human Accessibility#
If you already have good accessibility scores in Lighthouse, you are partway there but not all the way.
Human accessibility audits focus on whether disabled users can access your content. AI accessibility focuses on whether the accessibility tree is accurate and unambiguous enough for a machine to reason about it.
The practical difference shows up in edge cases.
An image button with aria-label="Save" is accessible to a screen reader user. It is also clear to an AI agent. A button with no accessible name at all fails both human and AI accessibility. A button with a confusing name like aria-label="icon-23" might pass some automated checks but fails to communicate anything useful to an agent.
Layout shifts matter more for agents than for humans. A human who intended to click "Submit" and accidentally clicked "Cancel" because a banner appeared and shifted the page will notice the mistake and click again. An agent executing a workflow step that requires clicking "Submit" may not catch that the layout shifted and it clicked the wrong element. The error propagates.
The practical checklist for improving AI accessibility:
- Every button, link, and form control needs a clear, descriptive accessible name
- Use semantic HTML elements instead of divs styled to look interactive
- Do not rely solely on placeholder text as a form label
- Verify that
aria-hiddenis not accidentally hiding content that agents need to see - Check that your CLS score is genuinely low, not just acceptable for human users
- Test your page with an accessibility tree inspector and read it as if you were an agent seeing it for the first time
How the Scoring Works#
The Agentic Browsing score is a fraction, not a number. The documentation describes it as "a ratio showing how many agentic readiness checks your site passes."
This means a site that passes three of five checks shows 3/5, not a weighted score. Every check has equal weight. There is no partial credit for almost having llms.txt or for having some accessible names but not all.
Results can vary between runs. JavaScript-based WebMCP tool registration depends on when the tool registration fires relative to when Lighthouse captures the state. Accessibility tree construction changes if the DOM is modified dynamically. A layout shift that happens sometimes but not always will produce inconsistent CLS results.
The documentation is clear that the current goal is data collection, not ranking. Google is using these audits to understand the landscape of agentic web readiness, not to reward or penalize sites in search rankings. Yet. That framing will change as agentic browsing becomes mainstream.
What You Should Actually Do Right Now#
In order of impact and ease:
1. Add llms.txt today. It takes thirty minutes. Drop a markdown file at your domain root. Write a summary of what your site does, link to your key pages with descriptions, and keep it updated. This is the fastest win and the audit check most developers are currently failing.
2. Audit your accessible names. Run a Lighthouse accessibility report and look specifically at the button and form audits. Check every element that uses an icon instead of text. Check every form field to ensure it has an associated label, not just a placeholder. Fix the missing names.
3. Check your CLS score in context. A CLS score of 0.05 on a mostly static page is fine. If your page loads ads, inserts content dynamically, or uses web fonts that cause layout shifts, test whether those shifts happen in the window where an agent would be trying to interact with your content.
4. Read your accessibility tree. Open Chrome DevTools, go to the Elements panel, and enable the Accessibility Tree view. Read it as if you are an agent. Does every interactive element have a meaningful name and role? Are there elements that look interactive but show up as generic in the tree? Fix what you find.
5. Evaluate WebMCP for your use case. If your site has transactional features, forms, or search, look at the WebMCP spec. Implementing it now puts you ahead of the majority of the web. If your site is primarily content, it is lower priority.
Why This Matters More Than It Looks#
The Agentic Browsing audit looks like a minor new tab in Lighthouse. It is actually a leading indicator of a significant shift in how the web works.
Right now, most AI agent interactions with websites are fragile. Agents parse raw HTML, try to find clickable elements, attempt form submissions, and fail often. The failure modes are expensive: agents loop, take wrong actions, or give up and report that the task cannot be done.
The reason this happens is that websites are built for human visual parsing. Agents are not bad at understanding what a website does. They are bad at interacting with interfaces designed entirely around visual cues that do not exist in the accessibility tree or the DOM structure.
The sites that fix this early will be the ones that agents recommend, navigate successfully, and return to. That is not fundamentally different from how human SEO works. The sites that are easier to use get more traffic. The mechanism shifts; the principle does not.
I covered some of this from the orchestration side in Before You Run 10 Claude Agents and The Four Agent Orchestration Patterns. The agent side of the equation is improving rapidly. What has not kept up is the web. The Lighthouse audit is Google's way of making that gap measurable.
The sites that are ready when agentic browsing becomes mainstream will have an advantage. The good news is that the requirements are not exotic. Semantic HTML, proper accessible names, a plain text file that describes your site. The technical bar is low. Most sites just have not done it because there was no reason to yet.
Now there is a score that tells you whether you have.
References: Lighthouse Agentic Browsing Scoring (Chrome Developers), llms.txt Specification, WebMCP documentation
FAQ#
What is the Lighthouse Agentic Browsing audit?
It is a new experimental category in Google Lighthouse that evaluates how well your site supports AI agent navigation. Unlike the existing categories (Performance, Accessibility, SEO, Best Practices), it uses a fractional pass/fail ratio rather than a 0-100 score. It checks three things: whether you have llms.txt for agent discoverability, whether you implement WebMCP to expose site functionality to agents, and whether your accessibility tree is structured clearly enough for machine interaction.
What is llms.txt and why do I need it?
llms.txt is a markdown file you place at the root of your domain (e.g., https://yourdomain.com/llms.txt). It tells AI agents and language models what your site contains and how to navigate it, similar to how robots.txt tells crawlers what they can access. An agent reading your llms.txt should be able to understand your site structure and find relevant pages without having to crawl extensively. The llms.txt specification requires only an H1 heading — everything else is optional but useful.
What is WebMCP and is it required?
WebMCP is an implementation of Anthropic's Model Context Protocol (MCP) in the browser. It lets websites expose structured tools to AI agents — for example, a search tool, a form submission tool, or a booking action. Lighthouse checks whether your site registers any WebMCP tools. It is not technically required for the audit to run, but sites without WebMCP fail that particular check. For content-only sites, the impact is low. For sites with transactional features or forms, implementing WebMCP improves agent interaction reliability significantly.
How is AI accessibility different from regular accessibility?
Human accessibility focuses on whether disabled users can access content using assistive technologies. AI accessibility focuses on whether the accessibility tree is accurate, unambiguous, and stable enough for a machine to reason about. The checks overlap significantly — both require elements to have proper names, roles, and visibility. The key differences are around specificity of naming (generic labels that are acceptable for humans are often insufficient for machines) and layout stability (an agent cannot recover from clicking the wrong element due to a layout shift the way a human can).
Will failing the Agentic Browsing audit hurt my search ranking?
Not currently. Google has stated that the current goal is to gather data and provide actionable signals, not to rank sites. The audit is experimental. That said, the direction of travel is clear: as AI agent-driven browsing becomes more mainstream, sites optimized for agent interaction will perform better in agent-driven referral traffic, even if that does not immediately translate to traditional search ranking signals.
How often will the audit score change between runs?
Results can vary. JavaScript-based WebMCP tool registration timing affects capture. Accessibility tree changes based on DOM modifications. CLS can fluctuate if your layout shifts happen inconsistently. The deterministic checks (like llms.txt presence) are stable. The dynamic ones (WebMCP timing, CLS) may produce different results across runs. This is acknowledged in the documentation.
What is the fastest way to improve my Agentic Browsing score?
Add llms.txt. It is a thirty-minute task, it is completely within your control, and it is one of the core checks. After that: audit your accessible names (every button, link, and form field should have a descriptive label), check your CLS score in the context of dynamic content, and read your accessibility tree in Chrome DevTools as if you were an agent navigating your site cold. These steps will address the majority of failures without requiring any new infrastructure.