In short
It is cheap to add and, on current evidence, does very little. The llms.txt proposal describes a plain text file at the root of a site listing the pages a language model should read, but no major assistant provider has documented using it, and none reports on it. For an online store the things that demonstrably affect whether products can be found and described accurately are crawlable pages, a clean product feed, correct structured data and a deliberate robots policy. Add llms.txt if you like, after those.
What the proposal is, and where it stands
The idea comes from the developer community rather than from any search or assistant company. A file at the root of the domain, written in plain text with markdown headings, lists the pages a model should prefer and gives a short description of each, so that a system with a limited context window can be pointed at the useful parts of a site instead of crawling everything.
It is a reasonable idea for a documentation site, where a small number of stable pages carry almost all the meaning and the maintainers can describe them accurately in a paragraph each.
What it does not have is adoption by the systems that would need to honour it. The major assistants retrieve pages through their own crawlers and through search indexes, and none of them has published documentation saying they read this file or treat it as a signal. Some have said publicly that they do not.
That may change. Standards sometimes start as conventions and become supported later. Until that happens, the honest description is that adding the file is a bet on future support rather than an action with a present effect.
Why it fits an online store poorly
A store's most important content is its catalogue, and a catalogue is the worst possible fit for a hand-maintained text file. Prices move, stock moves, products are added and retired weekly, and a static list of URLs with descriptions goes out of date almost immediately. The mechanisms that already exist for this, product feeds and structured data, are designed to be regenerated continuously.
The second problem is scale. A file listing a few dozen pages tells a model nothing about a catalogue of thousands, and a file listing thousands is a sitemap with extra prose.
The third is that the information assistants get wrong about stores is rarely about which pages exist. It is price, availability, shipping, returns and specifications, and those are settled by the feed and the page markup, not by a directory.
There is also no way to know whether it helped. With no reporting from any provider and no way to isolate the effect, a store that adds the file cannot tell you what it did, which is a reason to keep it low on the list rather than a reason to avoid it.
What to do first, in order
Make the pages readable without interaction. If a product's price, availability, description and specification only appear after a script runs or a shopper picks a region, a fetcher may see none of it. This single check resolves more assistant accuracy problems than anything else.
Get the product feed complete and accurate, because on Google's surfaces the feed is the product record, and other shopping systems increasingly work from structured merchant data too. Identifiers, attributes, images, price, availability and shipping all matter here.
Add Product structured data that matches the visible page, and organisation and policy markup so returns, shipping and contact details are stated in a machine-readable way as well as in prose.
Decide a robots policy deliberately, separating the fetchers that answer shoppers from crawlers that gather training data, and blocking cart, checkout, account and filtered URLs from all of them.
Then make sure the facts about your store are consistent everywhere they appear: your own pages, marketplaces, supplier listings, directories and review sites. Assistants assemble an answer from several sources, and contradictions between them are what produce wrong descriptions of your products.
If you add it anyway, keep it small and true
There is no harm in the file itself. It is a few kilobytes served from your root, it does not affect ranking, and it does not expose anything a sitemap does not. The risk is entirely in the maintenance: a stale file that describes pages you deleted is worse than no file.
So point it at things that do not change. The categories you will still have next year, your shipping and returns policies, your sizing or compatibility guidance, your about and contact pages, and any reference material you maintain. Leave individual products out and let the feed and sitemap handle those.
Write the descriptions as plain facts rather than marketing copy. If it is read at all, it will be read by a system trying to work out what your site covers, and a sentence saying what a page contains is more useful than a sentence saying how good it is.
Put it on the same maintenance schedule as your sitemap and your policy pages, and review it whenever the site structure changes. Then set expectations accordingly with whoever asked for it: this is a small, speculative addition, not a visibility strategy.
Related questions
Do ChatGPT or Perplexity read llms.txt?
Neither has documented doing so, and the file is not part of any published crawling specification. Their systems retrieve pages through their own fetchers and through search infrastructure. Treat any claim that a specific assistant honours the file as unverified unless it appears in that provider's own documentation.
Does adding the file create any risk?
Very little. It is a public text file, so do not list anything you would not want indexed, and keep it accurate. The realistic downside is opportunity cost: time spent maintaining it is time not spent on the feed, the structured data and the crawlability of product pages, which have demonstrable effects.
Is there an equivalent that assistants actually use today?
Yes, several, and they predate the idea. Robots.txt is honoured by the major fetchers, XML sitemaps are used for discovery, structured data is parsed on the page, and product feeds supply merchant data directly to shopping systems. Those four are documented, supported and measurable in a way this proposal currently is not.