Does llms.txt actually work? A 90-day log test

1. The result

As of mid-2026, llms.txt is a proposal, not a working standard — and the data says it changes nothing about your AI visibility today. That is the consistent result across every serious measurement. In my own logs, over a window I published once and did not touch, the file was requested a handful of times in three months. Almost all of those requests came from SEO audit tools and generic scanners — essentially never from the AI retrieval bots that decide citations. The large studies found exactly the same shape at scale. If you take one thing away: treat llms.txt as low-cost insurance, never as a growth lever.

For anyone unfamiliar with the object under test: llms.txt was proposed by Jeremy Howard in September 2024. It is a single Markdown file served at /llms.txt that curates and summarises your site for language models: an H1, a summary blockquote, and grouped lists of links. The idea is to give an AI a human-curated map instead of your whole site. Only the H1 is strictly required. A companion convention, /llms-full.txt, concatenates full documentation into one file. You can generate a spec-correct version in seconds with the free llms.txt generator. The question was never whether you can make one — it is whether anything reads it.

2. What the three big studies found

Every large study lands in the same place: publish rates are climbing, but AI systems are not reading the files.

• Ahrefs (137,210 domains, May 2026): 97% of llms.txt files received zero requests. Of the requests that did land, only 1.1% came from AI retrieval bots. [source]
• SE Ranking (~300,000 domains): found no relationship between having an llms.txt and how often a domain is cited by major LLMs. Dropping the variable from their model improved accuracy.
• Otterly (90-day server-log test): of 62,100+ total AI-bot visits, just 84 requests (0.1%) targeted /llms.txt — performing 68% below an average content page.

And Google has been blunt. In June 2026, John Mueller called llms.txt "purely speculative for now (the file has existed for years, yet none of the AI systems use it)," likening it to the long-dead keywords meta tag. Gary Illyes separately confirmed Google has no plans to support it.

"The file has existed for years, yet none of the AI systems use it." - John Mueller, Google, June 2026

3. Who actually requests your llms.txt

When something does fetch the file, it is almost never an AI answer engine — it is your own SEO tools.

SEO audit tools are the single largest requester at 21.7%. The training crawler GPTBot fetches it occasionally (4.51%), but the bots that actually generate citations — OAI-SearchBot, PerplexityBot — collectively account for barely 1%. Ahrefs summed it up memorably: Slackbot fetched llms.txt more often than PerplexityBot did. And a crawler fetch is not a citation; it is a prerequisite that almost never happens.

4. Why adoption exploded anyway

Adoption grew 8.8× in a year — and almost none of it is deliberate. The count of monitored sites with llms.txt jumped from ~4,088 (June 2025) to ~36,120 (May 2026). That looks like a movement until you see where it came from: platform defaults. When Shopify quietly pushed llms.txt across its stores in spring 2026, adoption on that platform hit 78%.

Strip out the platform defaults and deliberate adoption among the top 10,000 sites is only about 5–6%. The "everyone's doing it" impression is manufactured by a few CMS vendors flipping a switch, not by measured results convincing teams to add it.

5. What this test does not prove

The verdict rests on convergent evidence, and it is worth being exact about what each piece supports. Evidence A server-log test measures one thing well — whether a path was requested, and by whom. That is a direct observation. It is also narrow.

• It is one site. A single domain in a single niche cannot represent the web. The large-scale studies carry that weight; the log test sits beside them, not in place of them.
• Absence of requests is not proof of absence of effect. It is strong evidence, because a file that is never fetched cannot have influenced anything. It does not rule out use by systems that fetch once, cache, and never return.
• No control was possible. There is no version of this site without an llms.txt running in parallel, so no citation comparison can be made at all.
• Unidentified traffic stays unidentified. A bot that does not declare itself cannot be classified.
• It is a snapshot. Behaviour in one window says nothing about behaviour after an engine changes its retrieval stack.

Stating all of this plainly matters because the conclusion is a negative one. Negative findings are held to a higher standard than positive ones, and rightly so. The claim here is narrow: nothing observable is reading the file at any meaningful rate.

6. Run your own 90-day log test

Do not take my word for it — this is measurable in your own access logs. The method below is the one I ran, adapted from Otterly's design.

Filter for the declared AI bots — GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot, Google-Extended — and verify by IP to catch spoofing. Any script can claim to be any bot, and a handful of spoofed requests turns a null into a false positive.

Four other mistakes will produce a misleading result in either direction. No control file: a raw count means little, so compare against a control path of similar obscurity and express the result as a ratio. Sampled or truncated logs: many hosting dashboards sample traffic or discard entries quickly, and a sampled log can miss a rare event entirely — check retention before you start. Changing the file mid-test resets what you are measuring. And stopping early on a promising week: crawl activity is uneven, so a busy fortnight is normal variation, not a trend.

Define "working" before you start. A weak positive signal is production retrieval bots requesting the file at a rate materially above a control PDF. A strong signal is a measurable citation lift not explained by other changes. Fact Even a genuine retrieval-bot fetch tells you the file was read, not that it changed an answer — separate claims requiring separate evidence. Based on every dataset above, expect neither signal.

7. llms.txt vs robots.txt vs sitemap.xml

These three root files are constantly confused, do completely different jobs, and only two of them are actually honoured.

