Does Lighthouse fail my site if I do not publish an llms.txt file?

No. The Lighthouse documentation states that if the file is not provided by the server and the response is a 404, the audit is marked Not Applicable, because publishing the file is optional. Only a server error while retrieving /llms.txt flags the page. So a missing file costs you nothing in this report, and a green result is not evidence that you have one — check the audit's status rather than the category's pass ratio.

Does a passing llms.txt audit mean AI engines will read my file?

No. The audit is a presence and delivery probe: it verifies that a request to /llms.txt does not produce a server error. It does not grade the file's headings, summary, link targets, size or accuracy, and no Lighthouse audit can tell you whether ChatGPT, Claude, Perplexity or Gemini actually fetched it. Treat the audit as a uptime check on one URL, then validate the contents separately and read your server logs for real fetches.

Does Lighthouse check whether the links inside my llms.txt work?

There is nothing in the published audit description that crawls the file's contents. The documented behaviour covers only the fetch of /llms.txt itself, so a file whose links all point at a retired staging host, a renamed docs path or a dev environment still passes. In an October 30, 2026 audit of recruiting sites we found exactly that defect — 1,928 links in one file aimed at a Pantheon development host — and Lighthouse would have reported it as delivered.

GEO · October 2026

Lighthouse's llms.txt Audit: What It Checks and What It Cannot See

An llms.txt file now appears in a browser vendor's own audit suite, which is the strongest signal yet that the format survived its hype cycle. But the check is narrower than the category name suggests: it confirms that one URL answers without a server error, and says nothing about whether the file is worth reading.

Lighthouse Has a New Category, and It Has No Score

Chrome's Lighthouse ships an Agentic Browsing category, documented as a set of deterministic audits that evaluate how well a site is built for machine interaction. It is scored differently from the categories you are used to: there is no weighted 0–100 number, because Google's stated reason is that agentic web standards are still emerging and the goal is data collection rather than a ranking. Instead the report shows a fractional pass ratio, per-audit pass or fail status, and informational counts in the category header.

That design choice is worth sitting with. Performance and accessibility audits convert dozens of measurements into a single score you can regress in CI. Agentic Browsing gives you a ratio of checks passed — useful, but only if you read which checks ran.

The llms.txt Audit Is a Delivery Probe, Not a Content Review

The published description of the audit is brief. Lighthouse flags a page if a server error occurs when it attempts to retrieve the llms.txt file. If the file is not served and the response is a 404, the audit is marked Not Applicable, because publishing the file is optional. Nothing in that description covers headings, the summary blockquote, link validity, encoding, byte size or whether the links resolve.

Two consequences follow. A missing file is invisible in the report — five hostnames in the probe below return 404 and would pass as N/A. And a 200 response passes, even if what arrives behind that 200 is the wrong document entirely.

What 29 Hostnames Answer Today

On October 31, 2026 we requested /llms.txt from 29 hostnames that publish developer documentation or market developer tools, following redirects.

Response	Count	Lighthouse verdict
`200` with `text/plain` or `text/markdown`	23	pass
`200` with `text/html`	1	pass — and it should not
`404`	5	N/A
`5xx` or a broken connection	0	flag

The single HTML answer is deno.com: status 200, content type text/html; charset=utf-8, 58,366 bytes of application shell where a Markdown index should be. An agent that trusts the content type appends HTML to its context and pays for markup it cannot use; an agent that ignores content type and parses for lines starting with a hash finds a document with none. The audit cannot distinguish that from a well-formed file, because the status line is the only thing it reads.

The opposite failure is size. ai-sdk.dev returns 5,011,503 bytes of text/markdown — a legitimate Markdown document, and roughly 1.25 million tokens at four bytes per token, which is more than most context windows can hold. It passes. Both files fail the same requirement and neither failure is visible in a green report. The practical limits are covered in the llms.txt size limit.

What Else the Category Grades

The llms.txt check is one strand of a category that otherwise grades interaction, not reading. The documented audits cluster into three groups.

WebMCP tool registration. Lighthouse calls the Chrome DevTools Protocol WebMCP domain and monitors registration events, verifying both declarative tools defined in HTML and imperative tools defined in JavaScript.
Agent-centric accessibility. Agents read the accessibility tree, so a filtered subset of existing a11y audits is graded: programmatic names and labels on interactive elements, valid roles and parent-child relationships, and content that is not interactive while hidden from the tree.
Stability and discoverability. Cumulative Layout Shift, because an agent that locates an element and then clicks it loses the element if the page reflows in between, plus the llms.txt presence check.

If your goal is a green agentic report, the llms.txt item is the cheapest one you will ever earn. The WebMCP and accessibility items are where the work is.

Why a Green Run Can Flip Without a Code Change

The audits are deterministic, but the docs list three sources of variance that matter when you gate a deploy on the result. Dynamic tool registration through the imperative API means the timing of registration decides whether a tool is captured in the snapshot. Large or complex DOM changes the shape of the accessibility tree, which is the primary data model for agent navigation. And layout shift driven by ads, unsized images or injected content moves elements between the moment an agent identifies them and the moment it interacts.

In practice that means an unchanged page can report a different ratio on a slower runner, so treat the category as a trend rather than a build-breaking threshold.

Run a Content Check Beside the Lighthouse Run

Four commands cover what the audit skips: content type, size, the first lines of the document, and whether the listed targets still answer. The full pass is available in the llms.txt checker.

# 1. Content type and size — is this text, and how big?
curl -sIL https://example.com/llms.txt | grep -iE "^(HTTP|content-type|content-length)"

# 2. Does the body open with an H1 and a summary, or with HTML?
curl -sL https://example.com/llms.txt | head -5

# 3. Byte count, against a sane ceiling (a few hundred KB at most)
curl -sL https://example.com/llms.txt | wc -c

# 4. Every listed link, status only
curl -s https://example.com/llms.txt | grep -oE "https://[^)]+" | while read u; do
  printf "%s %s\n" "$(curl -s -o /dev/null -w '%{http_code}' -L "$u")" "$u"
done | grep -v "^200"

Then do the part no tool can do for you: read the file as an agent would. If the first screen does not say what the site is, which surface it covers and where the authoritative pages live, the green light is measuring the wrong thing. The crawler user-agent test covers the delivery side; the generator at /generator gives you a structurally valid starting point to edit.

Audit behaviour described here is taken from Chrome's Lighthouse documentation for agentic browsing, last updated May 5, 2026; the format itself is the llms.txt proposal, v2, last modified August 10, 2026. Status codes, content types and byte counts were captured from this server on October 31, 2026 with redirect following. Lighthouse categories and audit descriptions change, so re-run the report against your own origin rather than treating this summary as current behaviour.