How long should the summary blockquote in llms.txt be?

Two to five sentences, roughly 40 to 80 words. The blockquote is the single fragment most likely to travel into an AI answer, so every clause should be quotable on its own: what the site or product is, who it is for, what it contains, and what distinguishes it. Cut adjectives that carry no information — leading, world-class, next-generation — because an engine has no way to verify them and will drop them or paraphrase you into something blander.

Do link descriptions in llms.txt actually matter?

They matter more than the links for anything beyond a naive crawler. A bare URL tells an agent that a page exists; a description tells the agent which question that page answers, which is what retrieval is actually matching on. The specification treats non-link text in a list item as a description, so the format is designed for it. Two rules: name the question the page answers rather than restating its title, and keep one idea per line.

Should llms.txt descriptions reuse my meta descriptions?

Only as a first draft. Meta descriptions are written for a search results snippet — they are truncated around 155 characters, they often open with a call to action, and they are tuned for a human deciding which result to click. An llms.txt description is read by a model deciding whether a page is worth fetching and quoting, so the useful version leads with the subject and the scope, not with an invitation. Rewriting twenty of them by hand takes about an hour, and it is the highest-leverage hour in the file.

Writing · September 2026

llms.txt Descriptions: The Lines That Actually Get Quoted

Structure tells an engine where to look. Prose decides whether it bothers. These are the only three places in your file where you get to write sentences — and most files waste all three.

Three Slots, Three Different Jobs

The llmstxt.org format is deliberately thin: one H1, an optional blockquote summary, H2 sections of links. Everything else in the file is addresses. That leaves you exactly three slots for language, and each one is read differently.

Slot	Who reads it	What it must do
`# Site Name`	Anything parsing the file	Identify the entity, not the tagline
`> Summary`	A model building a first impression of the domain	Be liftable verbatim into an answer
`- [Title](url): text`	Retrieval deciding which URL to fetch	Name the question the page answers

The Summary Blockquote: Write It to Be Quoted

The blockquote under your H1 is the most reusable string in the file. An agent that has just discovered your domain needs a working model of it in one read, and a summary that reads like a landing page hero gives it nothing to hold: we help modern teams do more is not a fact, and a model with no verifiable claim will simply move on to another source.

A summary that survives being quoted answers four things in order:

What it is. The category of thing, in the words a person would search for.
Who it is for. The audience is often the strongest filter in a retrieval step.
What is inside. Docs, API reference, changelog, comparisons — the shape of the site.
What is distinctive. One concrete differentiator, ideally a number or a constraint.

Keep it to two to five sentences. And write it in the third person: an engine quoting the phrase we help teams has to rewrite the pronoun to place it in an answer, and every rewrite is a chance to lose your framing. The site is or the entity name itself travels intact.

Link Descriptions: Name the Question, Not the Title

The text after the colon is the second most valuable real estate in the file and the most commonly automated into sludge. A description that repeats the page title adds nothing a model could not derive; a description that names the specific thing the page covers is what a retrieval step can actually match against a user's question. The examples people cite most often make the same point: Pricing is weak, plan comparison with feature breakdown and current monthly prices is strong.

Three patterns to prefer over restating the title:

Scope lines. "Covers retention, funnel and cohort analysis — not marketing attribution."
Question lines. "Answers whether the free tier includes API access, and what the rate limits are."
Constraint lines. "Lists supported SDKs and the minimum runtime version for each."

The negation in the first pattern looks odd in marketing copy and reads perfectly to a model: it bounds the page. Descriptions are also the place to disambiguate near-duplicate pages, which is the problem behind most duplicate-link findings in a structural validation pass.

Before and After: One Section, Rewritten

Same links, same order. Only the descriptions changed:

## Documentation
- [Quickstart](https://example.com/docs/quickstart.md): Get started
- [Data model](https://example.com/docs/data-model.md): Our data model
- [API reference](https://example.com/docs/api.md): API docs

## Documentation
- [Quickstart](https://example.com/docs/quickstart.md): Install the SDK, send a first event and verify it in the live explorer
- [Data model](https://example.com/docs/data-model.md): How events, users and accounts are keyed, including identity-resolution rules
- [API reference](https://example.com/docs/api.md): Every endpoint with request and response schemas, plus per-plan rate limits

The second version is longer by roughly forty words and worth every token: it is the difference between an agent knowing three files exist and knowing which one answers the question it was given. The full set of writing conventions lives in the llms.txt best practices guide.

Length Discipline: Descriptions Are a Budget

The whole file is read in one fetch, so every extra clause competes with the links that deserve the context window. Practical limits that read well in practice:

Summary: 40–80 words. Past 100 it stops being quotable and starts being ignorable.
Link description: 8–20 words. Long enough to add information, short enough to scan.
No sentence that only fills space — "read more about our great features" is a token spent on nothing.

Descriptions are also the fastest way to leak or over-promise. Anything you would not put on a public page does not belong in a description either; the categories are listed in what not to include in llms.txt.

A Twelve-Minute Rewrite Pass

Read your blockquote aloud and delete every adjective you cannot measure.
Cover the page titles and read only the descriptions. Can you tell what each page contains? If not, rewrite.
Check that no two lines describe the same page in different words.
Confirm each description is true of the page it points at — copy that describes a retired feature is worse than no copy.
Re-run the file through the llms.txt checker to confirm the structure still parses after your edits.

If you would rather start from a working skeleton than an empty file, paste your sitemap into the llms.txt generator and spend your time on the three slots that need a human: the H1, the summary, and the descriptions.