llms.txt generator and validator

llms.txt is a markdown file you publish at the root of your domain — https://example.com/llms.txt — that lists the pages on your site worth reading, with a one-line description of what the site is. It exists because a language model given your rendered HTML has to spend most of its context on navigation, cookie banners and boilerplate before it reaches anything you wanted it to read.

It is a proposal, published at llmstxt.org, not a standard any AI company has committed to honouring. We publish our own llms.txt and a longer llms-full.txt, which is why we built this tool. Being straight about its status matters: adopt it because it costs an hour and makes your site legible, not because someone promised you citations for it.

The specification is short. A valid file has, in this order:

• An H1 with the name of the site or project. This is the only element the spec requires.
• A blockquote summary — optional, but it is the one line a model reads to decide whether the rest is relevant to the question it is answering. Write it deliberately.
• Optional prose giving more context. No headings in this part.
• H2 sections, each containing a markdown list of links in the form - [name](url): optional notes.
• A final section named Optional, if you want one. Its links are the ones a model should drop first when it needs a shorter context.

# Attensira

> Attensira tracks how AI assistants answer questions about your category and
> opens pull requests against the pages that need to change.

## Core pages

- [Home](https://attensira.com/)
- [Pricing](https://attensira.com/pricing)

## Tools

- [Schema markup validator](https://attensira.com/tools/schema-validator)
- [XML sitemap validator](https://attensira.com/tools/sitemap-validator)

## Optional

- [Glossary](https://attensira.com/glossary)

The validator checks exactly those rules and reports the line number for each failure. It does not score the file: a spec is followed or it is not, and a percentage in between would be a number we invented.

Nothing here is written by a model. The generator is deterministic — the same site produces the same file — and every value in the output comes from something it actually read:

• It finds your sitemap: the URL you gave it, or a Sitemap: line in your robots.txt, or /sitemap.xml, /sitemap_index.xml and /sitemap-index.xml in that order.
• If that is a sitemap index, it reads the first five child sitemaps and says so in the result.
• URLs are grouped into sections by their first path segment — /blog/* becomes a Blog section, /docs/* becomes Documentation — and shortest paths come first, because a section root is usually more useful than a leaf.
• Link text comes from the last path segment, de-slugified. The H1 comes from your og:site_name or your homepage title. The summary comes from your homepage meta description; if you have none, the line is left blank for you to write rather than filled with a guess.
• Sections are capped at 25 links so the file stays readable.

Treat the output as a first draft. A generated list of every URL on your site is not an llms.txt worth publishing — the value of the file is in what you leave out.

• Serve it as text/plain. The most common failure this validator finds is an HTML 404 page returned with a 200 status, because the file was never deployed and a catch-all route answered instead.
• Absolute URLs only. A model reading the file has no base to resolve a relative path against.
• Write the summary yourself. One sentence saying what the site is and who it is for. This is the highest-leverage line in the file.
• Curate. Twenty pages that answer real questions beat two thousand URLs. Leave out tag archives, pagination and thin pages.
• Keep it in sync. A file listing URLs that now 404 is worse than no file. Generate it in your build, or set a reminder.
• It is not an access control. llms.txt invites reading; it cannot prevent it. Whether a crawler may fetch your pages at all is decided in robots.txt.