llms.txt Validator: 43 of 578 Sites Fail Lighthouse

Google Search tells you not to bother with llms.txt. Chrome's Lighthouse ships an audit that gives your site a zero for it. Both are Google, both are live, and the second one is why people go looking for an llms.txt validator: a red row appears in a PageSpeed report and the docs don't explain it.

So I took the validator apart. The audit is 125 lines of JavaScript and its content check is three regular expressions. I ported those rules and pointed them at the 578 external hosts this blog cites across its 356 posts — vendor docs, forums, standards bodies, shops. 178 answered. 43 fail the audit, and 32 of those 43 never published an llms.txt at all.

What Lighthouse actually checks

The audit lives at core/audits/agentic/llms-txt.js. After the fetch, the entire content validation is this:

const hasH1 = /^\s*#\s+.+/m.test(content);
const hasLink = /\[.+\]\(.+\)/.test(content);
const isTooShort = content.length < 50;

One markdown H1 anywhere in the file, one markdown link of the form [text](url), at least 50 characters. That is the whole test. The status handling around it matters more than the regexes:

• HTTP 5xx → score 0, shown as Failed with HTTP status 500
• HTTP 4xx → notApplicable — no file, no score, no penalty
• Fetch error → score 0, Fetch of llms.txt failed
• HTTP 2xx → run the three rules above

The documentation page mentions only the server-error branch and says a 404 is marked Not Applicable "as providing the file is optional at the moment." It never documents the H1, link or length rules — which is what a site owner filed in issue 17082, after a spec-compliant file came back as a failure with a misleading fetch error.

578 hosts, one request each

The population is every external link host in our posts — the same list I used to check which sites block AI training bots on Cloudflare. I fetched /llms.txt and /llms-full.txt from each host once, with a Chrome User-Agent, on 2026-09-20.

My first pass was wrong twice. I stored only the first 3,000 characters of each body, which marks any file whose first markdown link appears later as "no links" — a false failure. And www.sandisk.com and www.westerndigital.com came back as binary garbage because they gzipped the response although I never sent an Accept-Encoding header. I refetched all 178 responding hosts with full bodies and gzip handling; 163 compress, none of them lie about it. Every number below comes from that second pass.

Most failures are sites that never published a file

Of the 178 hosts that returned 200, 32 sent HTML. Eighteen redirected /llms.txt onto a normal page: support.google.com to its home page, discussions.apple.com to /error/unauthorized, cyber.harvard.edu and www.indexnow.org to their own /404 pages that answer 200, www.cablematters.com to Customerror.aspx. Two — macmyths.com and www.searchenginejournal.com — redirect to their own explainer article about llms.txt.

The other fourteen answer 200 with HTML at the same URL, because their front end returns the app shell for any path: reddit.com, x.com, threads.com, duckduckgo.com, nvd.nist.gov, core.telegram.org, builder.aws.com, realtek.com and six more.

All 32 fail with missing H1 and no links. None of them ever claimed to have the file; a catch-all route turned "not found" into "found, and wrong." If this audit fails for you and you never wrote the file, check the status code before you write one — a real 404 would have made the audit skip you entirely.

The 11 real files that fail

146 hosts returned actual text (97 as text/plain, 49 as text/markdown). Eleven of them fail:

Host	Bytes	Audit error	What is in the file
developer.amazon.com	69,083	no links	405 bare URLs, one per line, no [](...)
cursor.com	21,678	no links	354 bare URLs under H2 sections
www.algolia.com	7,866	no H1	Starts with Algolia; the summary and 27 links are fine, the # is missing
plugable.com	5,676	no links	Company description in prose
www.playstation.com	3,842	no H1	Opens with "Generated by LLMs.txt Generator"
thehackernews.com	2,719	no links	A hand-rolled policy file: site_name:, canonical_source:
store.minisforum.com	1,098	no links	First line is literally Content-Type: text/plain
rustdesk.com	2,263	no links	H1 and summary only
aescreens.com	2,006	no links	H1 and summary only
www.elektormagazine.com	1,213	no links	H1 and summary only
nichebloghub.com	65	no H1, no links	robots.txt content, including an invented Disallow-Training: /

Two patterns cover nine of the eleven: bare URL lists instead of markdown links, which the llms.txt spec does require as [name](url), so the audit is right and Amazon and Cursor are wrong; and files that are a summary with nothing to follow.

A quarter of the files were written by Shopify, not by the site

37 of the 146 files open with "Agent Instructions" instead of the site's name and carry a pitch for shop.app/SKILL.md: auto-generated Shopify storefront files, clustered between 4.0 and 4.7 KB, telling the reading agent to install Shopify's Shop skill so it can buy things. The median file size across my whole sample is 4,502 bytes, which is just this file. Same kind of storefront I surveyed when I mapped Shopify's products.json limits.

Add 9 files naming Yoast and 2 signed by an "LLMs.txt Generator" and 48 of 146 — 32.9% — carry a generator's fingerprint. All 37 Shopify files pass Lighthouse, and none has the blockquote summary the spec asks for, because Lighthouse doesn't look for one.

