Chrome's agentic browsing audit checks for llms.txt, Google Search ignores it

What the agentic browsing category actually checks

The documentation sits at developer.chrome.com/docs/lighthouse/agentic-browsing/scoring, written here as plain text rather than as a link because this site keeps a registered list of the external hosts it will link to and that host is not on it. The page carries Last updated 2026-05-05 UTC and it sorts the category into three groups: WebMCP Integration, Agent-Centric Accessibility, and Stability and Discoverability. Naming them matters, because the second group is the bulk of the category and it is not new work. It is the accessibility tree, reused.

Three checks sit under Agent-Centric Accessibility and the page describes each in a single clause. Names and labels covers ensuring every interactive element has a programmatic name. Tree integrity covers verifying that roles and parent-child relationships are valid. Visibility covers confirming that content is not hidden from the accessibility tree while being interactive. Anyone who has run the ordinary accessibility category will recognise all three, and the reason they reappear is stated in the companion blog post, A developer toolkit to make your website agent-ready, published on 22 June 2026 by Kasper Kulikowski and Michael Hablich at developer.chrome.com/blog/agent-ready-toolkit: agents rely on the accessibility tree, derived from DOM for assistive technology, as their primary data model. How that tree gets built from markup is not a Chrome invention either. It is specified by the W3C in Accessible Name and Description Computation, a Working Draft dated 29 May 2026.

Stability and Discoverability holds the two checks that are less obviously about accessibility. The first is Cumulative Layout Shift, which web.dev defines as a measure of the largest burst of layout shift scores for every unexpected layout shift during the page lifecycle, with a target of 0.1 or less at the 75th percentile of page loads. The agentic framing is different from the human one: the scoring page says CLS matters here because agents rely on element positioning, so a shifting layout is a misclick rather than an annoyance. The second is the llms.txt check, described as checking for the presence of a machine-readable summary at the domain root.

Notice what the list does not contain. There is no check on whether your prose survives without JavaScript, no check on which crawlers your robots.txt admits, and no check on structured data as an entity signal. That is not an omission on Chrome's part. It is a statement of what this category is for, which is a browser-resident agent operating a page, and it is why a full pass answers a different question from the one this site asks.

Why one Google page checks for llms.txt and another says Search ignores it

The two positions are easy to state because both are written down. The Lighthouse scoring page lists llms.txt as one of the things an agent ready site is checked for. Google's guide to optimizing for generative AI features, carrying Last updated 2026-07-10 UTC when read on 2 August 2026, says under a heading about what you do not need to do that you do not need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search, including its generative AI capabilities, as Google Search itself does not use them. It goes further and says it is completely fine to maintain such files for other services or systems, and that doing so will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them.

Read carefully, those two documents do not contradict each other, and a post claiming they do would be trading a real distinction for a headline. The Search guide is scoped to Google Search and it says so in the sentence. Lighthouse is a developer tool published by the Chrome team, and the category it added is scoped to agents operating in a browser. One organisation, two products, two audiences, and the file is useful to the second in a way the first has explicitly declined.

What is genuinely new is that a Google surface now checks for the file at all. Until this category shipped, the honest summary of llms.txt was that no major vendor had committed to reading it in production, and the evidence for it was thin. That summary was published here, inconveniently, in what the evidence says about llms.txt, while this site was shipping an llms.txt generator, and the position has not changed. A presence check inside a developer audit is still not evidence that any answer engine fetches the file, and it should not be sold as one. It is evidence that one team at Google thinks presence is worth reporting.

The distinction is worth holding because generative engine optimization advice tends to collapse it. A tactic that a documentation page mentions becomes, three blog posts later, a tactic that a search engine rewards. Those are different claims with different evidence behind them, and the only defence against the drift is quoting the sentence and dating the page you read it on.

Every reading in this category is taken inside a browser

One line in the Chrome documentation decides how far these results can be carried: testing the category requires Chrome 150 or later, and WebMCP audits require registering for the WebMCP origin trial. Lighthouse loads the page in Chrome. The accessibility tree the audits read is derived from the DOM, and the DOM is what exists after the browser has parsed the markup and run the scripts. Every check in the category therefore describes the page as it exists at the end of that process.

That is the right measurement for the thing being measured. An in-browser agent really does arrive with a rendering engine, so auditing the rendered result is not a shortcut, it is the target. The problem is only that this is one of two layers, and the other one is where most AI visibility failures actually live. A client that fetches your HTML and does not execute it sees whatever the server returned, and if the prose arrives later, from JavaScript, it never arrives at all. That gap is what prose parity exists to name, and it is the single most common reason a modern site is unreadable to the systems that quote it.

