The right llms.txt plugin for each docs framework, and which to skip

Docusaurus has three community llms.txt plugins with almost the same name: docusaurus-plugin-llms, @signalwire/docusaurus-plugin-llms-txt, and docusaurus-plugin-llms-txt. They differ in what they write, how recently anyone released them, and whether their output follows the spec. Starlight, MkDocs, VitePress, Fumadocs, and Nextra each have their own version of this problem. Pick wrong and you add a dependency nobody maintains, or you ship an /llms.txt that the reference parser rejects or that links no pages.

Stars find the pick on every framework that has plugins. They do not tell you what the pick still leaves undone. On Docusaurus, weekly downloads would have sent you to a plugin whose stable npm release is from July 2025. On Starlight, the most-starred llms.txt plugin generates an index that links no documentation pages unless you add them by hand. On MkDocs, the most-starred plugin is in maintenance mode. Nextra has no built-in support, and we found no Nextra-specific plugin to star.

Use stars to shortlist, then check maintenance, conformance to the llms.txt v2 spec, and extensibility, and finish by reading the output with curl.

The picks at a glance

Read on October 5, 2026. Fumadocs stars count the whole framework, so they do not compare with the plugin numbers.

How we evaluated

We judged every plugin on the same four criteria:

• GitHub stars, with npm or PyPI weekly downloads to separate close options.
• Recent pushes and releases, and whether repository fixes have reached a published release.
• Accuracy against the llms.txt v2 spec: link-only H2 file lists, per-page .md, and rel="alternate" and rel="describedby" links.
• Extensibility: filtering, ordering, custom sets, and templates.

We read stars, releases, and downloads on October 5, 2026. Downloads cover September 28 to October 4, 2026 and include CI installs, so they are not a count of sites. We did not build or run any plugin for this post: accuracy comes from each project's code, docs, and issue tracker, and extensibility from documented options. EkLine maintains an open-source Starlight template that uses one of these plugins; the disclosure is in the "Where EkLine fits" section.

What a conformant llms.txt looks like in v2

Jeremy Howard's proposal is now "v2 of the proposal," modified August 10, 2026. Only the H1 is required: "This is the only required section." Then come an optional blockquote, optional details, and "Zero or more markdown sections delimited by H2 headers, containing 'file lists' of URLs." Each item is "a required markdown hyperlink [name](url), then optionally a : and notes."

(opens the full-size image in a new tab)

Pages agents might need should have a Markdown version "at the same URL as the original page," with .md appended or replacing the extension. The v2 changes add discovery links: "rel="alternate" type="text/markdown" points to a page's markdown version, and rel="describedby" points to the llms.txt file that covers it." v2 also drops the special meaning of the Optional section, and the spec text read on October 5, 2026 does not mention llms-full.txt.

A GitHub code search on October 5, 2026 across the Docusaurus, MkDocs, Starlight, and VitePress plugins below found the describedby link only in vitepress-plugin-llms. Code search covers default branches only and can lag, and it did not cover Fumadocs or the plugins we skip.

Docusaurus: rachfop's docusaurus-plugin-llms

Docusaurus has no built-in support. In the open Docusaurus issue, maintainer slorber wrote "I'd prefer to keep a lean core and keep this plugin in the community," and later that core support was worth considering, "even though I'm still not super convinced by the usefulness of this file." A core PR was closed unmerged on 2025-10-10.

Pick: rachfop's docusaurus-plugin-llms, released as v0.6.1 on 2026-10-03 with no open issues. It writes llms.txt and llms-full.txt, and per-page .md only on opt-in, because generateMarkdownFiles defaults to false. Its options cover filtering and ordering: ignoreFiles, includeOrder, customLLMFiles, versions: 'auto', keepFrontMatter, and excludeImports.

v0.6.1 added per-locale output for Docusaurus i18n sites. Caveat: the README says "MIT License" while GitHub detects no license file. Closed issues about invalid .md paths (#41) and URLs that drop baseUrl (#43) show why you should still check its output.

Contender: SignalWire's @signalwire/docusaurus-plugin-llms-txt. It leads on weekly downloads (43,177 against rachfop's 36,660) and works from "your final HTML output," with route-based sections, per-page .md, and includeVersionedDocs. It lost on release state: on npm, latest is "1.2.2" (2025-07-23) and alpha is "2.0.0-alpha.7" (2025-11-10). Meanwhile the README documents "Version 2.0, which includes breaking API changes," and fixes from 2026-08-29 are in no npm release. Issue "#47 Title extraction falls back to the site name when the first h1 is the site title" is still open.

