Does MkDocs or Material for MkDocs support llms.txt natively?

Not as of 2026. MkDocs ships no built-in llms.txt feature and llmstxt.org's integrations list has no MkDocs entry yet. An open community discussion on the Material for MkDocs repository (squidfunk/mkdocs-material, discussion #8384, 'Add native support to generate llms.txt') shows demand and points to the mkdocs-llmstxt plugin, but until native support ships you choose between a static file and a community plugin.

What does the mkdocs-llmstxt plugin generate?

On every mkdocs build it writes /llms.txt at the site root from your site_name, site_description and the sections you define in mkdocs.yml. Each page you list is also exported as a clean Markdown file, and llms.txt links those .md URLs. Set full_output: llms-full.txt to additionally emit the full-text dump. The plugin requires site_url to build absolute links, and it parses the rendered HTML (via BeautifulSoup and Markdownify) so API docs and injected content are captured.

How do I handle versioned MkDocs docs like Read the Docs (en/latest/)?

The llms.txt spec allows the file at any subpath — /en/latest/llms.txt covers the pages under that path, and agents use the most specific file when several apply. The mkdocs-llmstxt plugin supports a base_url option that rewrites all generated links to a docs subdirectory such as https://product.example.com/en/0.1.34, which is the pattern for language- or version-specific Read the Docs builds.

MkDocs tutorial · Plugin or static · 6 minutes

How to Add llms.txt to MkDocs

MkDocs is the Python-based documentation generator behind a large share of open-source docs sites, usually dressed in the Material for MkDocs theme. It has no native llms.txt feature — but it barely needs one. A plain file in docs/ is copied straight to your site root on every build, and the community mkdocs-llmstxt plugin generates a spec-compliant file from your own config. Both routes are covered here.

MkDocs and llms.txt: No Native Support (Yet)

Software documentation is where llms.txt gets used most heavily — the llmstxt.org spec notes that coding agents follow the file to find API references and tutorials — and MkDocs is one of the most common engines behind that documentation. Yet the integrations list at llmstxt.org still has no MkDocs entry: it names hosted platforms like Mintlify and GitBook and CMS plugins like Yoast, but nothing for self-hosted MkDocs.

The gap is visible in the ecosystem. A community discussion on the Material for MkDocs repository (squidfunk/mkdocs-material #8384) asks for native llms.txt generation, and the answer so far is a plugin. Timothée Mazzucotelli's mkdocs-llmstxt is the reference implementation, and real projects use it in production — the Instructor documentation pipeline regenerates its llms.txt automatically on every deploy. Note that MkDocs pages can sit at any subpath, so the file works for versioned docs too — the llms.txt v2 spec defines how subpath files and Markdown page versions behave.

Method 1: Ship a Static docs/llms.txt

MkDocs copies every non-Markdown file in docs/ verbatim into the output directory, preserving its path — the same mechanism that makes docs/robots.txt work. Create docs/llms.txt and your next mkdocs build serves it at https://docs.example.com/llms.txt:

# Acme Docs

> Acme Docs is the official documentation for the Acme platform.
> It covers installation, configuration and the REST API.

## Getting Started

- [Quickstart](https://docs.example.com/getting-started/): first project in five minutes
- [Authentication](https://docs.example.com/authentication/): API keys and scopes

## API Reference

- [REST API](https://docs.example.com/api/): every endpoint, parameter and error
- [Webhooks](https://docs.example.com/webhooks/): events your server can subscribe to

This is the right route for small sites whose structure changes rarely. The cost is manual maintenance: every new page is a hand edit, and when your docs drift from the file, agents follow a stale index. Keep URLs absolute — never relative paths — and remember the file only describes pages under its own path, so docs served at /en/latest/ want a file in that same tree.

Method 2: Auto-Generate with the mkdocs-llmstxt Plugin

Install the plugin and add it to mkdocs.yml. Three keys matter: site_url is required (all links are built from it), site_description becomes the blockquote, and your sections define the curated heading groups, with optional per-file descriptions and glob support:

# terminal
pip install mkdocs-llmstxt

# mkdocs.yml
site_name: Acme Docs
site_url: https://docs.example.com/
plugins:
  - search
  - llmstxt:
      markdown_description: Long-form context an agent needs before navigating.
      sections:
        User Guide:
          - index.md: What Acme Docs covers
          - getting-started.md
          - deployment.md
        API Reference:
          - api/*.md

Every mkdocs build now writes site/llms.txt. The plugin parses the rendered HTML (BeautifulSoup + Markdownify) and converts it back to clean Markdown, so executed code blocks, Jinja-generated snippets and API documentation survive in the output — and each page you list is published as its own Markdown file, with llms.txt linking those .md URLs. Set full_output: llms-full.txt to also emit the full-text dump, the pattern the llms.txt vs llms-full.txt guide compares. For versioned builds on Read the Docs, the base_url option rewrites every generated link to a subdirectory such as https://docs.example.com/en/0.1.34.

One honesty note: the plugin's repository is in maintenance mode — the author moved on to another project and is looking for a maintainer. It is widely used and stable, but pin your version and keep the static-file fallback in mind. An alternative, mkdocs-llmstxt-md, takes a raw-Markdown approach (enabled as llmstxt-md) and generates both llms.txt and llms-full.txt from your source files by default, deriving sections from your nav when you configure nothing.

Which Route Fits Your Docs?

Approach	Setup	Stays current	Extra outputs
Static `docs/llms.txt`	1 minute	Manual edits only	None
`mkdocs-llmstxt`	~5 minutes	Every build	.md page versions, optional llms-full.txt
`mkdocs-llmstxt-md`	~5 minutes	Every build	llms.txt + llms-full.txt by default

A static file is fine while your sitemap is small and stable. The moment docs change weekly — new guides, moved pages, added API endpoints — a generated file stays honest, because the llms.txt an agent reads is only as trustworthy as its last update.

The MkDocs-Specific Checklist

Set a canonical site_url — plugin links are derived from it. A placeholder site_url ships broken or relative links into your llms.txt.
Curate, don't dump — list the pages that answer real questions: getting started, auth, deployment, the API. Skip the 404 page, the changelog and search indexes. Curation rules live in the best practices guide.
Write useful descriptions — "what problem this page solves" beats "documentation for module X" when an agent decides which link to fetch.
Handle versioned docs per tree — each language or version wants its own subpath file; use base_url in per-version builds rather than one file claiming to cover all of them.
Rebuild to publish — MkDocs is static: llms.txt changes only when CI runs mkdocs build, so wire it into your existing deploy pipeline.

Verify Before Agents Read It

After deploying, confirm the file serves as plain text with a 200 status:

curl -s -o /dev/null -w "%{http_code} %{content_type}\n" https://docs.example.com/llms.txt
# Expect: 200 text/plain

Then paste the URL into the free llms.txt checker to validate the H1, blockquote summary, absolute URLs and section structure against the v2 spec. Draft the initial file in seconds by feeding your MkDocs sitemap into the free llms.txt generator, then switch to the plugin once your sections are settled. MkDocs makes the file trivial to ship and easy to keep current — for a documentation site, that is the highest-leverage AI visibility change you can make this week.