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

Part of our llms.txt guide.

llms-full.txt is the full-content companion to llms.txt. Instead of a curated list of links, it inlines the actual text of your pages into one large Markdown file, so a model can ingest your whole documentation in a single fetch. It suits text-heavy docs sites and, like llms.txt, has no confirmed consumers among major engines.

The difference in one line

llms.txt is a table of contents. llms-full.txt is the whole book pasted into one file. Jeremy Howard's original proposal described both: the index file to point at key pages, and the full file to carry the actual content in a single document.

Why the full variant exists

The value proposition is single-fetch ingestion. With plain llms.txt, a model reads the index and then has to go fetch each linked page, stitching them together. With llms-full.txt, everything is already in one Markdown file, so a cooperating model can pull your entire documentation in one request and reason over it without extra round trips. For documentation and API references, where the content is mostly clean prose and code, that is a genuinely tidy delivery format.

When it is worth doing

Use llms-full.txt when all of the following hold:

• Your content is text-heavy: documentation, API references, knowledge bases, guide libraries.

• The full export is a manageable size. If it balloons into many megabytes, it may exceed a model's context window and become useless in one pass.

• You can generate it automatically, so it stays in sync with the real pages.

It is a poor fit when:

• Your site is marketing pages, media, or apps rather than prose.

• Your content is huge. A giant file can blow past context limits, which defeats the single-fetch purpose.

• You would have to maintain it by hand. A stale full-content file is a large surface of wrong information.

The size problem is the real constraint

The headline benefit (everything in one file) is also the main risk. A big documentation set can produce an llms-full.txt of several megabytes, which is far more than most models will accept in a single context window. At that point the model either truncates it, skips it, or falls back to fetching individual pages anyway. So the full variant works best for focused, mid-sized documentation, not sprawling sites. A common pattern is to publish both: llms.txt as the always-safe index, and llms-full.txt for the cases where a model can take the whole thing.

How to generate it

Do not hand-maintain this file. Most documentation platforms that support the convention (for example Mintlify and GitBook) can generate both llms.txt and llms-full.txt automatically from your existing content, so they never drift. If you generate it yourself, the format is simply your pages concatenated as clean Markdown, ideally with a heading per page. Serve it at your root: https://yourdomain.com/llms-full.txt.

Set expectations the same way

Everything from the main spec page applies here too, and if anything more so, because the full variant is more effort. No major engine has confirmed reading llms.txt, let alone llms-full.txt. Google said in July 2025 it does not support the convention, and independent analysis across hundreds of thousands of domains found no measured citation lift. Treat llms-full.txt as a convenience format for the models and tools that opt into it, not as a growth channel.

Practical recommendation

• Small or marketing site: skip llms-full.txt. A basic llms.txt, if anything, is plenty.

• Mid-sized docs that fit a context window: auto-generate both, keep them in sync, move on.

• Very large docs: keep llms.txt as the reliable index; llms-full.txt may be too big to help.

The effort-to-payoff ratio only makes sense when generation is automated. If it is not, your time is better spent on crawlable, well-structured content that engines are confirmed to read.

FAQ