Lighthouse Agentic Browsing vs Agent Ready

At a glance

Lighthouse column verified on 2026-08-06 against the audit source in agentic-browsing-config.js rather than the documentation, which is thinner than the implementation. The category is experimental and iterating — re-check the source for its current audit list.

What is Lighthouse’s Agentic Browsing category?

It is a Lighthouse category Google shipped in Chrome M150, announced on 22 June 2026 alongside Chrome DevTools for Agents. It runs six deterministic audits, grouped into WebMCP and Agent Accessibility:

• agent-accessibility-tree — filters 33 accessibility rules that matter for machine interaction: button and link names, form labels, and the ARIA attributes that decide whether the tree is well-formed.
• webmcp-registered-tools — lists the WebMCP tools registered at analysis time, both declarative and imperative. Informational.
• webmcp-form-coverage — flags forms with no declarative WebMCP annotation. Informational.
• webmcp-schema-validity — validates tool and parameter names and descriptions on annotated forms.
• cumulative-layout-shift — the Core Web Vitals metric, reused here because elements that move between the moment an agent locates them and the moment it clicks cause misclicks.
• llms-txt — fetches /llms.txt and checks it has an H1, contains at least one Markdown link, and runs to at least 50 characters.

Every audit carries equal weight, and the category deliberately has no 0–100 score. Google’s scoring documentation explains why: “the current focus is to gather data and provide actionable signals rather than a definitive ranking.” You get a pass fraction instead. Running it needs Chrome 150 or later, and the three WebMCP audits need the WebMCP origin trial — without it they report not-applicable rather than running.

What is Agent Ready?

Agent Ready is an independent agent-readability scanner. It fetches a site and runs 70 checks across four families: 15 site-wide files (llms.txt, robots.txt, sitemap.xml, sitemap.md, AGENTS.md), 23 per-page conditions from the Vercel Agent Readability Spec, 10 structural llms.txt checks against llmstxt.org, and 22 agent-protocol manifest checks. On top of that it runs a separate 23-check WCAG 2.2 and layout-stability suite, reported as its own accessibility sub-score rather than folded into the headline number. Every check maps to a numbered entry in a published methodology and returns a deterministic plain-English fix. It runs from the web, a REST API, a CLI, an MCP server, an SDK, or a browser extension.

How do the two differ?

They audit different layers, and the split is cleaner than in most tool comparisons:

• Lighthouse audits the interaction layer. It drives a real browser, so it can answer questions that only exist at runtime: does the layout hold still, is the rendered accessibility tree well-formed, which WebMCP tools actually registered.
• Agent Ready audits the discovery layer. It asks whether an agent can find your site, identify your capabilities, and read your content without rendering: llms.txt, AGENTS.md, markdown mirrors, content negotiation, and the manifests that advertise your MCP server, agent card, or payment endpoint.
• The overlap is one signal. Both check llms.txt, and they treat it differently — see below. Both also touch accessibility, but Lighthouse reads the rendered tree while Agent Ready reads static HTML.
• The score models diverge on purpose. Lighthouse reports a fraction because the standards are still emerging. Agent Ready reports 0–100 and labels each spec as ratified, pre-standard, or behavioural, so a draft protocol is never presented as settled.

How do they treat llms.txt differently?

This is the one place the tools measure the same file, and the difference is worth knowing before you read either result.

Lighthouse’s llms-txt audit treats any 4xx response as not-applicable and scores it 1. A site that has never published an llms.txt therefore passes that audit. Only a file that exists and breaks one of three rules — no H1, no Markdown link, or under 50 characters — fails.

Agent Ready scores adoption as well as conformance. A missing file fails S1, and the 10-check llms.txt sub-score weights the structural checks (file accessible, H1 present, valid Markdown) at 3× the content checks. Neither approach is wrong — Lighthouse asks “is this file well-formed?”, Agent Ready asks “does this site have a well-formed one?” — but a green Lighthouse row is not evidence that an llms.txt exists.

What does Lighthouse cover that Agent Ready doesn’t?

Three things, all of them consequences of driving a real browser — and all of them genuinely out of reach for a fetch-based scanner:

• Runtime WebMCP tool registration. Tools registered by JavaScript through the imperative API only exist once the page runs. Agent Ready defers WebMCP entirely.
• Cumulative Layout Shift. Real layout movement, measured over a real page load. Agent Ready checks static signals that correlate with it, such as whether media declares explicit dimensions, but cannot measure the metric itself.
• The rendered accessibility tree. Lighthouse evaluates the tree the browser actually built, after scripts have run. Agent Ready parses static HTML, so it misses anything a client-side framework injects.

