llms.txt explained: what the v2 spec actually requires
An H1 is the only element the llms.txt specification requires, llms-full.txt is not in the spec at all, and no answer engine documents reading either file.
The answer
An llms.txt file has exactly one required element: an H1 with the name of the project or site. Everything else the specification describes is optional, including the summary blockquote and the link sections that make the file useful. No answer engine currently documents consuming llms.txt, so publishing one is a cheap bet on a convention rather than a fix for a measurable problem. Publish it anyway if your content is documentation-shaped; skip the anxiety if it is not.
The rest of this page is what the llmstxt.org v2 specification actually says, which differs from most of what is written about it.
The specification, in the order it specifies
Source: "The /llms.txt file, v2" by Jeremy Howard at llmstxt.org, published 2024-09-03 and modified 2026-08-10. The required order is:
- An optional byte-order mark.
- An H1 with the name of the project or site. This is the only required section.
- A blockquote with a short summary containing the key information needed to understand the rest of the file.
- Zero or more markdown sections of any type except headings — paragraphs, lists — giving more detail.
- Zero or more sections delimited by H2 headers, each containing a file list: a markdown list where every item has a required hyperlink, then optionally a colon and notes.
An H2 named literally ## Optional is, by convention, secondary material an agent may skip when it needs a shorter context. That is the only section name with defined meaning.
A conformant file
# Acme Widgets
> Acme sells industrial widgets. This file indexes the pages an assistant
> should read to answer questions about pricing, the HTTP API, and returns.
> Prices are USD and change on the first of each month.
Every URL below is canonical and also available as markdown by appending
.md to the path. Pages not listed here are marketing or archived.
## Product
- [Widget catalog](https://acme.example/widgets.md): all 40 SKUs with dimensions and load ratings
- [Pricing](https://acme.example/pricing.md): per-unit and volume pricing, updated monthly
- [Returns policy](https://acme.example/returns.md): 30-day window, restocking terms
## API
- [Authentication](https://acme.example/docs/auth.md): API keys, scopes, rotation
- [Orders endpoint](https://acme.example/docs/orders.md): create, amend, cancel
## Optional
- [Company history](https://acme.example/about.md)
- [Press releases](https://acme.example/press.md)Four v2 rules that most write-ups get wrong
It may live at any path
v2 dropped the root-only assumption. /docs/llms.txt covers everything under /docs/, and where more than one file applies an agent should use the most specific. This is in production already: OpenAI publishes a root file at developers.openai.com/llms.txt plus per-product children at /api/llms.txt, /codex/llms.txt and /commerce/llms.txt, all verified by direct fetch on 2026-08-21.
The spec explicitly rejects /.well-known/
The reasoning is stated: well-known URIs under RFC 8615 exist only at the origin root, and many authors control only a path on a shared host. If you have read advice to move the file to /.well-known/llms.txt, that advice contradicts the specification.
Discovery has defined link relations, including a header form
Two relations: rel="alternate" type="text/markdown" points at the markdown version of the current page, and rel="describedby" points at the llms.txt that covers it. Both work as HTML <link> elements or as an HTTP Link: response header. The header form is the useful one, because it also covers non-HTML resources and can be set at a CDN without touching a single page.
Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"The companion proposal behind rel="alternate": serve a clean markdown version of each page at the same URL with .md appended, as page.html.md, or with the extension replaced, as page.md. Directory URLs use index.html.md or index.md. Projects built with nbdev emit markdown versions of every page by default, which is why the fast.ai and Answer.AI sites satisfy this without anyone doing extra work.
llms-full.txt is not in the specification
The v2 text contains no such filename. llms-full.txt is a convention popularised by documentation platforms, Mintlify in particular (Mintlify llms.txt documentation), denoting one file with the entire documentation corpus concatenated rather than a curated index of links. The distinction the specification does draw cuts against it: the file "stays small enough to fit in context. The detail lives behind the links, and is fetched only when needed". Treat a full-text dump as a positive but non-normative extra. It is not spec-required, and nothing should score you down for lacking it.
What it is not
llms.txt is not an access control. The specification is explicit that it complements robots.txt: "robots.txt lets automated tools know what access to a site is considered acceptable; llms.txt information is instead used on demand". Listing a page in llms.txt does not grant permission you withheld in robots.txt, and omitting a page from llms.txt does not withhold anything. If you want a crawler kept out, that belongs in robots.txt.
It is also not a sitemap replacement, and the spec gives three reasons: sitemaps do not indicate markdown versions, they exclude external URLs, and in aggregate they exceed a context window. The author's stated expectation is that the file "would mainly be useful for inference rather than training, and that is how it has been used".
The mechanical conformance checklist
The format is deliberately parseable — "a precise format allowing fixed processing methods (i.e. classical programming techniques such as parsers and regex)" — so a checker can assert this, in order:
| # | Assertion | Severity |
|---|---|---|
| 1 | Response is 200 and the content type is text-ish: text/plain or text/markdown | error |
| 2 | After the optional BOM, the first non-blank block is an H1 | error |
| 3 | Exactly one H1, at the top of the document | warn |
| 4 | If a blockquote is present, it immediately follows the H1 | warn |
| 5 | No headings between the blockquote and the first H2 | warn |
| 6 | Every section after the intro is delimited by H2, with no H3 or deeper at top level | warn |
| 7 | Every list item inside an H2 section contains a markdown link | error |
| 8 | Item notes, where present, follow the link and a colon | info |
| 9 | Links resolve with a 2xx | warn |
| 10 | Links prefer markdown targets over HTML | info |
| 11 | The whole file fits comfortably in a context window | info |
| 12 | An HTML rel="describedby" link or Link: header points at it | info |
Because H1 is the sole hard requirement, a binary pass/fail checker calls almost everything conformant, which is why grading items 3 to 12 separately is the only way the result carries information. Real files miss these. Stripe's docs.stripe.com/llms.txt, fetched 2026-08-21, follows its H1 with a prose paragraph and no blockquote, and carries an ## Instructions for Large Language Model Agents section with prescriptive directives such as never recommending a particular deprecated API. Useful, non-conformant on item 4.
Does it affect citation? No engine says so
This is the part worth being blunt about. No answer engine publishes that it consumes llms.txt, and no vendor documentation reviewed for this site mentions the file at all. Anyone telling you llms.txt improves your citation rate is inferring, and there is no published measurement to inspect.
The closest thing to institutional recognition is Chrome's Lighthouse, which ships an llms.txt audit under its agentic-browsing checks (Chrome Lighthouse llms.txt audit, last updated 2026-05-05). Read what it does carefully:
"Lighthouse flags the pages if a server error occurs when attempting to retrieve the llms.txt file. If the file is not provided by the server (resulting in a 404), the audit is marked as Not Applicable (N/A), as providing the file is optional at the moment."
A 404 is neutral. A 5xx is a failure. Google's own tooling declines to penalise absence. If you serve nothing at that path, make sure you serve a clean 404 rather than a 500, because that is the only outcome Lighthouse actually marks against you.
/llms.txt as a deduction. That is a judgement call, not an industry standard, and it is disclosed with its exact point weight on the methodology page so you can subtract it. Our reasoning: a machine-readable index of your own canonical pages costs almost nothing to generate and has no downside. Reasonable people disagree, which is why the weight is published rather than buried.The honest case for publishing one anyway
The strongest evidence that the convention has real uptake is who publishes for their own documentation: OpenAI, Anthropic, Google's Gemini API, Perplexity and Stripe all do, verified or cited during research on 2026-08-21. Labs that would know whether the file is read are publishing it for their own docs. That is suggestive, not proof.
The practical argument is smaller and better. Generating llms.txt from the same source as your sitemap forces you to name your canonical pages, which is an exercise that improves your internal linking whether or not a crawler ever reads the output. Platforms including Mintlify, GitBook, Yoast SEO, AIOSEO and Wix generate it automatically, and there are plugins for VitePress, Docusaurus and Drupal. If it is a checkbox, tick it. If it is a project, do server-side rendering first.
Run a scan to see whether your /llms.txt exists, what content type it is served as, and which of the twelve conformance assertions above it actually satisfies rather than just whether the file is there.