llms.txt: what it is, how to write one, and whether it does anything yet

There is a file people keep asking about, and the honest answer has two halves that are both true: nobody has confirmed it does much yet, and you should probably still add one.

Here is the full picture.

What it is

llms.txt is a Markdown file placed at the root of a domain, at https://example.com/llms.txt. It contains a short description of what the organisation is, followed by a curated list of links to the pages that matter most, each with a one-line explanation.

The proposal came from Jeremy Howard of Answer.AI in September 2024. The reasoning behind it is straightforward: modern web pages are mostly navigation, scripts and layout, and a language model working within a context limit wastes most of that budget on markup. A clean summary lets a model get the important information in one cheap fetch.

The idea borrows its shape from robots.txt, but it does the opposite job. robots.txt restricts. llms.txt explains.

What it looks like

The format is deliberately simple. An H1 with the name. A blockquote with a summary. H2 sections containing link lists.

# The Corner Room

> A twenty-four cover neighbourhood restaurant in Fitzroy, Melbourne,
> serving a daily-changing seasonal menu. Open Wednesday to Sunday,
> dinner only. Walk-ins for the bar, bookings for tables.

## Core pages
- [Menu](https://example.com/menu): The current week's menu, updated Wednesday.
- [Bookings](https://example.com/book): Table reservations, party size limits, cancellation terms.
- [Finding us](https://example.com/visit): Address, parking, nearest landmarks, accessibility.
- [About](https://example.com/about): Who runs it, the cooking, the room.

## Practical details
- Address: 12 Gertrude Street, Fitzroy VIC 3065
- Hours: Wednesday to Sunday, 7pm to 11pm. Closed Monday and Tuesday.
- Price band: $60 to $90 per head, without drinks.
- Bookings: online or by phone. Groups above six by phone only.

## Contact
- bookings@example.com
- +61 3 XXXX XXXX

Two things worth noticing about that example. It states facts a model can filter on, and it repeats them in prose rather than assuming the model will parse a table. Both are deliberate.

llms.txt versus llms-full.txt

The proposal defines an optional companion. llms-full.txt contains the actual content of the linked pages concatenated into one document, so a model can read everything in a single request rather than following links.

For a documentation site with hundreds of pages, this is genuinely useful. For a restaurant with six pages, it is usually redundant. Start with llms.txt and add the full version only if your site is large enough that link-following would be expensive.

The honest state of support

This is where most articles on the subject overstate things.

No major AI provider has publicly committed to reading llms.txt. There is no documented weighting, no verification tool, no reporting. Some developer-focused platforms have adopted it and some AI coding tools look for it, but that is a different use case from a model deciding which restaurant to recommend.

Why it is still worth doing

Three reasons, none of them speculative.

The cost is close to zero. A static file, twenty minutes, no maintenance beyond keeping the facts current.

Adoption is cheap to be early on. If support arrives, the file is already there. If it does not, you lost twenty minutes.

Writing it is a genuine audit. This is the real value. To write a good llms.txt you have to state, in plain sentences, what your business is, who it serves, what it costs, when it is open, and which page says so. Most businesses discover during that exercise that several of those facts are not stated clearly anywhere on their own site. Fixing that does improve retrieval, with or without the file.

How to write one that is useful

A few rules that separate a useful file from a decorative one.

Lead with classification. The first sentence should let a model place you: what type of business, where, at what level. "A twenty-four cover neighbourhood restaurant in Fitzroy, Melbourne" does more work than "an unforgettable dining experience."

State constraints explicitly. Hours, price, capacity, booking policy, accessibility. These are what queries filter on.

Link only to pages that answer something. A curated list of six useful pages beats a dump of forty.

Write the descriptions for a reader, not a crawler. One clear sentence per link explaining what is on the page and why someone would want it.

Keep it current. A stale llms.txt is worse than none, because it is exactly the kind of clean, confident source a model would trust.

Where it fits

Think of it as the smallest piece of a larger job. The file itself is a nice-to-have. The discipline it enforces, writing down what you are in language a machine can use, is the whole point of the exercise, and it pays whether or not anything ever reads the file.