llms.txt for Documentation Sites: Mintlify, GitBook, Docusaurus, and VitePress

Of all the places an llms.txt file can live, documentation sites are where it earns its keep. The format's own specification says so: llms.txt files "are used most heavily for software documentation, where coding agents follow them to find API references and tutorials." A coding agent that needs to call your API correctly does not want your navigation bar, your cookie banner, or your JavaScript bundle. It wants clean text.

This guide covers how the major documentation platforms handle llms.txt today, what to do when your platform does not generate it, and how to apply the second version of the specification published in 2026.

What changed in the llms.txt specification

The llms.txt proposal was first published in September 2024. Its author released version 2 in August 2026, after two years of adoption. According to the site, thousands of sites now publish an llms.txt file, documentation platforms generate one automatically, and Chrome's Lighthouse checks for one as part of its agentic browsing audits. The AI labs also publish the file for their own developer documentation: the specification page lists OpenAI, Anthropic, and Gemini as examples.

For documentation owners, the changes that matter are these:

• Discoverability through standard link relations. A page can point to its Markdown version with rel="alternate" type="text/markdown", and to the llms.txt file that covers it with rel="describedby". You can provide these as HTML <link> elements or an HTTP Link: header.
• Two URL forms for Markdown pages. Version 1 specified appending .md to the full page URL (page.html.md). Version 2 also allows replacing the extension (page.md). URLs without a file name should append index.html.md.
• Files in subpaths now have a defined meaning. A file covers the pages under its path, and when several apply, the most specific one wins. This lets a site that controls only a path, such as a GitHub Pages project site, participate fully.
• Consumption is described plainly. Agents are expected to read or search the llms.txt, then follow the relevant links, which should point to LLM-friendly content. The context-expansion tooling from version 1 is no longer part of the proposal, and the Optional section no longer has mechanical meaning. It remains a useful convention for secondary links.

The required structure is unchanged: an H1 with the project name (the only required part), an optional blockquote summary, optional free-form sections, and zero or more H2 sections that contain lists of links, each as [name](url) with optional notes after a colon.

# Acme API

> Acme is a payments API. These docs cover authentication, payments, webhooks, and SDKs.

Prices and limits are listed on the pricing page. All amounts are in minor currency units.

## Docs