Skip: din0s's docusaurus-plugin-llms-txt (npm: docusaurus-plugin-generate-llms-txt). It "generates a concatenated markdown file from your documentation under /llms.txt," so page content goes inside the index instead of links. One release, 0.0.1 from 2024-11-15, and no push since, yet it drew 5,974 weekly downloads and the Docusaurus community resources page still lists it.

Not a contender but useful: FlyNumber's docusaurus-markdown-source-plugin only "exposes your markdown files as raw .md URLs," so it pairs with a generator.

MkDocs: pawamoy's mkdocs-llmstxt, with a caveat

Pick: pawamoy's mkdocs-llmstxt, the most-starred (132) and most-downloaded (56,006 PyPI downloads last week) MkDocs llms.txt plugin. Since 2025-12-01 its README has said: "This project is in maintenance mode." The README continues, "I'm now dedicating my time to Zensical," and invites "a responsible transfer of maintainership." There has been no release since maintenance mode began; the latest is 0.5.0 (2025-11-20), and housekeeping commits landed as late as 2026-10-02.

It wins on two points. It converts rendered HTML to Markdown, so mkdocstrings and macros output is included. And Zensical, from the Material for MkDocs team, reads its configuration natively "Since [0.0.67]," released 2026-09-30. Among the documented differences, "Zensical silently ignores preprocess" and mkdocstrings source listings are omitted. PR #986, which added the support, notes that HTML is converted to GFM, not CommonMark. The cost is setup: you list sections by hand with fnmatch globs, and "Each source file included in sections will have its own Markdown file."

Contender: noklam's mkdocs-llmstxt-md. Choose it if you want a maintained plugin and do not plan to move to Zensical. It is "source-first," with "no HTML parsing," builds sections from nav when sections is empty, and adds .md URLs and llms-full.txt. It lost on adoption (18 stars, 2,873 weekly downloads) and license clarity: GitHub detects none, PyPI says MIT. Because it reads source, confirm that generated API pages appear.

Contender: TimChild's mkdocs-llms-source. Also source-first and nav-derived, with per-page .md, llms-full.txt, and optional git-revision stamps. It lost on adoption (2 stars, 277 PyPI downloads a week) and filtering: "#5 Support excluding pages" is open.

Starlight: starlight-llms-txt, plus .md twins from elsewhere

Pick: delucis's starlight-llms-txt, the only llms.txt plugin on Starlight's plugins page: 114 stars, a push on 2026-10-04, 0.12.0 on 2026-09-15, and 166,799 weekly npm downloads. It leads on extensibility: llms.txt, llms-full.txt, llms-small.txt, customSets, promote, demote, exclude, customSelectors, and minify. Since 0.11.0 it requires Astro 7: "Support for Astro 6 and Starlight versions below 0.41 has been dropped."

In its source (llms.txt.ts, read October 5, 2026), /llms.txt is the H1, the description, a "## Documentation Sets" list linking to llms-small.txt, llms-full.txt, and custom sets, then a "## Notes" H2 of plain-text bullets. The plugin generates no documentation page links; the only way to add some is the optionalLinks option, which you fill by hand and which renders under an ## Optional heading, a name v2 no longer treats as special. In issue #40, joshuap reported "The 'Notes' section that appears as a subheading in the doc is unsupported by the parser," tested against the v1 Python tool. Per-page .md (#28) and i18n are open requests, the code includes only the default locale, and #35 notes exclude is missing in llms-full.txt.

It stays the pick on maintenance, adoption, and options. Add per-page .md separately; EkLine's Serve Markdown guide covers Starlight.

