Does llms.txt Actually Do Anything? An Evidence Check

Few topics in AEO generate as much confident advice on as little evidence as llms.txt. Depending on who you read, it is either essential infrastructure or complete theatre.

Both positions are overstated. Here is what the file is, what is actually known about whether anything reads it, and a defensible answer to the only question that matters: should you publish one.

What it is

llms.txt is a proposed convention: a markdown file at the root of your domain giving language models a curated, clean summary of your site and links to the pages that matter most.

The reasoning behind it is sound. Modern web pages are hostile to machine reading — navigation, cookie banners, interstitials, and content that only materialises after JavaScript runs. A model working within a finite context window spends much of it on markup rather than substance. A hand-authored markdown index sidesteps all of that.

It is deliberately analogous to robots.txt, and the analogy is where most of the confusion originates.

The analogy is misleading in the way that matters

robots.txt works because crawler operators agreed to honour it. The convention was formalised as RFC 9309 after decades of practice, and it is load-bearing precisely because the major crawlers have publicly committed to reading it.

llms.txt has the format and not the commitment. As of now, no major AI engine has publicly documented that it fetches or uses llms.txt in producing answers. That is the central fact, and it is the one most articles on the subject step around.

Consider what the engines do document. OpenAI publishes detailed crawler documentation covering its user agents and how to control them. Google maintains extensive guidance on its AI features and what influences them. Perplexity documents its crawlers. These are companies that document crawler behaviour in considerable detail. None of that documentation describes consuming an llms.txt file.

Absence of documentation is not proof of absence — an engine could read the file and never say so. But when the same vendors document adjacent behaviour thoroughly, silence on this one is weak evidence against, not neutral.

What people mistake for evidence

Three arguments come up repeatedly. Each is weaker than it looks.

“My server logs show AI crawlers fetching it.” Plausible, and it means less than it appears. Crawlers fetch lots of root-level paths speculatively. A fetch proves retrieval, not use — the file could be downloaded, parsed, and discarded, or downloaded and never parsed at all. Crawl is not citation, and that gap is the recurring theme of measurement in this field.

“We published one and our AI visibility improved.” Almost never attributable. Teams that publish llms.txt are teams actively working on AEO — they are simultaneously restructuring content, adding structured data, and pursuing citations. Attributing movement to the one change that is easiest to point at is the oldest error in marketing measurement. Nobody has published a controlled test isolating this variable, and until someone does, these reports are anecdote.

“It can’t hurt.” Nearly true and worth stating precisely: it costs the effort to write and the discipline to maintain. A stale llms.txt describing last year’s product is worse than none, because you have created a machine-readable document asserting things that are no longer true.

What it is genuinely good for, today

Setting aside whether engines read it, writing one has a reliable second-order benefit that does not depend on adoption at all.

It forces you to state plainly what you do. Producing a concise, accurate, jargon-free summary of your business and your most important pages is an exercise most companies have never actually completed. The output is directly reusable — in your homepage copy, your meta descriptions, your documentation index, your positioning. The clarity is the deliverable.

It surfaces your own information architecture. Teams routinely discover, mid-draft, that the page they most want an engine to read does not exist, or exists in three contradictory versions. That finding is worth more than the file.

It is cheap optionality. If adoption arrives, you are ready. If it does not, you spent an afternoon and got a positioning exercise out of it.

Notice that none of these is “engines will read it.” They are the honest reasons, and they are sufficient for a small investment.

What definitely does work

The uncomfortable comparison: everything llms.txt hopes to achieve is achievable today through mechanisms that are documented, adopted, and verifiable.

• Rendered HTML that states the answer plainly. Engines demonstrably read your pages. A page whose central claim appears as a clear, self-contained sentence is quotable; one that buries it is not. This is the mechanism with actual evidence behind it — the GEO paper found that adding quotations, statistics and cited sources measurably improved visibility in generative engines.
• Structured data. Schema.org markup is consumed by Google’s systems, documented, and testable.
• Server-side rendering. If your content requires JavaScript to appear, some crawlers will not see it. JavaScript rendering and AI crawlers covers this, and it is a far more common cause of invisibility than any missing convention file.
• Third-party presence. Engines weight what others say about you heavily, and no file on your domain influences that.

If you have an afternoon for AEO work, and your pages do not yet state their answers plainly, llms.txt is not where that afternoon belongs.

The verdict

Publish one if you already have your fundamentals in order, you can generate it from a source you maintain anyway, and you understand it as an option on future adoption rather than a current channel. Our llms.txt generator and llms.txt audit exist for this — free, quick, no reason not to.

Do not publish one if it would be hand-maintained and destined to go stale, or if it would consume effort that your unrendered content or your absent third-party presence needs more.

Do not report it as a visibility tactic to anyone, and be sceptical of any tool or agency presenting it as one. There is currently no evidence base for that claim, and making it is how a field’s credibility erodes.

How you would know if it started working

Worth planning for, because the answer could change and you want to detect it rather than assume it.

The test is not “did our visibility improve after publishing” — too many variables move at once for that to be attributable. It is narrower: does the content of what engines say about you start tracking the specific framing in your llms.txt rather than the framing on your pages? If your file describes your product in a particular way that your site does not, and answers begin echoing the file’s language, that is a signal worth taking seriously. If answers keep tracking your homepage copy, the file is not reaching them.

That requires a baseline recorded before you publish and consistent observation after — which is the general shape of testing any AEO change honestly. Multi-engine monitoring is what makes the comparison possible across engines, since adoption would almost certainly arrive unevenly: one vendor first, documented or not, while the others carry on ignoring it.

The broader point

llms.txt is a good idea proposed in good faith to solve a real problem. It may well be adopted. The reason to be careful about it is not that it is bad — it is that AEO is young enough that plausible-sounding tactics circulate faster than anyone checks them, and a discipline that cannot distinguish “this ought to work” from “this is documented to work” produces advice that is indistinguishable from guessing.

The correct posture is the boring one: implement it if it is cheap, describe it accurately, and keep watching. If a major engine documents consuming it, that changes the answer immediately — and what is llms.txt is where we track the specification itself. Until then, the honest description is “low-cost, unproven, and possibly useful later,” which is a perfectly respectable thing for a new convention to be.