The consumers on that other side of the line are documented, not hypothetical. Common Crawl's July archive was collected by a crawler whose own FAQ states it executes no JavaScript, and it is one of the corpora that ends up in training and retrieval sets. Retrieval clients are no more uniform: a paper logged in seven of nine AI coding agents arriving without a product name recorded most of them identifying as an HTTP library rather than a product, and only two of the fifteen tools it observed drove a JavaScript-evaluating browser at all. None of those clients would ever produce an agentic browsing score, and none of them would be improved by one.

The practical consequence is that a perfect result in this category tells you nothing about whether a crawler received your text. The two can disagree in both directions. A client-rendered React application can render an immaculate accessibility tree, pass the names and labels check, hold layout perfectly still, and still return an empty shell to a fetch without a browser, which is the failure the Next.js rendering guide is written for. A plain server-rendered page can fail on layout shift while being entirely readable to every crawler that asks. If you want the second answer, what GPTBot sees fetches a page the way a crawler would and shows the text that survives, which is a different question asked of a different client.

A fractional score is not a grade, and the documentation says so

The scoring page is unusually careful about what its own number means, and that care is worth reproducing rather than summarising away. Unlike other Lighthouse categories, it states, the agentic browsing category does not have a weighted average score from 0 to 100. What it reports instead is a fractional score, described as a ratio showing how many agentic readiness checks your site passes. The companion blog post of 22 June 2026 puts the same point in one clause: at the time of publication, agentic browsing is informational and unbenchmarked.

Two things follow that anyone quoting this category should carry with the number. The first is that a fraction of checks passed is not comparable across sites in the way a weighted score is, because every check counts once regardless of how much it matters. The second is that part of the category cannot report on most sites at all. WebMCP audits require registering for the WebMCP origin trial, so a site that has not registered is not being told it failed a capability, it is being told nothing about that capability, and a fraction that silently includes or excludes those checks means something different in the two cases.

The scoring page also warns that its results move: while the audits are deterministic, it says, your results may fluctuate due to changes in how your site registers its tools or responds to agentic requests. Deterministic audits with fluctuating results is not a contradiction, it is a precise statement that the instrument is stable and the thing being measured is not, which is a distinction most tooling declines to make about itself.

This site has an obvious reason to approve of that restraint, and it is worth declaring rather than implying. Withholding a confident number when the measurement does not support one is the argument in why we will not grade a page we could not measure, and the weights behind Lantad's own AI visibility score are configured decisions rather than discoveries: structure is set at 15 points of 100 in core/src/config.ts, and the llms.txt presence check inside it carries half the weight of a full sub-check. Nobody measured that llms.txt is worth half a check. Somebody chose it, it is written down in a config file, and the methodology page is where the choice is defended in public rather than hidden inside a total.

What to check before you audit agent readiness

Running the category is cheap and there is no argument against doing it. The argument is about order, because the checks it runs assume a condition it never tests, which is that a machine asking for your page receives your page. Three things sit upstream of that assumption and all three are checkable today.

The first is access, and it is not answered by fetching your own site in a browser. A robots.txt file admits or refuses each crawler by name, and a rule written for one token says nothing about another, which is why the robots.txt tester evaluates a file per crawler rather than in aggregate, and why the AI crawlers tool exists to list the tokens worth writing rules for in the first place. Getting this wrong is quiet: nothing on your site changes, no error appears, and the traffic simply never arrives.

The second is the layer above your own configuration. Your robots.txt is a request that a well behaved client honours, and it is not the thing that actually stops traffic. An edge or CDN rule enforces, and it can refuse a crawler that your file admits without either document mentioning the other, which is the case set out in two layers decide whether AI can read your site. If a managed bot rule is blocking a retrieval crawler, no amount of accessibility tree hygiene will put your page into an answer.

The third is what the response body holds. Fetch your own page without a browser and read what comes back. If the article text is in the response, every downstream question is worth asking. If it is not, the agentic browsing category will still describe a well built page, because it is describing the rendered result, and the client that mattered never got that far. This is the same ordering problem as asking whether you rank before checking that you are indexed, and it is why how to get cited in Google AI Overviews starts with eligibility rather than with content technique.

Then run the audit. An agent that can operate your page is a genuine goal, the accessibility work it rewards is worth doing on its own merits, and the checks are specific enough to act on. Just record what the number is: a fraction of a documented checklist, taken in a browser, published by a team that says plainly it is not benchmarked yet.