llms.txt examples: two good files and one done badly
A small product site
Eight pages, a plain menu, one thing to sell. The temptation is to skip the file entirely, and the reason not to is that the site's name rarely says what the site does.
# Example Analytics > Server-side analytics for teams that cannot ship > a browser tag. ## Product - [What it does](/product/): the measurement model, and what it cannot see - [Setup](/setup/): the two integration paths, with the tradeoff of each - [Pricing](/pricing/): what each plan includes, and where the limits are ## Reference - [API](/api/): endpoints, auth, and rate limits - [Data retention](/retention/): how long each record is kept, and why
Five links out of eight pages. The three left out are the ones a reader with a question would not need: an about page, a contact form, a terms page. Leaving them out is the selection that gives the file its value.
The notes carry a second job that is easy to miss. Each one names a limit as well as a subject: what it cannot see, the tradeoff of each, where the limits are, and why. A reader deciding between two links is usually deciding which one will disappoint it less, and a note that admits a boundary answers that faster than a note that praises the page.
Notice what the blockquote does. "Server-side analytics" places the category; "for teams that cannot ship a browser tag" places the reader. A summary that stopped at the category would have described half the sites in the category.
A documentation set
Sixty pages, a sidebar, and a structure that makes sense only if you can already see the whole of it. This is the case the format was designed for, and the mistake to avoid is mirroring the sidebar.
# Example DB > An embedded database with a SQL interface and no > server process. ## Start here - [Install](/docs/install/): platforms, and what each package contains - [First query](/docs/first-query/): the shortest path to a working read ## Guides - [Transactions](/docs/transactions/): isolation levels, and which is default - [Migrations](/docs/migrations/): the file format, and rollback behaviour - [Backups](/docs/backups/): what a backup contains, and what it omits ## Optional - [Internals](/docs/internals/): storage layout, WAL - [Changelog](/changelog/): releases, dated
Sixty pages became seven links, grouped by what a reader would be trying to do. Start here and Guides are tasks; the sidebar's own categories were probably nouns.
The grouping is the editorial work, and it is the part that cannot be generated. A build step can list every page and keep the list accurate, but only somebody who knows the product can say that installing and running a first query are one journey while transactions and backups are another. Where the list is generated, the section names and the notes are still worth writing by hand once and reviewing when the shape of the product changes.
The Optional section earns its place here. Internals and a changelog are skippable by a reader answering a practical question, and labelling them honestly means the reader drops the right two rather than a guess.
The same file, done badly
Nothing in the file below is malformed. It parses, it sits at the right path, and it is close to useless.
# Example DB - The Fastest Embedded Database > The best embedded database for modern teams. > Blazing fast, developer first, trusted by thousands. ## Links - [Home](/) - [Docs](/docs/) - [Blog](/blog/) - [About](/about/) - [Careers](/careers/) - [Privacy](/privacy/) ## Optional - [Install](/docs/install/) - [First query](/docs/first-query/)
Four things went wrong, and each is common.
The H1 carries a slogan
A reader quoting the site now quotes a superlative, which is worse for the site than a plain name.
The summary makes claims it cannot support
"Trusted by thousands" gives a reader nothing to verify and reads as noise.
The notes are gone
Every link is a category label, so the reader learns only what the URL already said.
Optionalholds the two pages that matter mostA reader honouring the label drops exactly the pages the site most wanted read.
Reading your own file back
The useful test takes a minute and needs no tooling. Read the file as if you had never seen the site, then answer three questions from it alone.
What does this site do? If the blockquote does not answer it, rewrite the blockquote before touching anything else.
Which link would I follow first, given a real question? If two links look interchangeable, the notes are doing no work.
What would I still not know? That gap is either a page you forgot to list or a page you have not written, and both are worth knowing.
What ages and what does not
The blockquote rarely goes stale, because what a site is changes slowly. The link list goes stale constantly, because pages move and get renamed and get retired, and nothing warns you.
That asymmetry is the argument for generating the list from the same source as the pages. A summary written by hand is a second description of the site that has to be kept in step with the first, and the failure mode is silent: the file still parses, still fetches, and now names pages that are gone.
Where hand-writing is unavoidable, put the file where a deploy would notice it, and read it back on the same schedule you review the navigation.
There is one more thing worth checking on that schedule, and it takes seconds: fetch the file the way a reader would, from outside your network, with a plain client. A file that answers from your machine and returns a challenge or a redirect to everybody else has stopped existing for the readers it was written for, and nothing in the file itself would ever tell you.
FAQ
Can I copy one of these files?
Copy the shape, not the content. The sections, the note lengths and the use of Optional transfer to any site; the words do not, because the whole value of the file is that it describes this site rather than a category. A copied summary is a generic one, and a generic summary is the guess the file exists to replace.
How many links is too many?
There is no limit in the format, and the practical ceiling is the point at which a reader stops being able to choose. For most sites that is somewhere between five and fifteen. If a section needs thirty, the honest move is usually to link a hub page and let it do the enumerating.
Should the notes repeat keywords?
No. The file is read by something that already has the page text available if it wants it, so a keyword in a note buys nothing and costs clarity. Write the note so that a reader choosing between two links can tell which one answers the question in front of it.
Do I need llms-full.txt if my site is small?
Rarely. Its purpose is to save a reader many fetches, and a site of eight pages does not present that problem. Where the pages are long or the reader is likely to want several at once, it starts to earn its place, and it should be generated rather than maintained.
What if my sections do not fit these names?
Use your own. Only Optional has a reserved meaning, and every other heading is yours to name. Naming them after what a reader is trying to do works better than naming them after how the site is organised internally, because the internal organisation is the thing the reader cannot see and was never meant to learn.
AI SEO, without the overclaiming
These pages pin down what enrichment fills and what it never touches. The platform they describe is Bridge CDN, where an account is created.