The 30-second answer: the Optional section holds what is useful with budget and unnecessary without it
The spec says the Optional section is used, by convention, for secondary information: links an agent can skip when a shorter context is needed. That is the test. For each link, ask whether an assistant that never follows it can still describe your site correctly and answer the common questions. If yes, the link is Optional material. If no, it belongs in a named section above.
Three consequences follow. Keep it last, so a reader that stops early has seen the important part. Keep it short, because a section of a hundred links is not secondary information, it is an unsorted index. And annotate each link anyway; a reader with budget deserves to know what the link is before fetching it.
What the spec says, and what v2 changed
The llms.txt specification at llmstxt.org defines the file as an H1, an optional blockquote summary, optional free-form Markdown, and zero or more H2 sections each holding a list of links. Its mock example ends with ## Optional, and the text adds one sentence: the section is used by convention for links an agent can skip when a shorter context is needed.
In the original 2024 proposal that sentence had teeth. The proposal shipped with context-expansion tooling that read llms.txt, fetched the linked pages, and assembled a prompt; when the prompt had to be shorter, the tooling omitted everything under Optional. The August 2026 revision removed that tooling from the proposal and says so in its change notes: Optional sections are still allowed and remain a useful convention for secondary links, but they no longer carry mechanical semantics.
So in September 2026 the section is a label, not a mechanism. It tells any reader, human or model, which links the author considers secondary. Whether a given assistant honors that is up to the assistant, which is one more reason to keep the primary sections self-sufficient.
How real files use it
We saved 28 public llms.txt files on September 19, 2026, for the examples article. Eleven have an Optional section (two of them are the same Vercel file served at two paths). What they put there falls into a few patterns:
- Community, blog, support, changelog. The most common pattern and the most sensible. Bun lists its reference and blog; Perplexity’s docs list community and blog; Stripe’s docs list support and the changelog. Two links each.
- Upstream or third-party documentation. FastHTML, the spec author’s own project, puts 14 of its 21 links under Optional, including a Starlette documentation extract and a tiny JavaScript library the framework builds on. Useful for deep questions, skippable for most.
- Machine-readable extras. Vercel lists an experimental agent resource catalog, a product taxonomy, and a documentation graph, all JSON. Cloudflare’s marketing site uses Optional for a single link to its llms-full.txt.
- Other languages. This site’s own file lists its eight non-English versions under Optional, after the spec link.
- The dumping ground. Hono puts 87 of its 90 links under Optional, which is every middleware page; the section is the file. Stripe’s marketing site puts 153 of 305 links there, all resource articles. In both cases a named section would have told a reader what the links are.
The other 17 files have no Optional section, including Anthropic, Cloudflare’s developer docs, Next.js, Svelte, and Tailwind. That is also fine: when a generator produces a complete index, there is nothing secondary to separate.
What belongs there and what does not
| Belongs in Optional | Belongs in a named section |
|---|---|
| Changelog and release notes | Getting started and installation |
| Blog, community, newsletter | Pricing, plans, and limits |
| Support and contact entry points | The core guides and reference people ask about |
| Upstream or dependency documentation | Shipping, returns, and policies written out (for stores) |
| Other language versions of the site | The page that answers your single most common question |
| Machine-readable extras: llms-full.txt, JSON catalogs, OpenAPI | Anything with more than a dozen links (give it its own H2) |
| Older versions, migration guides from retired releases | Legal pages: usually leave them out entirely |
The left column shares one property: each item is something a reader asks for by name. Nobody discovers your product through the changelog, but someone who already uses it may want it. The right column is what an assistant needs to describe you accurately to someone who has never heard of you.
Writing it
Place it last. Name it exactly Optional, since the convention is the word. Keep it under about ten links; if it grows past that, promote a group to its own section with a name that says what it is. Annotate every link with the same one sentence you would write anywhere else in the file, because a reader with budget has to decide whether to follow it.
## Optional - [Changelog](https://acme.example/changelog): Release notes, newest first. - [Blog](https://acme.example/blog): Product announcements and engineering posts. - [Community forum](https://community.acme.example): Questions answered by other users and staff. - [llms-full.txt](https://acme.example/llms-full.txt): Full text of the guides above, in one Markdown file. - [日本語版](https://acme.example/ja/llms.txt): This file in Japanese.
Two things to avoid. Do not use Optional as the place for links you could not categorize; the fix for an uncategorized link is a category. And do not put the one page that answers your most common question there because it felt secondary to you. The test is the reader’s question, not your org chart.
Checking the result
Fetch the file and look at the last section: it should be Optional, short, and annotated. A validator lists every link it found, which is where the length shows.
Validate your llms.txt
Paste your site URL and the validator fetches /llms.txt, checks the structure against the spec, and lists every section and link it found.
Open the validator →FAQ
Is the Optional section required?
No. The only required element in llms.txt is the H1. The Optional section is a convention the spec describes and uses in its own example; a file without one is fully valid. Add it when you have secondary links worth keeping, and leave it out when everything in the file is primary.
Does an AI actually skip the Optional section?
Nothing guarantees it. Under the v1 spec, context-expansion tooling dropped Optional links when building a shorter prompt. The v2 revision of August 2026 removed that tooling from the proposal, so Optional no longer has mechanical meaning. Treat it as a signal to readers, human and machine, about priority, not as a switch.
Should it be the last section?
Yes, by convention and for a practical reason: a reader that stops early should have seen everything important first. The spec example puts it last. Mintlify's generated file is a rare exception that places an Indexes section after Optional, and that is a quirk of the generator, not a pattern to copy.
Can I put hundreds of links under Optional?
You can, and some sites do: in the files we sampled, one framework puts 87 of its 90 links under Optional and one company puts 153 of 305. That turns the heading into a dumping ground and makes the whole file read as low priority. If a section needs hundreds of links, it needs its own H2 with a name, or it belongs in llms-full.txt rather than in the index.
What about legal pages, pricing, and support?
Pricing and support are usually primary, because they answer questions people ask assistants; put them in a named section. Legal pages are usually not worth linking at all. Support, community, and changelog links are the most common Optional entries in real files, and that placement is right: useful when there is budget, not needed to understand the product.
Next steps
- → The llms.txt spec, explained line by line (the full v2 text, clause by clause)
- → llms.txt examples: 8 real files, annotated (the files sampled above, read in full)
- → How to write llms.txt by hand
- → All Learn articles