The proposal is simple enough to describe in a sentence. Put a file at /llms.txt containing a short description of what the site is, followed by a curated list of its most useful pages with one line each explaining what is in them. Markdown, human-readable, no schema.
The intent is that a model asked about your organisation could read one short document instead of crawling and inferring from a hundred pages of navigation, cookie banners and footer links.
What it is not
| FILE | AUDIENCE | PURPOSE | ENFORCEABLE |
|---|---|---|---|
| robots.txt | Crawlers | What may and may not be fetched | By convention only, and widely honoured |
| sitemap.xml | Search indexes | Every URL, with dates and priorities | Not a permission, an inventory |
| llms.txt | Language models | What the site is and which pages matter | No commitment from anybody |
The distinction that matters most: llms.txt grants nothing and forbids nothing. If you want to control training or crawling, that conversation belongs in robots.txt directives and in whatever opt-out mechanisms the relevant operators publish. Putting a licence statement in llms.txt is theatre.
Does anything read it?
The honest answer as of writing is: not demonstrably, at least not by the systems that matter most. Adoption on the publishing side has grown steadily; commitments on the consuming side have not followed. Anyone telling you it is a ranking factor is inventing that.
That is an argument against building a project around it. It is not an argument against writing one, because the file has a second use that does not depend on any model reading it.
The second use, which is the real one
Writing an llms.txt forces you to answer, in one page, what your site is for and which twenty pages actually matter. Almost every site fails that exercise the first time. You discover that four of the twenty do not exist, that two of them say the same thing, and that the sentence describing the company is different from the one in the footer, which is different again from the one in the meta description.
Fixing those is worth the hour regardless of whether a model ever fetches the file, because those inconsistencies are also what any system infers from when it composes an answer about you.
What to put in one
- One H1 with the organisation’s name and a blockquote of one sentence saying what it does. Use the same sentence everywhere else on the site.
- A short paragraph of context: where you are, what you make, who for. Facts a model can attach to an entity.
- Sections by page type, not by navigation label. Services, case studies, reference, definitions, writing.
- One line per page: the title as a link, then what is in it. Not marketing copy — a description.
- Numbers where you have them. Counts, dates, published figures. This is the material that gets quoted.
- A contact route and the canonical URLs for the organisation’s profiles.
Keep it under a few thousand words. The point is that it is cheaper to read than the site; a file that is not cheaper to read than the site has no reason to exist.
What to do instead, if you only do one thing
If the choice is between an llms.txt and getting your structured data right, choose the structured data. Organisation markup with consistent naming, Article nodes with real authors and dates, DefinedTerm on your definitions, and breadcrumbs that match the URLs are all read by systems that have committed to reading them.
llms.txt is a reasonable bet with a low stake. Schema is not a bet.
Why consistent naming across a site does more for machine comprehension than any single file can.
ENTITY GRAPH, DEFINED →