# llms.txt for documentation sites

> Docs sites are the ideal llms.txt use case. How to generate one for Docusaurus, MkDocs, Mintlify and others — plus when to add llms-full.txt and Markdown page versions.

Documentation sites are the ideal llms.txt use case: people constantly ask AI tools "how do I do X in *your product*," and a curated file points those models straight at the right pages.

## Why docs benefit most

Your docs already *are* the answers. llms.txt lets you hand a model a clean index of them — getting started, guides, API reference — instead of letting it crawl navigation, search UIs, and marketing pages.

## Generate it from your structure

Most docs sites already have a `sitemap.xml`. Group those URLs into a few sensible sections rather than dumping them flat:

```
# Acme Docs

> Documentation for the Acme API: setup, guides, and the full endpoint reference.

## Getting started

- [Quickstart](https://acme.com/docs/quickstart): First request in 5 minutes
- [Authentication](https://acme.com/docs/auth): API keys and scopes

## Reference

- [Endpoints](https://acme.com/docs/api): Every endpoint and parameter

## Optional

- [Changelog](https://acme.com/docs/changelog): Release history
```

## Link the Markdown versions

Many docs frameworks (Docusaurus, MkDocs, Mintlify, GitBook and others) can serve a Markdown or plain-text version of each page. Link those — `page.md` — so models parse clean content instead of rendered HTML with nav and sidebars.

## Add llms-full.txt for full context

For larger doc sets, publish a companion [llms-full.txt](/guide/llms-full-txt) with the full text inlined, so an agent can ingest everything in one fetch. Keep llms.txt as the concise index.

## Curate, then validate

Whether you hand-write the file or generate it from a plugin, review the output — auto-generators tend to include too much. See [llms.txt examples](/guide/llms-txt-examples) for patterns, then [validate](/) to confirm the structure and that every link resolves.