llms-full.txt vs llms.txt: what each does and when to add it
llms-full.txt is a full-text export of your site; llms.txt is just an index. Here is how they differ, what the 2026 data shows, and when to ship each.
llms-full.txt is a single Markdown file that concatenates a website's entire text content into one document, so an AI model can read the whole site in one request. It is the heavier companion to llms.txt, which is only a curated index: a short list of links that points an AI crawler to the pages that matter. One file is a table of contents. The other is the whole book, flattened into plain text.
The distinction matters because the two files solve different problems, and most teams ship the wrong one for their case. A marketing site rarely needs a full-text dump. A documentation site that wants a coding assistant to answer questions about its API often does. Getting this right takes an afternoon. Getting it wrong wastes a build step and leaves a stale file that no one reads.
The 30-second version
- llms.txt: a curated index at your site root. Markdown links to your most important pages, grouped under headings, with one-line descriptions. Small, hand-maintainable, human-readable.
- llms-full.txt: a machine-generated export at your site root. Every page's body content concatenated into one long Markdown file. Large, build-generated, meant to be ingested whole.
- Use llms.txt when you want to point models at the right pages.
- Use llms-full.txt when you want a model to hold your full content in context, usually for developer docs feeding an AI coding assistant.
Where llms.txt and llms-full.txt came from
Jeremy Howard of Answer.AI proposed the llms.txt standard in September 2024. The idea was narrow: give language models a clean, link-based map of a site so they do not have to parse navigation menus, cookie banners, and marketing chrome to find the substance. The spec defines an H1 with the site name, an optional summary, and sections of Markdown links.
llms-full.txt arrived as a convention layered on top, not a separate spec. Documentation platforms started publishing a second file that inlined the actual page content rather than linking to it. The reasoning: a coding assistant working inside an editor cannot make dozens of follow-up fetches for every linked page. If the content is already flattened into one file, the assistant pulls it once and works from it.
How llms-full.txt actually works
The mechanism is a build step. A generator walks your published pages, strips the HTML down to the meaningful text, converts it to Markdown, and writes the result into one file served at /llms-full.txt. Some documentation frameworks emit it automatically. On a custom site, it is a script that reads your content source and concatenates it.
The catch is size. A full-text export of a large site produces a very large file, and an AI model can only read what fits in its context window. Most production models in 2026 carry context windows between 200,000 and 1,000,000 tokens. A big documentation set can exceed even the top of that range once flattened, which means a naive dump gets truncated or never fully ingested. llms-full.txt is useful when the whole export fits in a single context window. When it does not, you are better served by llms.txt plus retrieval, so the model pulls only the sections it needs.
| Trait | llms.txt | llms-full.txt |
|---|---|---|
| Content | Links to pages | Full page text inlined |
| Size | Small (kilobytes) | Large (megabytes possible) |
| Maintenance | Hand or scripted | Build-generated |
| Best for | Orientation | Whole-corpus ingestion |
| Reader | Crawler picking pages | Assistant loading context |
Does llms-full.txt help you get cited by AI?
Here the honest answer diverges from most guides. For classic AI-search visibility, neither file has shown a measurable effect. In June 2026 Google confirmed that Search ignores llms.txt entirely, with no impact on rankings or AI Overviews. John Mueller of Google Search Relations gave the structural reason on the Search Off the Record podcast: a self-reported manifest cannot work as a differentiator, because every site would claim to be the authoritative one, so the signal carries no trust.
The data backs him. SE Ranking analyzed roughly 300,000 domains in May 2026 and found 10.13% adoption overall and 0% among the top 1,000 sites by traffic. After controlling for site authority, schema density, and content recency, it found no citation lift attributable to the file. A machine-learning model trained to predict AI citations actually improved when the llms.txt variable was removed, meaning the file added noise rather than signal. Separate monitoring of AI crawler traffic found that answer bots almost never request the file directly.
So llms-full.txt is not a growth lever for a marketing blog. If your goal is to be cited by ChatGPT, Perplexity, or Google AI Overviews, the levers that move the needle are structured content, real citations, and branded web mentions, not a manifest file. The one place llms-full.txt earns its keep is developer tooling.
When to ship llms-full.txt, and when llms.txt is enough
Ship llms-full.txt when all three of these are true: your site is documentation, an API reference, or a technical knowledge base; your readers use AI coding assistants like Cursor, Continue, or Cline that can pull a file into a session; and your full text fits inside a model's context window. This is the case the file was built for, and it works because the assistant loads current, clean docs instead of guessing from stale training data.
Ship llms.txt alone when you run a marketing site, a small blog, or a product site. The index gives models a map without the maintenance burden of a full export. It costs almost nothing, and while it will not lift your citation rate, it does no harm and stays cheap to keep current. We treat it as basic hygiene, not a growth tactic. Our deeper take on the index file lives in our guide to what llms.txt is and whether you need one.
How to keep both files honest
The real cost of these files is not creation, it is drift. A full-text export generated once and forgotten becomes a snapshot of an old site. If a model does read it, it reads yesterday. Two rules keep them useful. First, generate llms-full.txt in your build pipeline so it regenerates on every deploy and never lags the live content. Second, keep llms.txt short and curated by hand, because its value is judgment about which pages matter, and a script cannot make that call. A file that lists every page is not an index, it is a sitemap with worse formatting.
Related concepts
llms-full.txt sits inside a wider set of choices about how machines read your site: the llms.txt index, robots directives for AI crawlers, structured data, and how AI Overviews and AI Mode select their sources. Treat the two files as documentation infrastructure for the developer-tooling case, and treat everything else as the actual work of earning AI citations.
Sources
- llms.txt proposal, Answer.AI (Jeremy Howard)
- Google says llms.txt is speculative for now, Search Engine Journal
- llms.txt: why brands rely on it and why it does not work, SE Ranking
- llms.txt in practice: adoption data and evidence, Digital Applied
- LLM context length and context window explained, DataNorth
Frequently asked questions
Do I need llms-full.txt if I already have llms.txt?
Only if you run documentation, an API reference, or a technical knowledge base that AI coding assistants read. In that case the full export lets an assistant load your entire content in one request. For a marketing site, blog, or product page, llms.txt alone is enough. Adding a full-text export there creates a large file to maintain with no upside, because answer engines rarely fetch it and it does not affect search rankings.
Can llms-full.txt hurt my SEO or get my site penalized?
There is no evidence of a ranking penalty. Google has stated that Search ignores these files, so they neither help nor hurt classic rankings. The real risk is operational, not algorithmic: a full-text export that is generated once and never updated goes stale, and if an assistant reads it, it works from outdated content. Generate it in your build so it stays current, and the downside disappears.
How do I generate llms-full.txt automatically?
Add a step to your build pipeline that reads your published content, strips it to meaningful Markdown, concatenates it, and writes /llms-full.txt. Several documentation frameworks emit it out of the box; on a custom site it is a short script over your content source. The important part is that it runs on every deploy, so the export never lags the live site. A one-off manual export is the pattern to avoid.
Is there a size limit for llms-full.txt?
The convention sets no hard limit, but the practical ceiling is a model's context window, which in 2026 runs from roughly 200,000 to 1,000,000 tokens. If your flattened export exceeds that, a model cannot ingest it in one pass and either truncates it or ignores the overflow. For large documentation sets, pair a lean llms.txt with retrieval instead of relying on one oversized file.
Related articles
Studio
Start a project.
One partner for the whole build. Faster delivery, a modern stack, lower cost.