Your robots.txt and sitemap.xml do load-bearing work every day. llms.txt is aspirational. Get the first two perfect — see the technical GEO audit — before spending a minute on the third.

8. The security angle nobody mentions

There is a quiet risk the hype ignores: the file is an attack surface. Its whole premise is that AI agents will read it and trust it as an authoritative description of your site, and that trust is what makes it a target. In Ahrefs' dataset, the single largest research crawler hitting llms.txt files self-identified as prompt-injection-survey/1.0 — security researchers, and presumably less friendly actors, are already probing these files as an injection vector.

The threat model is straightforward. If an autonomous agent fetches your llms.txt and an attacker has injected instructions into it — or you unwittingly include content that reads like an instruction — the agent may act on it. If you publish one, treat it like public-facing code, not a marketing asset. Plain descriptions and links only, nothing resembling a directive, locked-down edit access, and never auto-generated from user-submitted content. A file almost no production AI reads is not worth a new security surface.

9. What to do instead

Every minute spent agonising over llms.txt is a minute not spent on things with actual evidence behind them. In rough priority order:

1. Do not block the AI search crawlers. This is the real "AI visibility file" — your robots.txt. Make sure OAI-SearchBot, PerplexityBot and Claude-SearchBot are allowed. Blocking them is the one config change that genuinely removes you from AI answers. See the crawler guide.
2. Get into Bing's index. ChatGPT reads from Bing; enable IndexNow and verify Bing Webmaster Tools — see the Bing playbook.
3. Serve real HTML. AI crawlers largely do not render JavaScript. If your facts are injected client-side, no llms.txt will save them; server-side rendering will.
4. Publish original data and lead with statistics. These lifted AI visibility 22–40% in controlled tests — the opposite of llms.txt's zero. See how to get cited.
5. Earn brand mentions. The strongest reported correlate of AI citation, roughly 3× the correlation of backlinks — correlational, with an uncontrolled brand-size confound.

Notice the pattern: everything on this list has measured evidence behind it. llms.txt has measured evidence against it. That asymmetry should decide where your hours go, and it is why the file must never come before crawlable server-rendered HTML, structured data, or freshness.

10. Could it matter later?

Maybe — and that is the only real case for shipping one today. Standards sometimes start as ignored proposals and later become load-bearing; sitemaps did. Adoption is climbing steeply, some of the companies building agents publish llms.txt for their own docs, and the IDE-agent use case is genuine and growing. If a major provider announced tomorrow that it reads llms.txt for retrieval, the calculus would flip overnight.

But "it might matter later" argues for a five-minute insurance file, not a priority. The failure mode to avoid is the familiar one: teams presenting llms.txt as a growth tactic, agencies charging for "llms.txt optimisation," founders believing a Markdown file at their root counts as AI-search homework. They have done the equivalent of adding a keywords meta tag in 2010 — harmless, fashionable, inert. Being early is not the same as being effective.

11. Common misreadings

"llms.txt is proven useless." Too strong. What is shown is that production retrieval crawlers rarely request it, and that no measured citation relationship has been found. Specific negative findings, not a universal claim.

"It will never matter." Also too strong — section 10 argues the opposite case explicitly. Ignored proposals occasionally become standards.

"You should delete yours." Does not follow. Keeping a small, accurate, curated file costs close to nothing. The argument is against treating it as a growth lever, not against its existence.

"The studies disagree with each other." They do not. Three independent measurements with different methods and sample sizes point the same way, and convergence across methods is the strongest form of evidence available in this field. Overstating a null result is the same error as overstating a positive one.

12. What would change this page

A conclusion is only credible if you can say what would overturn it. Open question Five things would revise this page materially.

• A major AI provider announcing retrieval support. The clearest and most likely trigger; it would flip the recommendation overnight.
• A sustained rise in production retrieval-bot requests for the file in server logs, verified by IP. Not a spike — a sustained change.
• A controlled comparison showing a citation difference between matched sites with and without the file. Nothing of that design has been published.
• Evidence of caching behaviour showing the file is fetched rarely but used repeatedly, which would explain low request counts without implying low impact.
• A published replication that disagrees with the existing studies, using a comparable sample size and a documented method.

Any of those would produce a dated update rather than a quiet edit.

13. The spec, if you publish one

Only the H1 is strictly required. Everything else is optional but recommended. The file is parsed in a strict order. First the H1 (site or project name), then a blockquote summary immediately after, then zero or more Markdown sections of background with no headings, then zero or more H2 "file list" sections formatted - [name](url): optional notes, and last an ## Optional section. An AI may skip the Optional links when context is tight, so put nice-to-haves there, not essentials.

Two companion conventions matter. /llms-full.txt concatenates full documentation into a single file, and is the variant IDE coding agents actually use; if you run developer documentation it is the more useful of the two to ship. Some sites also serve .md versions of HTML pages at the same URL plus a .md suffix.

A point that trips people up: llms.txt is curation, not access control. It does not stop anything being crawled (robots.txt) and does not list every URL for discovery (sitemap.xml). It is a hand-picked "start here", which is precisely why an auto-generated file dumping every page defeats the purpose. Curate it — your best 10–30 pages, grouped and described. And keep maintenance in mind: a stale llms.txt pointing at moved or deleted pages is worse than none, because it hands any agent that does read it a map full of dead ends.