If you’ve run Lighthouse or PageSpeed Insights on your store recently, you’ve probably noticed a new category sitting next to Performance and SEO: Agentic Browsing. It’s not experimental anymore, it’s not opt-in, and one of its checks disagrees with Google’s own Search guidance about the file it’s testing.

What shipped, and when

Lighthouse 13.3.0, released 2026-05-07, promoted Agentic Browsing from an experimental flag into the default configuration — it now runs automatically in the Lighthouse CLI and PageSpeed Insights, and, on Chrome 150+, in the DevTools Lighthouse panel with no flag required.

The category bundles six checks across three groups:

  • llms-txt — presence and validity of an llms.txt file
  • WebMCP integration — webmcp-registered-tools, webmcp-form-coverage, webmcp-schema-validity (whether the page exposes callable tools to an in-browser agent instead of just a DOM to scrape — the same WebMCP spec this research log has covered before)
  • agent-accessibility-tree — whether an agent reading the accessibility tree can actually identify page elements
  • Cumulative Layout Shift, reused from Core Web Vitals, as a stability-for-agents signal

Unlike Lighthouse’s usual 0–100 weighted score, Agentic Browsing reports a fractional pass ratio (e.g. “4 of 6 passed”). Google’s stated reason: agentic- web standards are still too immature to collapse into one number.

The llms.txt check has real, specific requirements

The llms-txt audit isn’t a simple file-exists check. To pass, your /llms.txt needs, per Chrome’s own documentation (developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt):

  • An H1 header
  • More than 50 characters of content
  • At least one Markdown-formatted link — [text](url) — not a plain-text URL

That last requirement has tripped up real sites. A plain https://example.com/products sitting on its own line, with no Markdown link syntax, fails the audit even in an otherwise spec-compliant file.

Two open bugs on the googlechrome/lighthouse GitHub repo show the sharp edges here. Issue #17051 reported that llms.txt files generated by the popular Yoast WordPress plugin start with a UTF-8 byte-order mark (BOM), which made Lighthouse fail to recognize the H1 header entirely — merged fix PR #17057 landed 2026-06-05, so sites scanned before that may have false-failed. [Issue

17082](https://github.com/googlechrome/lighthouse/issues/17082) is still

open: a validator-clean, 882-link llms.txt file — with server logs confirming Google fetched it successfully — still returned “Fetch of llms.txt failed,” traced to PageSpeed Insights running the audit on a headless Chrome build (146) below the documented Chrome 150 minimum instead of marking it “Not Applicable.”

If your llms.txt fails this check, verify manually before rewriting anything: confirm every link is real Markdown syntax first, then confirm what Chrome version actually ran the audit.

Google’s own products disagree with each other

Here’s the part worth knowing before you spend engineering time chasing this score: Google Search Central’s generative-AI guidance states plainly that Search, AI Overviews and AI Mode ignore llms.txt entirely. Google’s current wording is that maintaining one “won’t harm (nor help) your visibility or rankings in Google Search, as Google Search ignores them” — guidance the company added specifically to address community questions about whether these files matter for ranking.

So the same company runs two products that disagree: Chrome’s Lighthouse scores you on having a well-formed llms.txt; Google Search’s own ranking systems don’t read it at all. Multiple outlets covering the discrepancy frame it as two separate Google teams — Search ranking versus Chrome/DevTools agent tooling — building independently rather than a policy reversal.

That split is a useful line to keep straight with anyone on your team who asks “do we need this for SEO”: no, it won’t move your Google ranking. But it now gets scored, visibly, inside a tool your engineers already run constantly, and other agent surfaces — not Google Search — are exactly what llms.txt was written for in the first place.

Why this matters more than “one more Lighthouse category”

Lighthouse runs in CI pipelines, PageSpeed Insights reports, and DevTools panels across most web teams already. A default-on category means an imperfect Agentic Browsing score is now something a developer or client will see without anyone going looking for it — similar to how Cloudflare’s free Agent Readiness scanner put a number in front of prospects before they ever talked to an auditor, except Lighthouse doesn’t even require a visit to a URL — it’s already running.

Get the mechanical parts right — valid Markdown links, no stray BOM, checked against a current Chrome build — but remember a passing llms.txt check is a floor, not proof an agent can browse and buy on your store. That gap between “the discovery file parses” and “the transaction works” is exactly what AgentReady’s scan is built to catch.

Sources