What it is
llms.txt is a Markdown file served at the root of a domain. Its job is to give a language model a curated map of a site: here is what this site is, here are the pages that carry the actual substance, here is one line on what each covers.
The reasoning behind it is sound and easy to state. A model answering a question has a limited context window and a website full of navigation, cookie banners, footers and boilerplate. Rendering an entire site to extract three useful paragraphs is expensive and lossy. A short, hand-written index of the pages that matter is cheaper to read and more likely to be read correctly.
It is deliberately not a new technology. It is Markdown, at a known path, in a documented shape — the same design instinct that produced robots.txt and sitemap.xml.
Does anything actually read it?
This is the section every other page on this subject skips, so here it is plainly.
As of September 2026, no major AI search provider has publicly confirmed that llms.txt is used as a retrieval or ranking input. Adoption on the publishing side is real and substantial — a great many documentation sites and developer tools ship one. Adoption on the consuming side is not documented. Those are two different facts and they are routinely presented as one.
What that means for you: anybody telling you that adding llms.txt will get you cited by ChatGPT is asserting something they cannot demonstrate. If they can demonstrate it, ask to see the before-and-after, the dates, and how they separated the effect of the file from every other change made in the same window. That is not a rhetorical challenge — it is the test I would want applied to any claim I made.
The honest summary is: unproven, cheap, low-risk, and directionally aligned with where retrieval is going. That is a reasonable basis for spending an hour on it. It is not a reasonable basis for selling it.
How to write one
The format is a Markdown document with a specific shape rather than a rigid schema. In practice:
- An H1 with the name of the site or project.
- A blockquote or short paragraph saying in one or two sentences what the site is and who it is for. Write this as though the reader has no context, because it does not.
- H2 sections grouping the pages: services, guides, case studies, whatever your site actually has.
- Under each, a Markdown link per page, followed by a colon and one line describing what is on it.
- Optionally an "Optional" section at the end, holding pages a model may skip when short of space.
Four rules that decide whether it is any good:
- Curate ruthlessly. This is not a sitemap. A sitemap lists everything; llms.txt lists what is worth reading. If you list 400 URLs you have written a worse sitemap.
- Write the descriptions for a stranger. "Pricing" is useless. "Published prices for websites, hosting and growth work, correct at a stated date" is a description that lets a model decide whether to fetch the page.
- Keep it truthful and current. A file describing pages that no longer exist is worse than no file, and it is the failure mode of every generated one.
- Do not stuff it. There is no keyword advantage available here and an obviously padded file reads exactly like what it is.
The one this site ships
Cybrial serves llms.txt at the root of this domain. You can open it: it lists every hub, service page, guide and case study, each with one line saying what is on it, and it is generated at build time from the same route data that produces the sitemap and the navigation.
That last detail is the only part I would argue is genuinely good practice rather than merely fashionable. A generated file is a file that is still correct in March. If you take one thing from this page, take that: whatever you ship, ship something that regenerates.
I also ship it because it would be difficult to sell AI optimisation work while not doing the cheapest and most obvious piece of it. If the file turns out to do nothing, the cost was an hour. If it turns out to matter, the site was ready.
What does appear to work, while llms.txt is undecided
The things that make a page quotable by an AI system are, as far as anyone can currently demonstrate, the things that made a page quotable by a person: clarity, specificity, and being demonstrably the source rather than a summary of one.
- A short, direct, self-contained answer near the top of the page — a paragraph that makes sense lifted out of its context, because that is exactly what happens to it.
- Numbers with their source and date attached, in the same sentence. An assistant repeating "94.5% of 17,233 items, Merchant Centre sync log, September 2026" is repeating something checkable, which is why it is safe to repeat.
- Entity consistency: the same business name, description and founder across your site, your Google Business Profile, LinkedIn and any directory you appear in. Contradictions make you a risky thing to cite.
- Structured data that matches what the page actually says. Marking up a rating you do not display is worse than marking up nothing.
- Genuine first-hand material. Summarised general knowledge is precisely what these systems already have.
None of that is exotic and none of it depends on a file. It is what this site does, and the guides here are written to that pattern deliberately — which you can verify by reading one.
Should you bother?
Yes, if it costs you an hour and you generate it. It is cheap insurance against a standard that may become load-bearing, and the exercise of writing one-line descriptions of your own pages is quietly useful in itself — most people discover two or three pages they cannot describe, which is a finding.
No, if it is being sold to you as a package, a monthly retainer line, or a ranking factor. And no if writing it means not doing the work in the section above, which is where the demonstrable gains currently are.
I will update this page when there is something to update it with. If a major provider confirms it reads the file, that sentence changes and the date at the top changes with it.
