Chrome’s Lighthouse Can Now Audit Your Site for AI Agents. It Isn’t a Ranking Signal, and It Still Matters.

I remember the first time a client forwarded me a Lighthouse performance score and asked whether it mattered. My honest answer at the time was “to your developer, mostly.” A few years later, Google announced in May 2020 that Core Web Vitals would become part of a page experience ranking signal, and the rollout began June 15, 2021. Metrics that had lived for years in a developer tool walked straight into the ranking conversation, and I spent the first stretch of that era catching up on something I’d filed under somebody else’s job.

So when I opened DevTools this year and found a fifth category sitting beside Performance, Accessibility, Best Practices and SEO, I paid attention. It’s called Agentic Browsing, and every instinct I built during the Core Web Vitals years says this is how it starts.

Here’s what I’ve learned after a few weeks with the audits, the documentation, the bug tracker and the specification behind the newest check. The Core Web Vitals pattern is much weaker this time. The category is not a ranking signal, and nothing Google has published suggests it is headed there. And it is still one of the most useful things Google has shipped about where the web is going. Those three statements fit together once you’re precise about what Lighthouse is telling you.

What Shipped, With Version Numbers

Lighthouse 13.3, released May 7, 2026, added Agentic Browsing to Lighthouse’s default configuration. Chrome’s own documentation says testing the category requires Chrome 150 or later, and describes both the category and its WebMCP support as experimental and based on proposed standards. The category is available in current stable Chrome, but its DevTools checkbox is disabled by default. Early coverage telling people to install Chrome Canary to see it is out of date.

The checks fall into three groups. The first validates WebMCP integration, a proposed web API incubated by the W3C Web Machine Learning Community Group and implemented experimentally through a Chrome 149 origin trial. It lets sites expose JavaScript functions and HTML forms as tools that in-browser agents can call. The second group runs a filtered subset of accessibility audits aimed at agents, covering names and labels, tree integrity and visibility. The third, which Chrome calls stability and discoverability, measures cumulative layout shift and checks for an llms.txt file at the domain root.

Running it takes no special setup, but the category is not selected automatically. Open DevTools, choose the Lighthouse tab, select Agentic Browsing, and generate the report.

The Missing Score Is the Most Honest Thing in the Report

Every other Lighthouse category gives you a weighted number from 0 to 100. Agentic Browsing gives you a pass ratio, a fraction showing how many readiness checks your site passed. Chrome’s documentation explains the choice directly: because the standards for the agentic web are still emerging, the category is meant to collect data and offer practical signals rather than a definitive ranking.

I’d encourage every practitioner to sit with that sentence before reacting to anything else in the category. A weighted score means somebody decided how much each check matters. I read the absence of one as Google declining to make that decision in public. When the people who built the instrument say the standards are still emerging, the right response is to believe them and to be skeptical of anyone who shows up next quarter selling you an “agent readiness score.”

The Audit That Landed While Everyone Argued About llms.txt

Most coverage of the category stopped at llms.txt, because llms.txt is the argument the SEO world already wanted to have. The more interesting change arrived on September 18, when Lighthouse 13.5 shipped a new Agent Resource Discovery audit and regrouped the llms.txt and ARD audits together under “agent discovery”. Chrome’s engineers filed those two files in the same drawer, and that grouping tells you more about how Chrome thinks about llms.txt than any statement from Search Relations has.

ARD needs an introduction, because most marketers haven’t met it. It’s a draft open specification for how AI agents find tools and services across the web. An organization publishes a catalog at a well-known path on its own domain listing the tools, MCP servers, agents or APIs it offers; registries crawl those catalogs; and agents search by intent rather than relying on integrations someone installed in advance. The original v0.9 draft was dated May 28, 2026, and the specification was authored by Junjie Bu of Google, R.V. Guha of Microsoft and Shaun Smith of Hugging Face under an Apache 2.0 license. A coalition including Google, Microsoft and GitHub announced it on June 17 alongside reference implementations, building on a data model maintained by a Linux Foundation working group.

That author list deserves a second look from anyone who works in structured data. R.V. Guha initiated Schema.org and co-edited the Meta Content Framework, a precursor to RDF, before joining Microsoft. When someone behind the vocabulary in your JSON-LD co-authors a discovery specification, it earns a careful read on principle. It also fits a thread I’ve been pulling for a while on, since ARD uses the same well-known URI pattern, now with Google and Microsoft names attached.

Lighthouse 13.5 still looks for the predecessor AI Catalog pointer and falls back to the old filename. Here is the kind of detail that only shows up when you read the implementations side by side. ARD v0.91 moved discovery to the current filename and link relation on August 26, three weeks before Lighthouse 13.5 shipped. Lighthouse also validates against a bundled port of the earlier AI Catalog schema rather than fully implementing the current v0.91 manifest definition. As Lighthouse issue #17251 documents, a current manifest can conform to ARD and still be missed or failed by the audit. That’s what early standards look like up close: the tooling and the specification are moving on separate clocks.

On availability, PageSpeed Insights is now running Lighthouse 13.5, while Chrome DevTools is expected to bundle that release with Chrome 156. Until Chrome 156 reaches stable, PageSpeed Insights or the Lighthouse 13.5 command-line tool are the practical ways to see the ARD check.

Adoption Is Still Sparse

An early API Evangelist profile of ARD adoption probed the predecessor filename across 43,834 domains, reached 37,751 of them, and found nine publishers. None was fully conformant, and four passed the project’s own conformance tool. As of October 16, 2026, a later independent crawler reported manifests on roughly 0.1% of about 376,000 checked hosts. The corpora and methods are not directly comparable, but both measurements show that adoption remains sparse.

