llms.txt vs llms-full.txt: What Each File Does and Whether You Need Both

Two filenames, one specification, and a lot of confident advice telling you to publish both.

We went and read the spec live. Only one of these files is in it. That is not a criticism of the other one, but it does change what you should do on a Tuesday afternoon with limited time.

If you have not written either file yet, start with our step by step guide to writing an llms.txt file. This piece is about the choice between the two, not the writing of them.

What llms.txt is, per the spec

The llmstxt.org proposal is short and worth reading in full. It defines a markdown file at /llms.txt with a fixed shape:

• An H1 with the name of the project or site. The spec calls this "the only required section."
• A blockquote with a short summary.
• Optional non-heading sections with more detail.
• Zero or more H2 sections containing "file lists" of links, each link optionally followed by a note.

An ## Optional section has a defined meaning: those URLs "can be skipped if a shorter context is needed."

The stated problem it solves is bluntly practical. Context windows are too small for whole websites, and converting HTML full of navigation, ads, and script into clean text is "difficult and imprecise."

So llms.txt is a curation instrument. It is short on purpose.

The same page carries a second proposal that gets overlooked: serve "a clean markdown version of those pages at the same URL as the original page, but with .md appended." That one is arguably more useful than either root file, and almost nobody talks about it.

What llms-full.txt is, and where it came from

Here is where the two files diverge, and it is not a small difference.

llms-full.txt does not appear in the llmstxt.org specification. What appears there is a description of what the FastHTML project chose to do with its own file: expand llms.txt "to two markdown files with the contents of the linked URLs," named llms-ctx.txt and llms-ctx-full.txt, generated by a command line tool called llms_txt2ctx.

Different names, and more importantly a different category. Those are build outputs for feeding a model, not a second file the spec asks every site to host.

The llms-full.txt filename came from tooling. Mintlify's documentation describes it exactly: "The llms-full.txt file combines your entire documentation site into a single file as context for AI tools and LLM indexing." Mintlify auto-hosts both files, and even advertises them in an HTTP header: Link: </llms.txt>; rel="llms-txt", </llms-full.txt>; rel="llms-full-txt".

That is a real, useful convention with real adoption. It is a convention, not a standard, and the distinction matters when someone tells you that you are non-compliant for not having one.

The two files do opposite jobs

Strip away the naming and the difference is simple.

llms.txt is a map. It is small, it is curated, and its value comes from what you left out.

llms-full.txt is the territory. It is large, it is exhaustive, and its value comes from an agent being able to pull your whole corpus in one request instead of forty.

Which explains where each one fits. A documentation site whose entire job is to be loaded into a coding assistant's context benefits enormously from the second file. A twelve page site for a dental practice does not, and a concatenation of twelve pages is just your site again, in a worse format, at a URL nobody requested.

Old way, new way

The old way was a sitemap: every indexable URL, machine-readable, aimed at a crawler that would go and fetch each one.

The llmstxt.org page is direct about why that is not a substitute. A sitemap "will generally cover documents that in aggregate will be too large to fit in an LLM context window, and will include a lot of information that isn't necessary to understand the site."

The new way asks a different question. Not "what pages exist" but "which pages settle a question, and what question does each one settle." That is an editorial judgment, which is why it cannot be fully automated and why most auto-generated llms.txt files are just sitemaps wearing markdown.

The adoption caveat, stated exactly

This is the part that most posts on this topic skate past, so here it is with the hedges intact.

The specification itself does not claim engine support. It says: "This proposal does not include any particular recommendation for how to process the llms.txt file, since it will depend on the application." And on scope: "Our expectation is that llms.txt will mainly be useful for inference, i.e. at the time a user is seeking assistance, as opposed to for training."

That is an author describing a proposal honestly, and it deserves to be quoted honestly rather than upgraded into a standard.

As of 2026-08-06, checking the published documentation of the major engines, we found no commitment from OpenAI, Google, Perplexity, or Anthropic that their answer engines fetch or honor either file the way crawlers honor robots.txt. If that changes, or if you find such a page, it changes the calculation and we would want to know.

There is a genuinely interesting wrinkle, though. The AI labs publish these files themselves. OpenAI's developer docs open with a line pointing at their own llms.txt and note that "markdown versions of documentation pages are available by appending .md to the page URL."

Read that carefully, because it cuts both ways. It is strong evidence the convention is real and being adopted by serious parties. It is evidence about publishing, not about consuming. A lab hosting an llms.txt for other people's agents to read tells you nothing about whether its answer engine fetches yours.

The damaging admission

Writing either file will not get you cited, and we will not imply otherwise.

At best, llms.txt makes discovery cheaper for a system that chooses to look. It cannot make your pages worth reading. If the pages it links are thin, you have built a tidy index that helps a machine confirm they are thin faster.

There is a second, sharper risk with llms-full.txt specifically. It is a snapshot, and snapshots go stale. A hand-maintained concatenation of your site that drifts out of sync with the live pages is a confident, machine-readable statement of things that used to be true. Auto-generated ones from a docs platform stay current because a build regenerates them. Hand-rolled ones usually do not.

If you cannot commit to regenerating it, do not publish it. A stale full-text dump is worse than no dump.

And the automated apply for a WordPress site, with a preview and a per-fix approval, runs through the connected Citedon plugin. On any other platform you upload a text file yourself, which for one file is not a real burden.

So do you need both

A working rule.

If you run documentation on a platform that generates both automatically, you already have both, they stay current on their own, and there is nothing to decide.

If you run a business site and you are writing by hand, write llms.txt only. Keep it to the pages that genuinely settle a question. Skip llms-full.txt entirely, because the maintenance cost is real and the documented benefit for a marketing site is not.

If you are a documentation-heavy product whose users load your docs into coding assistants, both files earn their keep, and the .md versions of individual pages may earn more than either.

Where to start

Neither file matters if the pages you point at cannot be read. That is the check worth doing first, and it takes about a minute.

Run a free scan on the page you would put at the top of your llms.txt, and see what ChatGPT, Perplexity, Gemini, and Claude can actually pull out of it today.