What the audit ignores

The spec's structure is an H1 (the only required part), then a blockquote summary, then H2 sections of markdown link lists. 144 of my 146 files have H2 sections; only 84 have the blockquote summary, and all 84 are non-Shopify, so 77% of the hand-written files carry a summary and none of the generated ones do. Lighthouse passes all of them either way.

The one structural detail Lighthouse did have to fix is the byte-order mark, which broke the H1 regex on Yoast files until issue 17051. 14 of my 146 files start with one. Reimplement /^\s*#\s+.+/m in Python and those 14 fail for you and pass for Lighthouse, because JavaScript's \s matches U+FEFF and Python's does not — which is why my script spells out its whitespace class.

The sites I read most don't publish one

Ranked by how often this blog cites them, 6 of the top 20 hosts serve an llms.txt: github.com (175 posts), code.claude.com (69), developers.cloudflare.com (24), support.claude.com (10), supabase.com (9) — and discussions.apple.com (39), which is one of the HTML failures, not a real file.

The 404s in that top 20 include news.ycombinator.com (139 posts), support.apple.com (57), forums.macrumors.com (32), developer.apple.com (23), web.archive.org (10) and developers.google.com (15) — the site that published the guidance saying you don't need machine-readable AI files. The forums where I do most of my research have nothing, which matters more to me than the adoption rate: the pages an agent needs are usually not the ones an llms.txt lists.

llms-full.txt isn't in the spec at all

72 hosts serve a non-HTML /llms-full.txt, all but four alongside an /llms.txt. Six hit my 4 MB read cap, so platform.claude.com, developers.openai.com, docs.slack.dev, developers.cloudflare.com, supabase.com and docs.perplexity.ai are each at least 4 MB of concatenated documentation. Neither v1 nor the v2 revision of 2026-08-10 defines that filename — it spread on its own, and Lighthouse has no audit for it.

Run the same check on your own file

import re, urllib.request
JSWS = r'[\f\n\r\t\v    - 

  　]'
req = urllib.request.Request('https://example.com/llms.txt',
        headers={'User-Agent': 'Mozilla/5.0', 'Accept-Encoding': 'gzip'})
with urllib.request.urlopen(req) as r:
    status, ctype, body = r.status, r.headers.get('content-type', ''), r.read().decode('utf-8', 'replace')

print('status', status, ctype)
print('served HTML instead of markdown:', body.lstrip().lower().startswith(('<!doctype', '<html')))
print('hasH1  ', bool(re.search(rf'^{JSWS}*#{JSWS}+.+', body, re.M)))
print('hasLink', bool(re.search(r'\[.+\]\(.+\)', body)))
print('tooShort', len(body) < 50)

Check the HTML line first. If it says True, your problem is a routing rule, not your markdown.

What I did with our own file

https://picklog.cc/llms.txt returns a real 404, so Lighthouse marks us Not Applicable and we lose nothing. I am not adding the file today: our index lists every post, the sitemap is complete, and nothing in this census shows an agent reaching us through one — the same shape of answer I got comparing what AGENTS.md and CLAUDE.md actually get loaded. What I did keep is the checker, so the next time a Lighthouse row goes red I read the rule before rewriting the file.

Is there an official llms.txt validator?

There is no validator from the llms.txt authors. The closest thing to an authoritative check is the Lighthouse audit that ships in Chrome and PageSpeed Insights, and it tests only three things: at least one markdown H1, at least one markdown link, and a body of at least 50 characters. Third-party validators usually check more of the spec, including the blockquote summary that Lighthouse ignores.

Why does Lighthouse say my llms.txt is missing an H1 when it has one?

Usually because Lighthouse never saw your file. If your server redirects /llms.txt or returns the app shell for unknown paths, the audit reads HTML, finds no markdown H1 and reports both errors. Fetch the URL directly and check the status code and content type first. A leading byte-order mark caused this too, until Lighthouse issue 17051 was fixed.

Does a missing llms.txt hurt my Lighthouse score?

No. When the file returns a 4xx status, the audit is marked Not Applicable and does not count. A 5xx status or a failed fetch scores 0, and a file that returns 200 but breaks the three content rules scores 0. Having no file is treated better than having a broken one.

Method and limits: the host list is every external href in the body_html of all 356 posts in our Supabase database, dumped 2026-09-20, which gives 578 hosts. Each was fetched once from this Mac mini in Korea with a Chrome User-Agent between 10:33 and 10:35 KST; the 178 hosts that answered 200 were refetched in full at 10:41 KST with gzip handling. Verdicts come from my own port of the Lighthouse audit function, not from running Lighthouse. I did not reproduce its gatherer, so PageSpeed Insights can disagree with me — open issue 17194 shows it disagreeing with site owners too. The sample leans toward vendor documentation, forums and shops because those are the sites I cite, so 178 of 578 is not a web-wide adoption rate. The 27 hosts that returned 403 and the 8 that never answered may be blocking me rather than missing the file. The spec, Lighthouse docs and Google guide quotes are linked above and were read on 2026-09-20. There are no affiliate links in this post.