This is the interaction layer, and it is the part of agent-readiness that fetch-based scanners — ours included — do not score, because it is only observable when something actually drives the page. If your site is a client-rendered application whose critical flows are forms and multi-step interactions, Lighthouse is looking at the part that matters most for you.

What does Agent Ready cover that Lighthouse doesn’t?

Most of the discovery layer. Lighthouse’s category audits one rendered page; a large share of agent-readability lives in files an agent fetches before it ever loads your HTML:

• Agent-protocol manifests. MCP server cards (SEP-2127), A2A agent cards, agents.json, agent-permissions.json, UCP, NLWeb, API Catalog, Web Bot Auth, Agent Skills Discovery, and A2UI. WebMCP is the only protocol Lighthouse’s category covers.
• Payment rails. x402, MPP, AP2, and ACP — whether your site can quote a price and take payment from an autonomous agent.
• Site-wide files. robots.txt AI-crawler rules, sitemap.xml, sitemap.md, AGENTS.md, and a root OpenAPI spec.
• Markdown mirrors and content negotiation. Whether /page.md exists, carries frontmatter and a canonical Link header, and whether the HTML route honours Accept: text/markdown.
• Cross-page and cross-manifest integrity. Content parity between what a browser and a bot are served (cloaking), and whether the endpoints your manifests advertise are actually reachable.

Lighthouse audits a page. Agent Ready audits a site, up to 25 pages on the free tier and 250 on Pro.

Should you use both?

Yes — that is the honest recommendation, and there is little redundancy in doing so. Run Lighthouse’s Agentic Browsing category on the flows you most want an agent to complete: the booking form, the checkout, the search box. It will tell you whether an agent can operate them, and it slots into CI as a Lighthouse category you may already be running. Run Agent Ready on the site to cover the discovery layer — whether an agent can find you, read your content without executing JavaScript, and identify what you can do for it. The two results barely overlap, so fixing the union of what they flag is close to a complete picture. One caveat: Lighthouse’s category is experimental and behind an origin trial, so treat its output as a signal to act on rather than a number to track over time.

Frequently asked questions

What is Lighthouse's Agentic Browsing category?

It's a category Google added to Lighthouse in Chrome M150, announced on 22 June 2026. It runs six deterministic audits that check whether an AI agent can operate your page: one on the accessibility tree, three on WebMCP (registered tools, form coverage, schema validity), one on Cumulative Layout Shift, and one on llms.txt. Unlike Performance or SEO, it deliberately has no 0–100 score — it reports a pass fraction, because Google says the aim is to gather data and give actionable signals rather than a definitive ranking.

Does Lighthouse replace Agent Ready?

No, and the reverse isn't true either — the two barely overlap. Lighthouse drives a real browser, so it can see things a fetch cannot: layout shift, the rendered accessibility tree, and WebMCP tools registered at runtime by JavaScript. Agent Ready fetches your site and checks the discovery layer: llms.txt, AGENTS.md, sitemap.md, markdown mirrors, content negotiation, and the agent-protocol manifests. The only signal both check is llms.txt. Run both.

Why does a site with no llms.txt still pass Lighthouse's llms.txt audit?

By design. Lighthouse's audit treats any 4xx response as not-applicable and scores it 1, so a site that has never published an llms.txt is not penalised; only a file that exists and is malformed fails. Lighthouse is measuring conformance — is this file well-formed? Agent Ready measures adoption and conformance, so a missing llms.txt fails S1 and the llms.txt sub-score reflects it. Both are reasonable; they answer different questions.

Do I need Chrome 150 to run the Agentic Browsing audits?

Yes. The category requires Chrome 150 or later, and the three WebMCP audits additionally require registering for the WebMCP origin trial — without it they report as not-applicable rather than running. Agent Ready has no browser requirement: it's a server-side fetch, so it runs the same from the web, a CLI, CI, or an MCP tool call.

Which agent protocols does each tool check?

WebMCP is the only agent protocol Lighthouse's category covers, across three of its six audits. Agent Ready checks 22 protocol conditions spanning MCP server cards (SEP-2127), A2A agent cards, agents.json, agent-permissions.json, UCP, NLWeb, API Catalog, Web Bot Auth, Agent Skills Discovery, A2UI, and the payment protocols x402, MPP, AP2, and ACP — but not WebMCP, which it defers. Neither tool is a superset of the other.