ARD adoption has moved beyond single digits, but it still sits near one-tenth of one percent in a much broader independent crawl.

I keep landing on two readings of those measurements. One says this is an early signal of where agent discovery is heading, with developer-tool companies and infrastructure providers moving first. The other says ARD has a tooling constituency but only a thin adoption constituency, which describes plenty of specifications that never became mainstream. I don’t know which reading is right, and neither does anyone else. What I do know is that “Chrome checks for it” and “the web uses it” are separate facts, and this is the clearest case I’ve seen of the gap between them.

Where the Core Web Vitals Pattern Breaks

The case for treating Agentic Browsing as the next Core Web Vitals is straightforward. Lighthouse has historically been where Google’s measurement intentions surface first, and Core Web Vitals followed exactly that path from audit panel to announced ranking signal.

The case against it is stronger, and it rests on three differences. Core Web Vitals measured user experience that Google could evaluate from real-world usage data across the whole web, while most of these audits check for files and proposed interfaces with limited adoption. Core Web Vitals arrived with scored metrics and a published timeline, with roughly a year between the 2020 announcement and the 2021 rollout, and Agentic Browsing deliberately has neither. And nothing ties the category to Search. Google’s own Search documentation says no special AI files or markup are required and that Google Search does not use llms.txt. Chrome’s scoring documentation doesn’t mention Search at all.

So the honest verdict is that the pattern suggests direction without predicting rankings. If someone tells you agentic readiness is about to become a ranking factor, ask them for the announcement, because Google hasn’t made one.

A Correction I Owe You

I’ve pointed to Chrome’s llms.txt check before as evidence of Google’s do-versus-say split on the file. The tension is real. Google Search Central’s AI optimization guidance says you don’t need new machine-readable files, AI text files or special markup to appear in Google’s AI search features, and that Google Search does not use llms.txt. Chrome nevertheless shipped an optional Lighthouse check for the file.

My reading of that check was too generous, though. A missing file is marked Not Applicable, not passed. And the Lighthouse 13.5 implementation shows that a present file can fail if it lacks an H1, contains no Markdown link, is under 50 characters, returns a server error or cannot be fetched within the audit’s timeout. The check tells you Chrome’s engineers think the file is worth validating. It does not tell you Google’s ranking systems consume it, and I made that distinction less clearly than I should have.

The broader lesson holds for the whole category. Watching what Google builds tells you what its engineers are preparing for. It tells you nothing about what its ranking systems use. Both are worth knowing, and confusing the two is how practitioners end up selling roadmaps as results.

The Bugs You Will Hit This Week

This is the section nobody else seems to have written, and it will save you an afternoon.

In June, a developer filed a Lighthouse issue after the audit reported “Fetch of llms.txt failed” on a file the site’s server logs showed being fetched successfully. Lighthouse maintainers reproduced the problem and found that the request took 2.342 seconds, exceeding the audit’s two-second fetch timeout. The linked fix added clearer failure details; it did not change the timeout or the pass criteria.

The practical habits follow from that. Run the category in current stable Chrome for the original checks, and use PageSpeed Insights or Lighthouse 13.5 for the ARD audit until that release reaches stable DevTools. If llms.txt fails, confirm that it returns a 200, includes an H1 and at least one Markdown link, contains more than 50 characters and completes within two seconds. If you use LLMS Amplifier, the same rule applies to the files it generates, so check both the content and response time before changing any configuration. And if you publish a current ARD manifest, remember that Lighthouse may miss it because the tool still uses the predecessor discovery path and schema.

What to Do With This Right Now

The agent-centric accessibility audit is the only one I’d call unambiguously worth fixing today. Clean names, labels and tree structure help people using assistive technology and machines parsing your page in the same stroke, whatever happens to any agent standard. It’s the same argument I make in the accessibility layer of my AI-friendly website checklist, and Chrome has now built that argument into a tool.

Layout shift is already on your list if you lived through Core Web Vitals. llms.txt sits where it sat before, cheap and worthwhile if you keep it accurate and not worth publishing if you won’t maintain it, and the audit won’t penalize you for leaving it out.

WebMCP and ARD are watch-and-learn items for most sites. They become build items if your business exposes tools, APIs or agents that other software should be able to call, which is a smaller audience than the coverage implies. When I scope agentic readiness work for clients, I’ve started mapping it to the same groups Chrome uses (discovery, agent accessibility, stability and action), because those groups are a reasonable outline of what machines need from a site even before anyone scores them.

A Roadmap, Not a Scorecard

The Agentic Browsing category is worthless as a ranking lever right now, and valuable as intelligence. It’s a published list of what Chrome’s engineers believe the agentic web will require, written by people with a much clearer view of what’s being built than any of us have from outside. I read it the way I read a product roadmap. It tells me where to learn, where to experiment, and where to hold my money.

A Lighthouse audit tells you what Chrome’s engineers expect the agentic web to require. It says nothing about what Google’s ranking systems use.

There are a few things I’m watching. Whether Lighthouse 13.5 reaches stable DevTools. Whether the audit updates its predecessor discovery path and schema to match current ARD. Whether the category ever gains a weighted score, which would be the first real sign Google thinks the standards have settled. And whether adoption moves materially above roughly 0.1%. If you’re running these audits on real client sites and hitting results that don’t match the documentation, I’d like to hear about it. The tooling is getting less independent testing than it needs, and the practitioners comparing notes now are the ones writing the playbook everyone else buys later.

Written by Brian Winum

Digital marketing veteran, partner at MAXBURST and MAXPlaces, and creator of LLMS Amplifier and Authority Amplifier.

About Brian Work with me