Lighthouse agentic browsing is an experimental Lighthouse category that tests how easily an AI agent can read and operate a page. It does not produce a 0 to 100 score. It shows a pass ratio such as 3/3 across seven audits: an accessibility-tree check, Cumulative Layout Shift, an llms.txt check, an Agentic Resource Discovery (ARD) manifest check, and three WebMCP audits. Most write-ups call it “Google’s AI-readiness score” and tell you to rush out an llms.txt file. The source code says otherwise. A missing llms.txt costs you nothing, a broken one does, and the audit doing most of the work is plain accessibility.
What the Agentic Browsing Category Is (and Is Not)
The category arrived in Lighthouse 13.3.0 in May 2026. The Chrome for Developers documentation calls it “experimental and based on proposed standards,” and the description inside Lighthouse says it “is still under development and subject to change.” Chrome says the audits use deterministic signals, which makes them suitable for CI/CD checks, though results can still shift as a site changes how it registers tools or responds to agents.
It is not a ranking factor, a Search Console signal, or a measure of whether ChatGPT or Gemini will cite you. Chrome’s scoring page says the goal is gathering data and giving actionable signals, not a definitive ranking. Treat it as a lint pass for machine usability: can an agent driving a browser find your buttons, trust your layout and pick up your machine-readable files? Whether agents visit you at all is a separate question, covered in our guide to agentic browsers and SEO.
Where to Run It: Chrome DevTools, CLI or PageSpeed Insights
- Chrome DevTools: Chrome 150 added an “Agentic Browsing” checkbox to the Lighthouse panel, and it is off by default, which explains most “I can’t find it” confusion. Tick it, then analyse the page. Each Chrome release bundles a fixed Lighthouse version, so DevTools can lag the latest release.
- Lighthouse CLI: the most current option.
npx lighthouse@latest https://example.com/ --only-categories=agentic-browsingruns only this category. We tested with Lighthouse 13.6.0 (27 October 2026). - PageSpeed Insights API: Lighthouse’s own report viewer has requested the
agentic-browsingcategory from the PageSpeed Insights API since June 2026. We could not confirm that the PageSpeed Insights web interface shows it for every URL, so check the report you actually get.
For the performance, SEO and accessibility categories, see our Google Lighthouse guide. This category is scored on different rules.
The Seven Lighthouse Agentic Browsing Audits at a Glance
Lighthouse’s default config defines seven equally weighted audits. This is the list as of 13.6.0:
| Audit (ID) | Group | What it checks | Shows N/A when |
|---|---|---|---|
Accessibility tree is well-formed (agent-accessibility-tree) |
Agent Accessibility | A subset of axe rules: names, labels, ARIA validity | Rarely |
| Cumulative Layout Shift | Scored directly | Visual stability during the lab load | Rarely |
llms.txt follows recommendations (llms-txt) |
Agent Discoverability | Fetches /llms.txt at the origin root and checks its shape | The server returns a 4xx |
ARD manifest is valid (ard-schema) |
Agent Discoverability | Finds and validates an ARD manifest | No manifest found |
| WebMCP tools registered | WebMCP | Lists declarative and imperative tools (informative) | No WebMCP support |
| WebMCP form coverage | WebMCP | Lists forms with no tool annotations | No forms or no WebMCP support |
| WebMCP schemas are valid | WebMCP | Missing tool names, descriptions and field names | No WebMCP support |
Earlier coverage often counts six audits. The ARD audit arrived in Lighthouse 13.5.0 (September 2026), which also moved llms.txt and ARD into a new “Agent Discoverability” group.
The Accessibility Tree Audit Does Most of the Work
Agents that drive a browser read the page through the accessibility tree, the same structure screen readers use. Chrome’s agent-ready toolkit post (June 2026) calls it the agent’s main data model and adds that “accessibility is for humans first.” A button with no accessible name is just “button” to a screen-reader user and an unlabeled control to an agent. Neither can tell whether it adds to cart or deletes the account.
The agent-accessibility-tree audit reuses Lighthouse’s axe-based accessibility results, filtered to 33 rules that matter for machine interaction, including button-name, link-name, label, select-name, document-title, aria-hidden-focus, aria-required-children, duplicate-id-aria and svg-img-alt. One failing rule fails the whole audit.
What it leaves out matters too. Colour contrast, heading order and ordinary image alt text are not in the subset, so a page can pass the agent check and still fail the Accessibility category. The usual failures are icon-only buttons (cart, search, close, menu) without an aria-label, and inputs that rely on placeholder text instead of a real label. Our web accessibility and SEO guide covers fixes that help people and crawlers alike.
Why CLS Sits in an Agent Audit
An agent identifies an element, works out where it is, then clicks. If a late ad or an unsized image pushes content down in between, the click lands on the wrong thing. Chrome’s scoring page names ads, images without dimensions and injected content as causes of unstable results.
This is the standard Lighthouse CLS audit, so it’s the lab number from the page load, not the field CLS real users generate in the Chrome UX Report. The fix is ordinary Core Web Vitals work: reserve space for images, embeds and ad slots, and stop injecting banners above content after load. Lab CLS can miss shifts that happen later, when an agent scrolls or opens a menu, so a pass is a floor, not a guarantee.
The llms.txt Audit: What It Checks and Three Traps
This is the most misunderstood part of Lighthouse agentic browsing. Lighthouse requests /llms.txt at the root of the final page URL, so auditing a deep page still checks the root file. In the Lighthouse source:
- 4xx response (no file): not applicable. Chrome’s audit page says the file is currently optional, and a missing one drops out of the ratio.
- 5xx or 429 response, or a failed fetch: fail.
- File returned: it needs an H1 line (
# Title), at least one Markdown link and at least 50 characters, or it fails with the reason listed.
That creates three traps most guides miss. First, soft 404s: some CMS setups and single-page apps answer every unknown path with a 200 and the homepage HTML. Lighthouse “finds” an llms.txt with no Markdown H1 or link and fails you for a file you never published. Serve a real file or a proper 404 (our soft 404 guide explains why Google cares too). Second, rate limits: since Lighthouse 13.6.0, a WAF that answers with 429 causes a fail, while a 403 hides the check as N/A. Neither tells you anything about the file. Third, a stub with a title and no links fails, so an empty placeholder is worse than no file.
If you publish one, the free llms.txt generator produces the H1, summary and link list the audit expects. Our llms.txt adoption study found the file on 21% of 1,000 top sites.
The ARD Manifest Audit
Agentic Resource Discovery is a proposed specification for listing the agent-facing resources a domain offers, such as MCP servers, A2A agents and agent skills, in an ard.json manifest. Lighthouse 13.6.0 updated the audit to ARD v0.91. Per Chrome’s ARD audit page, Lighthouse looks for an Agentmap: line in robots.txt, a rel="ard" link tag or Link header, or /.well-known/ard.json, and accepts older ai-catalog locations with a warning.
No manifest means N/A. A valid manifest with best-practice warnings scores 0.9, which still counts as passed. A conformance error, such as entries missing an identifier, displayName or type, or an advertised manifest that won’t load, scores 0. For a content site with no MCP server or agent to list, skip it.
The WebMCP Audits, and Why They Show N/A
WebMCP is a proposed browser standard that lets a site expose actions, like “book a table”, as tools an agent calls directly instead of clicking through the interface (see our WebMCP explainer). Lighthouse reads registrations through the Chrome DevTools Protocol, covering declarative tools (HTML form attributes) and imperative tools (registered in JavaScript).
On a normal Chrome install all three return N/A because the browser doesn’t expose WebMCP. Chrome’s docs say WebMCP audits require the WebMCP origin trial, and the toolkit post tests with Chrome Canary and the enable-webmcp-testing flag. When support is present:
- Registered tools is informative and warns above 40 tools, since extra tools use model context, add latency and raise the risk of the agent picking the wrong one.
- Form coverage lists forms with neither a
toolnamenor atooldescriptionattribute. It nudges rather than fails. - Schema validity can fail: missing tool names, descriptions or field names score 0 for errors and 0.5 for warnings.
Tools registered late in JavaScript can miss the snapshot, so register them early.
How the Pass Ratio Works: A Worked Example
The header shows passed audits over passable audits. N/A results drop out of both numbers, informative audits never count, and anything scoring 0.9 or higher shows as passed. So 3/3 and 7/7 are both perfect, and comparing ratios between sites tells you little.
We ran Lighthouse 13.6.0 from the CLI against the seorocket.ai homepage in headless Chrome 156 with only this category. Result: 3/3. The accessibility tree passed, lab CLS was 0, and llms.txt passed because the file has an H1, Markdown links and more than the 50-character minimum. The three WebMCP audits were N/A (no WebMCP in stock Chrome) and ARD was N/A (we don’t publish agent resources). Four of seven audits never applied, which is normal for a content site. Read which audits ran before you celebrate or panic.
A Fix Order for Agent Readiness
- 1. Label every interactive element. It helps screen-reader users, agents and your Accessibility score at once.
- 2. Fix load-time layout shift. It’s a Core Web Vitals metric anyway.
- 3. Make /llms.txt return a clean result: a valid file or a true 404, never a 200 HTML page or a 429.
- 4. Add WebMCP to key forms only if agents completing bookings, quotes or checkout is a real goal.
- 5. Publish an ARD manifest only when you have an MCP server, agent or skill worth listing.
Lighthouse checks one URL at a time, so an unlabeled header search button can repeat on every page while you only test the homepage. Run the category on one URL per template, and pair it with a site-wide crawl. SEO Rocket’s real-crawler technical audit (Screaming Frog-backed, with JavaScript rendering) finds the 404s, soft-404 candidates, redirect chains and broken links that strand any visitor, human or agent. For the wider checklist, see how to make your website agent-ready.
Then measure the outcome. A perfect ratio doesn’t put you in AI answers. SEO Rocket’s AI Visibility tracking shows whether AI engines mention and cite your brand. That follows a playbook proven across 1,000,000+ ranking pages: fix what helps users first, then adopt the new standards.
Lighthouse Agentic Browsing FAQ
Does the agentic browsing result affect Google rankings?
Nothing from Google says it does. Chrome calls the category experimental and informational. The accessibility and CLS fixes it points to are worth making for users anyway.
Do I need an llms.txt file to pass?
No. A 404 at /llms.txt makes the audit N/A. You only lose it with a malformed file, a server error, a 429, or a soft-404 HTML page at that path.
Why are the WebMCP audits always N/A?
Standard Chrome doesn’t expose WebMCP. You need the origin trial or Chrome Canary with the testing flag, plus pages that register tools or annotate forms.
Which Lighthouse version do I need?
13.3.0 or later for the category, 13.5.0 for the ARD audit and 13.6.0 for ARD v0.91. In DevTools, use Chrome 150 or later and tick the Agentic Browsing checkbox.
