To write an llms.txt file, create a Markdown file with an H1 holding your site or project name (the only required element), an optional blockquote summary, and H2 sections — like Docs, Guides or API — each containing a Markdown list of links in the form [name](url): short description. Save it as llms.txt and deploy it at your site root so it resolves at /llms.txt. Keep links curated rather than exhaustive, write descriptions that say what each page actually answers, and make sure the file is valid Markdown. The most common mistakes are dumping every URL, omitting descriptions, and breaking the Markdown structure so the file can't be parsed cleanly.
What are the steps to write a valid llms.txt?
The llmstxt.org format is intentionally minimal, so writing a valid file is mostly about discipline. Begin with the one required element — an H1 with your site name — then layer on the optional pieces that make the file genuinely useful to a model.
After the H1, add a short blockquote summarizing what the site is and who it's for. Then create H2 sections grouping your links by purpose, and under each, list links as Markdown bullets with a colon and a one-line description. Save the file as plain Markdown named llms.txt.
- 1Create a Markdown file named llms.txt.
- 2Add an H1 with the site or project name (required).
- 3Add a one- or two-sentence blockquote summary (optional but recommended).
- 4Create H2 sections that group links by purpose (Docs, Guides, API).
- 5Under each section, list links as - [name](url): short description.
- 6Validate that it's clean Markdown, then deploy at the site root.
What does a good llms.txt look like?
A good file reads like a thoughtful table of contents written for someone who has never seen your site. The site name and summary orient the reader; the sections group related material; and each description tells a model what question that page answers, not just that the page exists.
Curation is the differentiator. The point of llms.txt is to highlight what matters, so resist the urge to mirror your full sitemap. Ten well-described, high-value links beat a hundred bare ones — both for the model's limited context and for keeping the file maintainable.
- Site name and a clear one-line summary at the top.
- Logical H2 sections, not one giant flat list.
- Descriptions that state what each page answers.
- Curated, high-value links rather than your entire sitemap.
What are the most common llms.txt mistakes?
Most broken or useless llms.txt files share a few patterns. The biggest is treating it like a sitemap and dumping every URL with no descriptions — that throws away the whole value of a curated, described map. The second is invalid Markdown: stray characters, broken link syntax or inconsistent heading levels that make the file hard to parse.
Other frequent issues are letting the file drift out of date as pages move or get renamed, linking to pages that aren't actually reachable by crawlers, and overstating what the file does to yourself or stakeholders. Keep it accurate, keep it valid, and keep your expectations honest.
- Dumping every URL with no descriptions (it's a map, not a sitemap).
- Invalid or inconsistent Markdown that won't parse cleanly.
- Letting links rot as pages move or get renamed.
- Linking to pages crawlers can't actually reach.
- Believing — or claiming — it guarantees more AI citations.
Frequently asked questions
What is the only required part of an llms.txt file?+
An H1 containing the site or project name. Everything else — the summary blockquote, the H2 sections and the link lists — is optional in the spec, though sections and descriptions are what make the file actually useful to a model.
Where do I deploy the llms.txt file?+
At your site root, so it resolves at https://yourdomain.com/llms.txt. How you do that depends on your stack — a static file in your public directory, or a route that returns the Markdown with a text/plain content type.
Should llms.txt list every page on my site?+
No. It's a curated highlight reel, not a sitemap. List the high-value pages you most want a model to understand, with a clear description each. A short, well-described file beats an exhaustive, bare one.