Do you need an llms.txt file? Google says no.

This site has an llms.txt. I would still tell you that most of what is written about llms.txt is wrong, and that the reason to have one is not the reason usually given.

The pitch is that it is a ranking or visibility file — publish one and the models will read it and cite you. There is very little supporting that, and a reasonable amount contradicting it.

#What the evidence actually shows

Three things, all of which are publicly reported rather than measured by me:

• Google has said it does not support llms.txt and is not planning to, with the comparison drawn to the old keywords meta tag — a file publishers maintain and search engines ignore.
• No major provider has publicly committed to reading it in production. Not OpenAI, not Anthropic, not Google, not Meta.
• Reported monitoring of AI crawler traffic through 2026 found direct fetches negligible — a tiny number of requests against hundreds of millions of AI bot visits. The training crawlers essentially do not ask for it.

#Where it genuinely does get read

There is a real use case and it is more interesting than the one being sold.

The distinction that matters is between a crawler and a fetcher. A crawler gathers pages at scale for an index or a training set, and largely ignores llms.txt. A fetcher retrieves a specific URL right now because a user just referred to it — you paste a domain into a coding assistant, or ask a desktop agent about a product, and something goes and looks.

Those on-demand agents do read it. Coding assistants and agent frameworks will pick it up when a user names a domain, which makes llms.txt an agent-to-agent convenience file rather than a search asset. If somebody points an assistant at your site and asks what you do, a good llms.txt is the difference between a confident answer and a guess assembled from your navigation.

That is a smaller audience than the pitch implies. It is also a higher-intent one, because somebody had to name you for it to happen at all.

#So should you write one?

Yes, if it costs you almost nothing. No, if it becomes a thing you maintain.

That distinction is the whole recommendation, and it is not the usual advice, so it is worth being specific about why.

#Generate it. Do not write it.

Mine was a static file for a while and I can tell you exactly what happened to it, because it is the standard outcome and it took about two months.

It drifted. It described one of my pages as something that page had never been — the description had been true of a different section that was later renamed. It omitted an entire route that had shipped after the file was written. And it carried two different "last updated" dates in the same document, which is a nice summary of what a hand-maintained file becomes.

Every one of those is the same failure: a summary of the site, maintained separately from the site. So it is now generated from the same data that renders the pages — the page registry, the project list, the article index. A page that exists is described. A page that does not cannot be. Neither state depends on anyone remembering.

A hand-written llms.txt is worse than no llms.txt, because a confidently wrong summary is exactly what a fetcher will believe.

One thing I deliberately left out: a build-stamped date. It would advance on every deploy and claim freshness the content does not have, and freshness is one of the few things an engine actually weighs. It reads the real dates of the real content instead.

#How to find out whether anything reads yours

Check your server logs, not your analytics — an analytics script never runs for a client that does not execute JavaScript, which is the entire population you are asking about.

There is a trap here I walked into on this site. My crawler logging is wired into the request layer, and its matcher excludes any path ending in a file extension — a sensible rule that keeps it off fonts, images and scripts. llms.txt ends in an extension. So the one file I most wanted visit data for was the one file my own instrumentation was configured to ignore, and I had no data at all rather than zero visits, which are very different results.

#What it does not substitute for

The failure mode I would most want to warn against is treating llms.txt as the AI-readiness task, ticking it, and stopping. It is the cheapest item on the list and close to the least important.

If your actual pages are readable without JavaScript, your structured data is in the served HTML, your headings describe what follows and your answers are self-contained, you are in good shape whether or not you publish an llms.txt. If none of that is true, the file will not rescue you — the fetcher that reads it will then go and read a page it cannot parse.

Publish one. Generate it. Spend the remaining effort on the pages.