Contender: Wave-RF's @wave-rf/starlight-llm-tools. It writes a "Per-page .md twin" and an "llms.txt manifest + llms-full.txt + llms-small.txt" "ordered by your sidebar," and supports Astro >=5.0. Choose it when spec-shaped page links matter more than adoption. It lost on adoption and activity: one star and 108 weekly downloads, with the last release, v0.3.1, on 2026-06-09.

VitePress: vitepress-plugin-llms

Pick: okineadev's vitepress-plugin-llms wins every criterion: the most stars of any plugin in this guide (405), a push on 2026-10-01, MIT, and 84,926 weekly downloads. v1.14.0, released 2026-09-11, added "llms.txt v2 standard support": <link rel="alternate" type="text/markdown"> and, when generateLLMsTxt is on, <link rel="describedby" href="/llms.txt"> on every page. Per-page .md is on by default, alongside llms-full.txt, and you get ignoreFiles, ignoreFilesPerOutput, customLLMsTxtTemplate, sidebar ordering, and <llm-only>/<llm-exclude> tags.

Contender: angelespejo's vitepress-plugin-llmstxt. It claims "Experimental support for VitePress v2.0.0-alpha," yet "#6 Support for VitePress 2.xx" and "#8 LLMS_URL with wrong path when build in Windows" are open. It lost on adoption: 6 stars, 157 weekly downloads.

Considered: native support. PR #5313, which posva opened, is still a draft. On 2026-07-24 posva wrote, "I don't think this is needed for vitepress 2.0," and left the call to another maintainer, so choose a plugin instead of waiting for native support.

Fumadocs: use the built-in llms()

Pick: the framework's own llms(). The Fumadocs AI and LLMs docs set it up with npx @fumadocs/cli feature llms; index(lang?) returns "the llms.txt index, built from the page tree," and you get /llms-full.txt and *.md routes with Accept negotiation. Because the index comes from the page tree, it lists pages. The repo's 13,297 stars and fumadocs-core's 2,120,917 weekly downloads count the whole framework, so they do not compare with the plugin numbers in this guide.

