What is llms-full.txt?

A companion file to llms.txt that contains the full text of your documentation flattened into one large Markdown file, instead of links. It lets an AI ingest your entire docs in a single fetch.

Do I need both llms.txt and llms-full.txt?

Most sites only need llms.txt. llms-full.txt mainly benefits documentation sites whose users paste docs into AI coding assistants. If you're not a docs site, skip it.

How big can llms-full.txt be?

There's no hard limit in the proposal, but practical limits are real: files beyond a few hundred thousand tokens exceed what most AI contexts can ingest at once. Large projects often split it per section.

Does either file affect Google rankings?

No direct effect. Both are conventions for AI consumption, not Google ranking signals. They matter for how AI assistants read and cite you, which is a different channel than organic search.

llms.txt vs llms-full.txt: which one do you need?

llms.txt is a curated index: a short Markdown file of links with descriptions, telling an AI where your important pages are. llms-full.txt is the payload: your entire documentation flattened into one Markdown file an AI can ingest in a single fetch. Almost every site benefits from the first; only documentation-heavy sites need the second.

The two files, side by side

	llms.txt	llms-full.txt
Contains	Links + one-line descriptions	Full page content, inlined
Typical size	1–5 KB	100 KB – several MB
Reader	An AI deciding what to fetch	An AI ingesting everything at once
Best for	Every site	Docs sites, API references, dev tools
Maintenance	Update when key pages change	Regenerate on every docs change

Both live at your domain root: /llms.txt and /llms-full.txt. They come from the same proposal — the llms-full variant emerged from documentation tooling (Mintlify popularized auto-generating both) as a convenience for AI coding assistants.

What llms.txt is for

llms.txt solves a navigation problem. An AI assistant landing on your site has no idea which of your thousands of URLs matter. The file is a reading list: "here's what this site is, and here are the 15 pages that answer the questions people actually ask." The model (or the tool orchestrating it) then fetches whichever linked pages the current question needs.

That makes llms.txt cheap to maintain and universally applicable — a store, a SaaS landing site, a blog, and a docs site all benefit the same way. If you haven't created one, the generator does it in minutes, and our annotated examples show what good files look like.

What llms-full.txt is for

llms-full.txt solves a bandwidth problem specific to documentation. When a developer says "here are the docs for library X, help me use it," the AI needs all the docs, not a list of links it must fetch one by one — many AI tools can't follow links at all, or burn context doing dozens of fetches. One big Markdown file fixes that: paste or fetch a single URL, get the whole reference.

That's why the pattern took hold in developer tooling: framework docs, API references, SDK guides. Users literally paste these files into Claude, ChatGPT, or Cursor. If your users do that with your content, llms-full.txt is worth generating. If nobody would ever paste your entire site into a chat window, it isn't.

Which one do you need?

Marketing site, store, blog, local business: llms.txt only. llms-full.txt of a marketing site is noise — an AI doesn't need your entire homepage copy inlined.
Documentation site or developer tool: both. llms.txt as the index, llms-full.txt for whole-corpus ingestion. If your docs platform (Mintlify, Fumadocs, and others) can auto-generate them, turn that on — hand-maintaining a full-text mirror is not a good use of your time.
Huge documentation (thousands of pages): llms.txt plus sectioned full files (for example /llms-full-api.txt, /llms-full-guides.txt), because a single file beyond a few hundred thousand tokens overflows the context of most models anyway. Link the sectioned files from llms.txt so they're discoverable.

Practical rules if you publish llms-full.txt

Generate, don't hand-write. The file must mirror your docs exactly; any manual step guarantees drift. Wire it into your docs build.
Strip navigation and boilerplate. Repeated headers, footers, and sidebars multiplied across hundreds of pages waste a huge share of the tokens an AI spends reading you.
Keep llms.txt as the front door. Link llms-full.txt from your llms.txt (a line in an ## Optional section works) so tools that only know the primary convention can find the full version.
Watch the size. As a rough rule, 1 MB of Markdown ≈ 250K tokens — already past what most mainstream contexts hold. If you're beyond that, split by section.
Validate the index file. Only llms.txt has a real structure to validate (H1, blockquote, link sections) — check yours with the llms.txt Validator. llms-full.txt is just Markdown; the only test that matters is whether it's current.

The bottom line

Start with llms.txt — every site type benefits, it takes minutes, and it's the file the broader ecosystem checks for. Add llms-full.txt only when your content is documentation that users feed to AI tools wholesale. If you're unsure whether you're that kind of site, you aren't: docs teams know, because their users ask for it.