# llms.txt best practices

> Rules for an llms.txt file that helps: curate hard, write descriptions that could be wrong, state your limits, stay current. Plus the mistakes that break files.

Source: https://llmstextgenerator.com/llms-txt-best-practices/
Last updated: 7 October 2026

The format is easy. Writing a file that actually helps is a bit harder. These are the rules that separate a useful file from a reformatted sitemap.

**The best llms.txt files are short, specific and current.** They list only the pages that answer real questions, describe each one in a sentence that contains facts, state the site’s limits up front, and are regenerated whenever the site changes.

## How many pages should you list?

Fewer than you think. The single biggest mistake is listing everything. A file with four hundred links has no priority signal left in it; it has become a sitemap with extra steps. Cut until every remaining entry earns its place, then cut a bit more. Fifteen to a hundred links suits most sites.

## What makes a good description?

A useful description could be wrong. “Comprehensive pricing information” cannot be wrong because it says nothing. “Three plans from USD 12 to USD 79 per seat per month” can be checked, and that is exactly why it is useful.

```
Weak:   - [Docs](https://example.com/docs): Our documentation.
Better: - [Docs](https://example.com/docs): REST API reference, SDK guides for Python, Go and Node, and webhook setup.
```

## State your limits in the summary

Models make confident recommendations. If you only ship to Australia, only work with enterprise clients, or do not offer the thing people assume you offer, say so in the blockquote. One clause prevents a lot of misdirected enquiries and a lot of wrong answers.

## Group by what visitors want, not your org chart

Sections named Products, Pricing, Documentation and Support map onto the questions people actually ask. Sections named after internal teams do not.

## How do you keep it in sync with reality?

A stale file is worse than none, because it will be trusted. Old prices and discontinued products get repeated back to customers as fact. Regenerate after any structural change, and review quarterly regardless.

**Automate it if you can.** Generating the file at build time from the metadata you already maintain removes the drift problem entirely. Static site generators and frameworks make this straightforward; see the [Next.js guide](https://llmstextgenerator.com/llms-txt-nextjs/).

## Which mistakes break an llms.txt file?

| Mistake | What happens |
| --- | --- |
| Relative URLs | Cannot be resolved once the file is read on its own. Always use absolute URLs. |
| Served as `text/html` | Parsers reject it even though it looks fine in a browser. |
| Only a file at `/docs/llms.txt` | Readers written before V2 only check the root. A subdirectory file is valid under V2, but keep one at the root too. |
| Blocked by your own `robots.txt` | The file cannot be fetched at all. Check your disallow rules with the tester. |
| Keyword-stuffed descriptions | Reads as spam to a model exactly as it does to a person. |
| Listing paginated archives | Fills the file with near-duplicate entries carrying no information. |
| Several H1 headings | The title becomes ambiguous; some parsers take the wrong one. |
| Copying a competitor’s file | You end up describing their business. It happens more than you would think. |

## Do not oversell it

If you are doing this for a client, describe it accurately: a cheap, sensible piece of housekeeping for an emerging convention, with no measurable ranking benefit and uneven adoption. Google itself says AI features need no special files ([Google’s guidance on AI features](https://developers.google.com/search/docs/appearance/ai-features)). Promising traffic gains from an `llms.txt` file is not defensible, and it sets up a conversation you will lose in three months.

## A checklist before you publish

- One H1 with the real site name
- A blockquote summary containing at least one qualifier or limit
- Three to six H2 sections named for what visitors want
- Absolute URLs in Markdown link syntax
- A specific, one-line description on every link
- `## Optional`, if used, holds only secondary links and sits at the end
- Served as plain text from the domain root with an HTTP 200
- Not disallowed in `robots.txt` (see [Google’s robots.txt introduction](https://developers.google.com/search/docs/crawling-indexing/robots/intro))
- [Validated](https://llmstextgenerator.com/llms-txt-validator/), and opened in a browser to confirm

## Frequently asked questions

How long should the file be?

Most good files are 2 to 10 KB. Length is not the target: if you need 20 KB to describe a large documentation site honestly, that is fine. If you need 200 KB you are listing too much.

Should I mention my competitors?

No. Describe your own site. Comparison pages are fine to list as pages, but the file is not the place for positioning against other companies.

Can I use it to influence how models describe me?

That is essentially what it is for, within honest limits. Write an accurate summary you would be happy to see quoted. Marketing claims you cannot support will read as noise.