Handle three things: send Vary: Accept on negotiated responses, as the docs instruct; the remark-llms output option, since MDX components "appear as JSX syntax by default"; and check for the description blockquote, which the generated index omitted (#3186). Check for past bugs too: in fumapress on fumadocs-core 16.15.11, "/llms.txt is written as the literal string [object Promise]" (closed 2026-09-18), and OpenAPI pages give "basically nothing useful" (#3073, closed as not planned).

Considered: a custom script. Langfuse's docs run on fumadocs-core ^16.15.4 but use their own generator, splitting output into llms-<section>.txt files "so the main index stays small enough to be cheap context." That suits a very large site; for most, the built-in is less to maintain.

Nextra: write a route handler

Nextra has no llms.txt support. Issue #4784, "Automated generation of llms.txt," has been open since 2025-09-05. The theme ships a "Copy page" button that copies page source ("theme.copyPage" in 4.6.0); the latest theme release is nextra-theme-docs@4.6.1 from 2025-12-04, and the repo has 327 open issues and PRs.

Pick: a route handler you own that outputs an H1, a blockquote, and H2 link lists. This is the one framework where hand-rolling is the default.

Considered: next-llms-txt. This generic Next.js package lost on maturity: 15 stars, no GitHub release, and 12 open issues and PRs. GitHub detects no root license, though the README points to a LICENSE file in the package folder and the package's package.json says MIT. Nothing shows it tested against Nextra, so try it on a branch first.

Check your output before you ship

Every gap above shows up in the output. Replace docs.example.com and the page path with your own:

# Index: an H1 first, then H2 sections of [name](url) links
curl -s https://docs.example.com/llms.txt | head -n 40
 
# One page's Markdown twin: expect 200 and Markdown, not HTML
curl -sI https://docs.example.com/getting-started.md
curl -s https://docs.example.com/getting-started.md | head -n 20
 
# v2 discovery links in the page HTML
curl -s https://docs.example.com/getting-started/ | grep -E 'rel="(alternate|describedby)"'

Page bodies inside /llms.txt mean a concatenating plugin. No page links under any H2 is the starlight-llms-txt shape. Links that 404 or drop your base path match rachfop's past bugs. On Fumadocs, also confirm the Vary: Accept header and that the index is not [object Promise].

"I'll just hand-write it" and "agents don't read it anyway"

The objection has two parts. llms.txt is a small static file, so any plugin or a hand-written file should do. And agents may not read it: Stoyan Stefanov compared llms.txt requests to robots.txt requests in his server logs and found "In terms of percentage it's 1 - 1.2% in the last 5 days," with little traffic from major AI crawlers (some Claude, no GPT or Gemini). That is one site he runs (sightread.org) over five days, published September 29, 2026. Against it is the spec author's unmeasured claim, in the v2 changes, that "coding agents use them reliably."

The second part limits this post. Nothing here shows llms.txt changes how agents read or cite your docs, and skipping it is a defensible call.

The first part fails once you decide to ship. "Any plugin" includes one that writes concatenated content into llms.txt and the most-installed Starlight llms.txt plugin, whose generated index links no pages. A hand-written file is right on day one and wrong the day a page moves. Teams that need the file end up maintaining code: Langfuse runs a custom generator, and the developer who opened the Docusaurus issue wrote, "Having an llms.txt is a business need for our company." For a small, stable site, hand-writing is fair; for a site that changes weekly, generate it at build time.

Where EkLine fits

A plugin builds the index from the pages you have. It does not check whether those pages are still true: a page describing a flag the last release renamed gets linked in llms.txt and copied into its .md twin on every build.

EkLine's Docs Agent works on the pages. It writes pages that AI agents can answer from, with consistent terminology, structured data, llms.txt, and clean markdown. It starts from the ticket or message for a change, reads the code engineering merged, and checks code samples against the code; every change arrives as a pull request or draft your team approves. Before, the plugin indexes stale pages. After, the Docs Agent updates those pages in a pull request your team reviews. The Docs Agent does not replace the plugin; you still pick one from this guide.

Disclosure: EkLine maintains Potluck Docs, an open-source Starlight template that uses starlight-llms-txt, so it inherits the index structure this post criticizes. Its live /llms.txt links only the abridged and complete documentation sets and has the same "## Notes" section. Potluck Docs pins starlight-llms-txt to ^0.8.1, so it misses the 0.9.0 code-block fix and the 0.10.0 per-output customSelectors control, and it has no rel="describedby" link. Per the Potluck Docs documentation, its per-page .md twins come from @ekline/starlight-contextual-menu and its rel="alternate" link from the template's head component.

Where to start

Install the pick for your framework, then run the curl checks against your live site.

Sources

• The /llms.txt file, v2
• llms.txt changes: v2 (August 2026)
• Docusaurus issue #10899
• Docusaurus PR #11420
• rachfop/docusaurus-plugin-llms
• docusaurus-plugin-llms configuration options
• SignalWire docusaurus-plugin-llms-txt
• @signalwire/docusaurus-plugin-llms-txt on npm
• din0s/docusaurus-plugin-llms-txt
• Docusaurus community resources
• FlyNumber/markdown_docusaurus_plugin
• pawamoy/mkdocs-llmstxt
• mkdocs-llmstxt on PyPI
• mkdocs-llmstxt-md on PyPI
• mkdocs-llms-source on PyPI
• Zensical PR #986
• Zensical MkDocs plugin compatibility
• noklam/mkdocs-llmstxt-md
• TimChild/mkdocs-llms-source
• delucis/starlight-llms-txt
• Starlight plugins list
• starlight-llms-txt issue #40
• starlight-llms-txt issue #28
• starlight-llms-txt issue #34
• starlight-llms-txt issue #35
• Wave-RF/starlight-llm-tools
• okineadev/vitepress-plugin-llms
• vitepress-plugin-llms v1.14.0
• angelespejo/vitepress-plugin-llmstxt
• VitePress PR #5313
• Fumadocs: AI and LLMs
• fumapress issue #99
• Fumadocs issue #3073
• Fumadocs issue #3186
• Nextra issue #4784
• nextra-theme-docs changelog
• bke-daniel/next-llms-txt
• Langfuse generate_llms_txt.js
• Stoyan Stefanov: llms.txt, agent-optimization wishful thinking
• EkLine: Serve Markdown
• ekline-io/potluck-docs
• Potluck Docs: Search and AI
• Potluck Docs live llms.txt