Agentic Browsing readiness & llms.txt

A practical guide · Updated June 3, 2026

Lighthouse added an experimental category called Agentic Browsing that evaluates how well a page is built for machine interaction — not just for human readers and search crawlers, but for AI agents that read structure, interact with elements, and find machine-readable hints. If you publish an llms.txt file, this is the context it now lives in.

This guide explains what the audit actually checks, what it does not mean for SEO, and a concrete checklist to get your site agent-ready.

First, the honest caveats

The Agentic Browsing category and WebMCP support are experimental and based on proposed standards. Two things matter before you act on it:

• It is not a Google Search ranking factor. It produces actionable signals about agent readiness, not a position in search results. Don't read it as “llms.txt now affects rankings.”
• There is no 0–100 score. Because the standards are still emerging, Lighthouse shows a fractional pass ratio, Pass/Fail statuses for specific audits, and informational counts — not a weighted grade.

What the audit checks

The category groups deterministic audits into three areas:

1. WebMCP integration

Lighthouse monitors tool-registration events to verify both declarative tools (defined in HTML) and imperative tools (defined in JavaScript). The related audits cover registered WebMCP tools, forms missing declarative WebMCP, and WebMCP schema validity. WebMCP is how a site explicitly exposes its logic and forms to agents so they can act, not just read.

2. Agent-centric accessibility

Agents rely on the accessibility tree as their primary model of the page. Lighthouse checks a subset of accessibility audits that are critical for machine interaction: names and labels (every interactive element has a programmatic name), tree integrity (valid roles and parent-child relationships), and visibility (interactive content isn't hidden from the a11y tree).

3. Stability & discoverability

Cumulative Layout Shift (CLS) measures visual stability — important because an agent may identify an element, then try to interact after it has moved. llms.txt checks for a machine-readable summary at the domain root.

Where llms.txt fits

The llms.txt audit checks for a machine-readable summary at /llms.txt. An important detail: if the file is missing (a 404), the audit is marked Not Applicable, not Failed — providing it is optional today. A server error while fetching it is flagged. So a valid llms.txt that returns 200 is a discoverability win, and its absence won't fail you.

You can build a spec-compliant file with our llms.txt generator (grounded in your real sitemap) and confirm it with the llms.txt checker before publishing.

Why results can fluctuate

The audits are deterministic, but your results can move between runs because of the timing of dynamic (JavaScript) tool registration, changes in DOM size that reshape the accessibility tree, and layout shifts from ads, undimensioned images, or injected content.

An agent-readiness checklist

1. Publish a valid llms.txt. Add /llms.txt at your root and validate it against the spec.
2. Keep the accessibility tree sound. Use semantic HTML and proper ARIA; give every interactive element a programmatic name; don't hide interactive content from the a11y tree.
3. Reduce layout shift. Set dimensions on images and embeds, reserve space for dynamic content, and avoid injecting elements above existing content.
4. Consider WebMCP. Expose key actions and forms to agents declaratively in HTML (or imperatively in JS) so they can act, not just read.

How to test your page

1. Open the page in Chrome Canary.
2. Right-click and choose Inspect.
3. Go to the Lighthouse tab.
4. Enable the Agentic Browsing category.
5. Run the audit and review the Pass/Fail and informational signals.

Frequently asked questions

Sources

• Chrome for Developers — Lighthouse Agentic Browsing scoring
• Chrome for Developers — llms.txt audit
• Search Engine Journal — Google Search vs Lighthouse guidance on llms.txt