llms-full.txt: What It Is and When to Use It

llms-full.txt is the long companion to llms.txt. Instead of a list of links, it holds the full text of your key pages in one Markdown file, so an AI tool can load your documentation in a single request. That convenience has a cost, though: a large file that goes stale the moment your pages change.

This guide explains what the file is, where it came from and how it differs from llms.txt. It also covers when it is worth publishing and how to build one that stays accurate. As a result, you can decide whether your site needs it at all, which for many sites is a fair question.

What llms-full.txt is

An llms-full.txt file is a single Markdown document, usually served at /llms-full.txt, that concatenates the content of a site's most important pages. Navigation, footers and scripts are stripped out. What remains is the readable text, often with a heading for each source page.

The typical reader is a developer who pastes the URL into an AI coding assistant. Rather than fetching dozens of pages one by one, the assistant gets the whole reference at once. For a product's documentation, that can mean more accurate answers about current features.

Where llms-full.txt came from

The file is not part of the llms.txt proposal itself. Documentation platforms popularized it instead. For example, Mintlify announced in November 2024 that it automatically generates and hosts both llms.txt and llms-full.txt for the docs sites it runs.

Version 2 of the proposal, published in August 2026, points in a slightly different direction. It expects agents to read llms.txt, then follow the relevant links to LLM-friendly pages, such as clean Markdown copies. So treat llms-full.txt as a widely used convention, not as part of a formal specification.

llms.txt vs llms-full.txt

The two files work as a pair: one is the map, the other the territory. Here is how they compare on the points that affect maintenance.

When llms-full.txt is worth publishing

The file pays off when readers need many pages at once and the content is stable enough to keep in sync. Consider it if these points describe your site:

• Developer documentation: users ask AI assistants how to use your API or SDK.
• A bounded reference: the core content fits in one file that a tool can load.
• Automated builds: your docs platform or build step can regenerate the file on every release.

On the other hand, a blog, a news site or a store rarely benefits. Their pages change too often, and no reader needs all of them at once. For those sites, a well-curated llms.txt is enough.

How to build an llms-full.txt file

Build the file with a script, not by hand, so it can be regenerated whenever content changes. The steps below keep it accurate and readable.

Start from the pages in llms.txt

Your llms.txt already names the pages that matter, so use the same list as the source. That keeps both files consistent and stops the full version from growing into a copy of your whole site.

If you list a page under Optional in llms.txt, consider leaving it out of the full file. In addition, skip changelogs and archives unless your readers truly need them.

Convert each page to clean Markdown

Extract the main content of each page and convert it to Markdown. Keep headings, lists, tables and code blocks, because they carry structure a model can use. Then remove menus, cookie banners, related-post widgets and repeated footers.

If your docs already exist as Markdown source files, use those directly. Otherwise, check a sample of converted pages by eye, since HTML converters often mangle tables and code.

Label every page with its source URL

Start each page's section with a heading and its canonical URL. That way, a tool that quotes the file can point readers back to the right page, and you can trace any error to its source:

# Quick start
Source: https://www.example.com/docs/quick-start

Create an account, then send your first invoice...

# API reference
Source: https://www.example.com/docs/api

Keep the order of the sections the same as in llms.txt. Then the two files read as a matching pair.

Serve and update it with the site

Publish the file next to llms.txt and serve it as text/plain; charset=utf-8 or text/markdown. Make sure your server compresses text responses, because the file can be large.

Most importantly, regenerate it in the same build or deploy step that publishes your docs. A stale llms-full.txt is worse than none, because it feeds outdated instructions to every tool that reads it.

Keep it small enough to use

Size is the main trade-off. A complete docs site can produce a file of several megabytes, which may exceed what a given tool loads in one request. If yours grows that large, split it by product or version and link each part from llms.txt.

Also measure before you invest further. Your server logs show whether anything requests /llms-full.txt, and which user agents do. If nothing fetches it after a few months, a simpler llms.txt may serve you just as well.

Conclusion

llms-full.txt bundles the full text of your key pages into one Markdown file for AI tools. It is a platform convention rather than part of the llms.txt proposal, and it suits documentation far better than blogs or stores.

If you publish one, generate it from the pages in your llms.txt, label each section with its source URL and rebuild it with every docs release. Then check both files after each deploy, and watch your logs to confirm that someone actually uses it.

Sources

These sources were reviewed on October 7, 2026. The guidance and example are independently written by SEOVision.

• The /llms.txt file proposal, version 2: the format llms-full.txt builds on
• llms.txt changes from version 1 to version 2: how agents are expected to follow links
• Mintlify: Simplifying docs for AI with /llms.txt: automatic llms-full.txt generation, November 2024