Bridge SEO
llms.txt format: the four parts, in order, and why
The shape, in one look
A conforming file is markdown, and it has four parts in a fixed order, with room for a line or two of free prose between the summary and the first section. Only the first is required.
# Site name > One sentence on what this is Any prose that helps a reader place the site. ## Docs - [Page name](/url): one line on what the page answers - [Another page](/url): one line ## Optional - [Deep reference](/url): may be skipped when context is short
| Part | Required | What it is |
|---|---|---|
# Site name | yes | an H1, and nothing above it |
> One sentence | no | a blockquote, directly after the H1 |
| Free prose | no | plain markdown, no headings |
## Section | no | H2 sections holding link lists |
## Optional | no | the one section name with a reserved meaning |
The order matters because the file is read top to bottom by something that may stop early. The name, then the sentence, then the links.
The H1 and the blockquote
The H1 is the site's name, not a slogan and not a keyword line. A reader that quotes you will quote this.
The blockquote directly under it is the one sentence you would say if somebody asked what the site is. It is optional in the specification and close to mandatory in practice: without it, a reader has to infer the subject from the link list, which is the guessing the file exists to prevent.
Keep it declarative. A summary written as a promise reads as marketing to a person and as an unsupported claim to a machine, and neither is what you wanted from it.
The link sections
Sections are ordinary H2 headings, and their names are yours: Docs, Guides, Reference, whatever the site actually has. Each holds a flat list of links, and each link carries a short note after a colon.
The note is the part people skip, and it is the part that does the work. Compare a bare link with the same link carrying one:
- [Pricing](/pricing/) - [Pricing](/pricing/): what each plan includes, and where the limits are
The first tells a reader nothing it could not guess from the URL. The second tells it whether to follow the link at all, which is the only decision the reader is making.
Write the note as an answer to "what would I learn here", not as a category label. Three to twelve words is usually enough. A reader choosing between six links reads six notes, so a note that repeats the link text spends the reader's attention and returns nothing.
Order the sections the way you would explain the site out loud, not the way the navigation happens to be built. The file is read from the top, and a reader that stops halfway should have stopped in the right place.
The Optional section
One section name is reserved: ## Optional. Links under it may be skipped by a reader working with a short context window.
This is the only prioritisation the format offers, and it is worth using honestly. Put the pages that a reader can do without there: deep reference, changelogs, archives. Do not use it as a second list of things you would like read anyway, because a reader that trusts the label will drop them first, and a reader that does not trust it gains nothing.
If everything on your site is essential, the file does not need the section. An empty Optional heading is worse than none.
llms-full.txt
The companion file carries the full text of the pages, in one document, in the order the summary lists them. It exists because following twenty links costs a reader twenty fetches, and a single document costs one.
Two things make it useful rather than large. It should contain the same pages the summary names, so the two cannot disagree. And it should be generated from the same source as the pages themselves, because a hand-maintained copy drifts within a release and then misdescribes the site with confidence.
Serving it
The file lives at the root: /llms.txt, alongside robots.txt. Serve it as text/plain or text/markdown, and do not put it behind a redirect chain or a bot challenge, since the readers that would use it are precisely the ones least likely to survive either.
There is no registration step, no submission, and nothing to verify. The file is either fetchable or it is not.
That also means nothing warns you when it breaks. A deploy that changes how static files are served, a rule that starts challenging unfamiliar user agents, a rename that leaves the old path returning a redirect: any of these takes the file out of use quietly, because nothing was watching it. Fetching it the way a reader would, occasionally, is the whole of the available monitoring.
Where files go wrong
Links that do not resolve
A summary naming deleted pages describes the site worse than no summary at all.
Notes copied from meta descriptions
Those are written to be clicked; these are written to be chosen between. The register is different.
A wall of every URL
The value is in the selection. A file that lists everything has made no selection and saved the reader nothing.
Marketing voice
Superlatives read as noise to a reader that cannot verify them, and the file has no place to put evidence.
A file nobody owns
The summary describes the site, so it goes stale exactly when the site changes, which is when everyone is busy. Generating it from the same source as the pages removes the problem rather than scheduling it.
FAQ
Is any of this enforced, and does it have to be markdown?
Nothing enforces it: there is no validator with authority, no registry and no error to receive, so a malformed file is read as whatever the reader makes of it. The specification says markdown for a practical reason, because headings and lists are the structure readers already parse, and the shape is the only thing a reader can rely on.
How long should it be?
Short enough that a reader arriving with a question can take in the whole of it, which for most sites means well under a hundred lines. If a section needs its own explanation, that explanation belongs on a page that the file links to rather than inside the summary itself.
Can I list pages that are not indexed?
You can, and it is occasionally right: a page blocked from search may still be the best answer to a question. Be aware that you are asking a reader to fetch something the rest of your setup keeps out of results, and make sure that is what you meant rather than an oversight.
What goes in the notes for a large documentation set?
Group by what a reader would be trying to do, not by how your navigation is organised. Half a dozen sections with honest one-line notes beat a faithful mirror of a sidebar, because the sidebar was designed for somebody who can already see the whole of it.
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.