llms.txt for documentation sites

The 30-second answer: llms.txt on a documentation site is mostly generated, so your job is curation

As of September 2026, Mintlify and GitBook serve /llms.txt, /llms-full.txt, and a Markdown version of every page without any configuration. Docusaurus and VitePress have no built-in support; a community plugin generates the same three things during the production build.

Every generator we looked at links every published page. The Vite docs index has 43 links, Mintlify’s own docs 117, and GitBook’s documentation 711. The llms.txt spec describes a short, curated index with a sentence per link, so the work that remains after installation is editorial: write the description, exclude what should not be there, decide how versions and languages are split, and keep llms-full.txt to a size an assistant will actually load.

What each platform gives you

One detail that is easy to miss: on Mintlify, GitBook, and VitePress the links inside llms.txt point at the .md copies, not at the HTML pages. An assistant that follows the index gets clean Markdown without navigation and scripts. That is a large part of why documentation sites see more benefit from the file than marketing sites do.

What the generated files look like in practice

Measured on September 29, 2026, by fetching the public files directly:

• Vite (VitePress plugin): llms.txt is 3.5 KB with 43 links, grouped under Introduction, Guide, and so on, after a short project description. llms-full.txt is about 430 KB.
• Vue.js (VitePress plugin): 7.4 KB, 94 links, organized as the sidebar is.
• Mintlify’s own docs: 23 KB and 117 links. Mintlify caps a generated index at 100,000 characters and, beyond that, keeps the root file as a directory that points to group files under /_llms/. llms-full.txt is about 1.7 MB.
• GitBook’s documentation: 124 KB and 711 links, one per published page, each with the page description as its annotation. llms-full.txt is about 460 KB.

The pattern is clear. Generated indexes are complete and current, which hand-written ones rarely are, and they carry no opinion about what matters, which is exactly what the spec asks an index to carry. The rest of this guide is about adding that opinion without giving up the automation.

Setup, platform by platform

Mintlify

Nothing to install. The H1 is your site name and the blockquote comes from the description field in docs.json, so that field is the one to write carefully. Mintlify also inserts an agent-instructions block after the description and sends Link and X-Llms-Txt response headers that tools use to discover the file. To take over, put an llms.txt at the project root; the generated version returns if you delete it.

GitBook

Nothing to install. Append .md to any published page URL for its Markdown, and /llms.txt or /llms-full.txt to the site root. GitBook also exposes a Model Context Protocol server for every published site. Because the index is built from page titles and descriptions and GitBook documents no way to edit it, the lever you have is the description on each page: a one-line description becomes the annotation next to the link.

Docusaurus

Install the community plugin and add it to the plugin list. Files are written only by the production build, not by the dev server.

npm install docusaurus-plugin-llms --save-dev

// docusaurus.config.js
module.exports = {
  plugins: [
    [
      'docusaurus-plugin-llms',
      {
        title: 'Acme CLI',
        description: 'Command-line reference and guides for the Acme deployment tool.',
        ignoreFiles: ['changelog/**', 'blog/**', 'versioned_docs/version-1.*/**'],
        generateLLMsFullTxt: true,
      },
    ],
  ],
};

VitePress

The plugin hooks into Vite’s plugin list rather than VitePress’s own, and writes llms.txt, llms-full.txt, and per-page Markdown into the build output. Its README lists Vite, Vue.js, and Vitest among the projects using it.

npm install vitepress-plugin-llms --save-dev

// .vitepress/config.ts
import { defineConfig } from 'vitepress'
import llmstxt from 'vitepress-plugin-llms'

export default defineConfig({
  vite: {
    plugins: [
      llmstxt({
        title: 'Acme CLI',
        description: 'Command-line reference and guides for the Acme deployment tool.',
        ignoreFiles: ['changelog.md', 'blog/*'],
      }),
    ],
  },
})

Five decisions the generator cannot make for you

1. The description. It is the only line an assistant is sure to read, and every tool takes it from a config field. One sentence: what the product is, who it is for, and what the docs cover. “Documentation for Acme” says nothing; “CLI reference and deployment guides for Acme, a tool for shipping containers to bare-metal servers” does.
2. What to leave out. Changelogs, release notes, blog posts, and old versions add hundreds of links that compete with the pages you want quoted. Every plugin has an ignore option; use it. On hosted platforms, unpublish or archive what you would otherwise exclude.
3. Versions. Link the current version from the root index. If older versions must stay reachable, put them under an ## Optional section so a reader with a small budget stops before them.
4. Languages. One index per locale, each at its locale root, is easier to use than a mixed file. The VitePress plugin handles i18n routes; Mintlify splits locale groups into separate files; on Docusaurus, generate per locale build.
5. The size of llms-full.txt. The bundle is where documentation sites get the most value, and also where they overshoot. Around 400 to 500 KB, as on the Vite and GitBook docs, is comfortable. Above a couple of megabytes, drop the auto-generated API reference from the bundle and keep it in the index only.

Checking the result

After deploying, fetch the files the way a crawler would and look at the first lines and the link count:

curl -sL https://docs.example.com/llms.txt | head -12
curl -sL https://docs.example.com/llms.txt | grep -c '^- \['
curl -sL https://docs.example.com/guide/getting-started.md | head -5
curl -sI https://docs.example.com/llms-full.txt | grep -i -E 'content-(type|length)'

The first command should show your H1 and a blockquote that reads like a description, not a placeholder. The second tells you whether the index is curated or a dump. The third confirms that the per-page Markdown is really served. Then run the site through a validator to catch a missing H1, links with the wrong base URL after a domain change, and headings the generator produced as H1 instead of H2.

FAQ