- [Quickstart](https://docs.acme.example/quickstart.md): Create a key and make a first payment
- [Authentication](https://docs.acme.example/authentication.md): API keys, scopes, rotation
- [Webhooks](https://docs.acme.example/webhooks.md): Event types, retries, signature verification

## Reference

- [Payments API](https://docs.acme.example/api/payments.md): Create, capture, refund
- [Errors](https://docs.acme.example/errors.md): Error codes and recommended handling

## Optional

- [Changelog](https://docs.acme.example/changelog.md): Release history

An important caveat applies to this and every other llms.txt discussion: it is an emerging convention. Publishing it does not guarantee that any particular assistant or search engine uses it. Google, for example, says in its guidance on AI features in Search that you do not need new machine-readable files or AI text files to appear in AI Overviews or AI Mode. Documentation is a different case because coding agents and developer tools fetch docs directly, and a clean index saves them effort.

Mintlify

Mintlify generates llms.txt and llms-full.txt automatically for the documentation sites it hosts. According to its documentation:

• You view the file by appending /llms.txt to your docs URL. Mintlify also hosts it at /.well-known/llms.txt for tools that follow the well-known convention.
• The file follows the specification: an H1 site title, a blockquote description taken from the description field in docs.json, optional custom agent instructions if you set markdown.instructions, structured sections with a description for each page, links to OpenAPI and AsyncAPI specifications, an Optional section for external links, and an attribution line (omitted when Mintlify branding is removed).
• Pages appear in the order of your docs.json navigation. Pages outside the navigation that your indexing setting includes appear last, alphabetically. Links include a .md extension so tools can fetch the Markdown version.
• Mintlify adds HTTP headers to responses: a Link header advertising llms.txt, llms-full.txt, and other discovery resources, and an X-Llms-Txt header as a convenience for tools that check support.
• Generated index files cannot exceed 100,000 characters. When the index would be larger, the main llms.txt becomes a directory and groups of page links move into generated index files under /_llms/. If you use a reverse proxy or a path allowlist, forward that route as well.
• You can override either file by creating llms.txt or llms-full.txt at the project root. A custom file replaces the generated one, and if you delete it, the generated version returns. A custom file must have a site title as an H1.

How authentication interacts: on fully authenticated sites both files require authentication, so tools that cannot sign in cannot read them. On partially authenticated sites both files are public but list only public pages.

Practical tip: if you run a reverse proxy in front of Mintlify under a path such as /docs, test /docs/llms.txt, /docs/llms-full.txt, and a generated /docs/_llms/... index in production. Links that point at the wrong prefix are the most common failure.

GitBook

GitBook documents a set of LLM-ready formats for published sites:

• Markdown pages. Append .md to any published page URL. For the root landing page, add /.md to the site URL.
• /llms.txt. An index of every published page that has a Markdown version.
• /llms-full.txt. The full documentation content in one file. GitBook notes that hidden pages are included, because hiding a page only removes it from the published table of contents.
• An MCP server for each published docs site, available by appending /~gitbook/mcp to the site root. Opening it in a browser returns an error, because it expects an MCP client.

GitBook also provides an Agents and MCP report in site analytics to measure traffic from language-model clients and MCP clients, which is a useful complement to the analytics approach in our guide to tracking AI traffic in GA4.

The hidden-pages note is worth acting on. If you hide a page because it is draft, internal, or deprecated, remember that it can still appear in llms-full.txt and the MCP server. Remove or restrict content that must not be public instead of only hiding it.

Docusaurus

Docusaurus does not generate llms.txt out of the box. The community plugin docusaurus-plugin-llms, listed on the specification site, generates LLM-friendly documentation following the llms.txt standard. Evaluate it like any build plugin:

1. Install it and add it to docusaurus.config.js.
2. Build the site and inspect build/llms.txt and any full-text file.
3. Verify that versioned docs are handled the way you want. Agents should usually see the current version, not every historic one.
4. Check that excluded and draft pages stay out.
5. Deploy and confirm https://yourdomain/llms.txt returns 200 with a text or Markdown content type, not your 404 page.

If you prefer to keep control, a short build script that reads your sidebar and front matter and writes static/llms.txt is a few dozen lines, and it avoids a dependency.

VitePress and other static generators

The specification site lists vitepress-plugin-llms, a plugin that generates LLM-friendly documentation for VitePress sites. For other generators such as Docusaurus alternatives, Astro Starlight, MkDocs, or Hugo, the pattern is the same:

1. Decide which pages are canonical and public.
2. Produce a Markdown version of each page. If your source is already Markdown, publish the cleaned source at a predictable URL.
3. Generate llms.txt from your navigation, with a one-line description from each page's front matter.
4. Optionally generate llms-full.txt as a concatenation, with a clear separator and the source URL before each page.
5. Fail the build if a listed URL does not exist.

The last step prevents the most embarrassing failure: an index that links to pages you deleted.

A hand-written file is fine

You do not need a platform plugin. For a small docs site, a hand-written file is perfectly reasonable. Follow these guidelines from the specification: use concise, clear language, include brief informative descriptions for each link, avoid ambiguous terms and unexplained jargon, and test the file by asking an agent questions about your content while giving it only the llms.txt as a starting point. That last test is simple and revealing. If the agent cannot find how to authenticate from your file, a human skimming it cannot either.

Subpath files for large sites

If your documentation lives under /docs/ on a larger company site, version 2 makes a subpath file meaningful: /docs/llms.txt covers pages under /docs/, and the most specific file wins. The specification's own example is the FastHTML project, which places its file at /docs/ to cover only the documentation pages.

A sensible layout for a company with a marketing site and docs:

• /llms.txt: what the company does, pricing and policy pages, and a pointer to the docs file.
• /docs/llms.txt: the documentation index, with API reference and guides.
• /docs/llms-full.txt: optional full text for tools that want one file.

Remember that each file should stay small enough to fit in a context window, and that linking to Markdown versions of pages is what makes the index useful.

Publish Markdown twins of your pages

The strongest improvement you can make beyond the index is Markdown twins: clean text versions of each page at a predictable URL. The specification asks pages with information agents might need to provide a clean Markdown version at the page URL with .md appended, or with the extension replaced by .md. Then advertise the relationship:

Link: </docs/payments.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"

Or in HTML:

<link rel="alternate" type="text/markdown" href="/docs/payments.html.md">
<link rel="describedby" href="/docs/llms.txt">

Mintlify and GitBook already do the first part for hosted sites. On a custom stack you add it yourself.

Quality rules for documentation indexes

1. One line per link, written for a machine and a human. "Authentication: API keys, scopes, rotation" beats "Click here."
2. Group by task, not by team. Agents ask "how do I authenticate," not "what did the platform team write."
3. State constraints directly. If the free tier limits requests, say so in the summary or in the relevant page description.
4. Keep it current. Generate it in CI, or review it when you release.
5. Do not list private URLs. Check authentication behavior. If a custom file links to a non-public page, only authenticated users can read it on platforms that respect authentication.
6. Version carefully. Point to the latest version, and add separate files for older versions only if agents need them.
7. Do not paste secrets or internal notes. The file is public.

How to test it

1. Fetch the file with curl -i https://docs.example.com/llms.txt and confirm a 200 status and a text or Markdown content type.
2. Open every link. A script that loops over the list and reports non-200 responses takes minutes to write.
3. Run the llmsmap audit for crawler access and llms.txt checks.
4. Ask an assistant a question your docs answer, providing only the llms.txt, and see whether it finds the right page.
5. If you use Lighthouse, note how its agentic browsing check behaves: it flags pages if a server error occurs when fetching llms.txt, and treats a 404 as not applicable because the file is optional at the moment.

For general structure and templates, see llms.txt examples, the llms-full.txt guide, and the comparison with robots.txt and sitemap.xml. If your docs sit behind Cloudflare, check that your bot settings do not block the agents you want to serve, using the AI Crawl Control guide.

FAQ

Does Mintlify create llms.txt automatically?

Yes. Mintlify generates llms.txt and llms-full.txt for hosted documentation sites, and you can override them with custom files at the project root.

Does GitBook support llms.txt?

Yes. GitBook publishes /llms.txt, /llms-full.txt, Markdown versions of pages with a .md suffix, and an MCP server for published sites.

Is there an official Docusaurus llms.txt feature?

The specification site lists a community plugin, docusaurus-plugin-llms. Docusaurus itself does not generate the file by default.

Do I need llms-full.txt too?

No. The index is the core file. A full-text file is optional and useful for tools that prefer a single document, provided it stays accurate and avoids private content.

Where should the file live if my docs are under /docs/?

Either /llms.txt at the root with a pointer to the docs, or /docs/llms.txt covering only the docs. Under version 2 of the specification a subpath file covers the pages under its path.

Will llms.txt improve my Google rankings?

There is no confirmed ranking effect, and Google says no special files are needed for its AI features. For developer documentation the benefit is mainly easier consumption by coding agents and tools. See the evidence-based analysis.

Summary

Documentation sites are the best-established use of llms.txt. Mintlify and GitBook generate the files and Markdown pages for you, Docusaurus and VitePress rely on community plugins, and a hand-written file works for small sites. Follow version 2 of the specification by publishing Markdown twins, advertising them with link relations, and using subpath files for docs under a larger site. Then test the result with a real agent and a link checker.