What Chrome's Lighthouse llms.txt audit actually checks
Chrome added an llms.txt check to Lighthouse. Its documentation explains the server-error case, while the open-source implementation reveals three additional content checks.
Last updated:
What the audit does
Lighthouse, the auditing tool built into Chrome DevTools and available as a CLI, now includes an llms.txt check inside its agentic browsing audits. The Chrome documentation for it, last updated 2026-05-05, describes the file as “an emerging convention used to provide a machine-readable summary of a website’s content, specifically designed for LLMs and AI agents”, and gives one rationale: “Without this file, agents may spend more time crawling the site to understand its high-level structure and primary content.”
That is a crawl-efficiency argument for agents, not a visibility or ranking argument. It is consistent with what we document on llms.txt and SEO and on whether Google uses llms.txt: nothing here claims a search benefit.
The open-source audit implementation adds detail that the short documentation page omits. When the request succeeds, Lighthouse checks that the body is at least 50 characters long, contains an H1 heading and contains a Markdown link. These are useful smoke tests, not a full implementation of the llms.txt v2 grammar.
Not Applicable is not a failure
This part is often misreported. The documentation says a server error is flagged, while a missing file is marked Not Applicable because the convention remains optional. The implementation generalises the missing-file case to any 4xx response.
- Any 4xx response: Not Applicable. The audit does not score the site on the file.
- A 5xx response or a fetch failure: failure.
- A successful response: the body must be at least 50 characters long and include both an H1 and a Markdown link.
So Lighthouse does not penalise a site for having no llms.txt. If a file is served successfully, however, the audit does say something about its minimum content.
If you serve the file through a function or a rewrite rather than as a static asset, a server or fetch error remains a real failure mode. Our per-stack guides cover serving it as a plain static file wherever possible, and the validator performs a more complete structural analysis.
How often it actually runs
Ahrefs classified every user agent hitting /llms.txt across 137,210 domains in May 2026. Chrome’s Lighthouse audit accounted for 22 requests, roughly 1 in 1,000 of all fetches they measured.
For scale, in the same dataset SEO audit tools as a category made 21.7% of requests, general web crawlers 13.1%, and all named AI bots combined 19.5%. The audit that reignited the debate is a rounding error in the traffic.
That is not an argument that the audit is unimportant. It is an argument against treating its existence as evidence that anything is now reading these files at scale. It is a check in a developer tool, run when a developer runs it.
What to do with this
Three things, none of them urgent.
Do not publish an llms.txt because Lighthouse “requires” it. It does not, and the documentation says so. Publish it if the reasons in benefits and limitations apply to you.
Do check the status and the body. A published file should return successfully, include an H1 and useful Markdown links, and be long enough to carry meaningful content.
Do validate full v2 conformance separately. Lighthouse does not check path scoping, the preamble grammar, section structure, discovery relations or link health. That is the wider gap our validator and deployment checks cover.