Lighthouse — the auditing tool built into Chrome DevTools and used by PageSpeed Insights — added a new category called Agentic Browsing alongside its existing Performance, Accessibility, Best Practices, and SEO scores. It measures something neither of those fully covers: whether an AI agent, not a human or a search crawler, can actually read and operate a page.
What it checks
Running lighthouse --only-categories=agentic-browsing against a URL surfaces six audits:
agent-accessibility-tree— is the page's accessibility tree well-formed? Valid ARIA, correct element nesting, accessible names on every interactive element.cumulative-layout-shift— the same CLS metric from Core Web Vitals, reused directly.llms-txt— does anllms.txtfile exist and follow the basic expected format? 4–6.webmcp-registered-tools,webmcp-form-coverage,webmcp-schema-validity— whether the page registers WebMCP tools and whether they validate. Most sites don't use WebMCP yet, so these three commonly show as not applicable rather than pass or fail.
Lighthouse's own description of the category is worth quoting directly, because it's an accurate self-assessment: "These checks ensure high-quality, browsable websites for AI agents and validate the correctness of WebMCP integrations. This category is still under development and subject to change." It was introduced around Lighthouse 13.3 in mid-2026 (TODO(faizan): verify exact version and ship date).
What it doesn't mean
Like Lighthouse's other categories, Agentic Browsing is a diagnostic audit, not a documented Google Search ranking signal — there's no confirmed claim that this score affects search rankings, and the category's own "still under development" language is a reasonable signal to treat it as directional rather than authoritative for now. It's also worth being direct about one specific audit inside it: llms-txt checks whether the file exists and is well-formed, not whether any AI engine actually uses it to decide what to cite. Google's own general guidance has been that site owners don't need special files for AI Search. Treat llms.txt as low-cost and forward-looking, not load-bearing.
What's actually worth fixing
The accessibility-tree audit is the one that matters most, and it's also the one most sites will fail without knowing it — because the failure mode isn't visual. We found this out first-hand building this site: an FAQ accordion rendered <dl><details><dt>…</dt>…<dd>…</dd></details></dl>. It looked correct in a browser. It scored 0 on agent-accessibility-tree, because <dl> only permits <dt>/<dd> groups, <div>, <script>, or <template> as direct children — <details> isn't one of them. The same bug also failed two ordinary Accessibility-category audits (definition-list, dlitem), which is the pattern worth internalizing: Agentic Browsing and Accessibility both walk the same underlying accessibility tree, so a structural HTML bug tends to fail both at once. Fixing accessibility issues you'd want to fix anyway is most of the work here — there isn't a separate "AI agent" version of good HTML.
CLS is the same metric you'd already be optimizing for Core Web Vitals; nothing agent-specific to do beyond that. llms.txt takes minutes to add and costs little, so there's no reason to skip it — just don't expect it to substitute for the harder work.
WebMCP is the newest and least mature piece here. If your site doesn't expose any user actions worth an AI agent calling directly — most content and marketing sites don't — those three audits aren't worth chasing yet.
Check your own site
Run a free scan to see how your site does on the checks this affects most directly — crawler access, content readability, and structured data, alongside an agentic-readiness check built on the same accessible-name and landmark signals Lighthouse's audit looks at. Or see this site's own live score, including the bug described above.