llms-full.txt inlines your full page content; llms.txt is the curated index. Which file your site needs, and how to deliver both when the bigger one pays back.
SEO, GEO & AEO Solutions
Looking for a seo, geo & aeo partner?
We build domain-led systems tailored to your industry and workflow. 12 years. 2,100+ engagements.
llms-full.txt is the bigger sibling of llms.txt. Same convention, same root directory, much larger file. Where llms.txt is a curated index pointing at your strongest pages, llms-full.txt concatenates the actual content of those pages into a single text file that AI engines can ingest in one read. The file can run to many megabytes, takes longer to write and maintain, and is worth delivering in a specific set of cases that does not include every site.
The honest question for most teams is not "should we deliver llms-full.txt" but "is our site one of the kinds where the bigger file pays back." We have delivered both files on our own site and watched the tradeoff up close. The pattern is clear once you see it: most sites benefit fully from llms.txt alone, and the small set of sites that benefit from llms-full.txt benefit a lot. The work is in knowing which set you are in before you spend the time on the bigger file.
Below is the choice framework that decides which file your site needs, what the 2 files look like side by side, the 4 kinds of sites where llms-full.txt is worth delivering, the 3 cases where the bigger file is overkill, and the path from decision to live.
2
Files in the convention: llms.txt for indexing, llms-full.txt for full-content ingestion.
4
Kinds of sites where llms-full.txt is worth the work; the rest do fine with llms.txt alone.
10x
Typical file-size difference between the curated llms.txt and the bulk llms-full.txt.
90%
Of sites that get most of the AI search lift from llms.txt alone, per current adoption patterns.
You will see the 2x2 that decides the file for your site, the side-by-side format comparison, the kinds of sites that should deliver the bigger file, and the practical work to do it well.
Which File Your Site Actually Needs, by 2 Axes
The choice between llms.txt alone and llms.txt plus llms-full.txt comes down to 2 things the site lead can answer in 30 seconds: how reference-heavy your content is, and how many pages you would want a model to read in full rather than skim. The matrix below is the choice plotted on those 2 axes, and only 1 quadrant is where llms-full.txt actually earns its setup cost.
File Choice 2x2
Which File Your Site Needs, Plotted on the 2 Axes That Matter
Across: how reference-heavy your content is. Down: how many pages a model would benefit from ingesting in full rather than skimming. Only the top-right quadrant is where llms-full.txt pays back.
Light Content, Few Pages
llms.txt Alone Is Enough
Most clinic sites, local business sites, and small-portfolio brands sit here. The curated index points at 10 to 30 first-party pages and that is all the model needs. llms-full.txt would add bytes without adding signal.
Reference-Heavy, Many Pages
Deliver Both Files, llms-full.txt Pays Back
Documentation sites, technical product sites, deep knowledge bases. The full-content file gives engines bulk access to the reference material, which is exactly the case where in-full ingestion lifts citation accuracy. The winning quadrant.
Light Content, Many Pages
llms.txt With Strict Curation
E-commerce catalogs, marketing-heavy sites with lots of pages but light editorial. Deliver llms.txt only, and curate the section aggressively to the few pages that carry real first-party signal. Skip llms-full.txt; the bulk content would dilute rather than help.
Reference-Heavy, Few Pages
llms.txt With Full Page Bodies Optional
Specialist research sites or single-product technical pages with deep content. llms.txt alone usually works. llms-full.txt is optional and adds value only if the engines you care about are reading the bulk file already.
Top-Right Is the Only Quadrant Where the Bigger File Earns Its Setup Cost
If your site is not in the top-right quadrant, deliver llms.txt and stop there. The bigger file adds size without adding signal in the other 3 quadrants, and the maintenance cost catches up to you within a quarter or 2.
The choice is not balanced. About 90 percent of sites land in 1 of the 3 quadrants where llms.txt alone is the right answer. The 10 percent in the top-right see meaningful lift from llms-full.txt, and the difference is large enough to justify the work. The honest read is to plot your site on the 2 axes first and let the answer fall out of the matrix rather than starting from "we should deliver both."
The matrix is also a useful filter for what comes next. Once you know which quadrant your site sits in, the rest of the work is straightforward: the top-right delivers both files and wires the bigger file into the build pipeline. The other 3 quadrants deliver llms.txt only and put their content effort into the curated index plus the underlying first-party content. Skipping the matrix step is where most teams overspend, because the default instinct is "more is better" and the matrix tells you that more is often just more, not better. The 2 axes are simple enough to answer in 30 seconds, which is the entire point.
What the 2 Files Look Like, Side by Side
The clearest way to see the difference is to look at the same site delivered as both files. llms.txt is the curated table of contents pointing at pages. llms-full.txt is the full content of those pages concatenated together. Same source pages; very different files.
llms.txt vs llms-full.txt
The Same Site, Delivered as Both Files
Top: the curated llms.txt index. Bottom: the same site rendered as llms-full.txt with the page bodies inlined. Both files are simplified for clarity.
Top, llms.txt (curated index, ~2KB)
# Acme Docs
> Documentation and reference content for Acme, an open-source data pipeline tool used by 200+ engineering teams.
For platform engineers, data engineers, and SREs running data pipelines in production.
## Core Documentation
- /docs/quickstart : 10-minute setup guide
- /docs/architecture : How Acme is built
- /docs/operators : Reference for all 40 operators
## Tutorials and Examples
- /tutorials/first-pipeline : Build your first pipeline in 30 minutes
- /tutorials/scaling : Scaling Acme to 1B events per day
## Optional
- /changelog : Version history
- /community : Forums and discussion
A curated index. The model reads the structure, decides which pages to crawl in detail, and retrieves the bodies separately. Lightweight, easy to maintain, good for most sites.
# Acme Docs
> Documentation and reference content for Acme...
For platform engineers, data engineers, and SREs...
## /docs/quickstart : 10-minute setup guide
Acme is a data pipeline framework that runs as a single
binary on any Linux system. To set up your first pipeline:
1. Download the binary from acme.dev/releases
2. Run acme init my-pipeline
3. Edit my-pipeline/config.yaml
4. Run acme start
(... full content of the quickstart page, inlined ...)
## /docs/architecture : How Acme is built
Acme is built on 3 layers: a source layer that reads from
data sources, a transform layer that runs operators, and a
sink layer that writes to destinations. The source layer...
(... full content of the architecture page, inlined ...)
(... full content of every other page in the index ...)
Same site, full content inlined. The model can ingest everything in a single read. Much larger file, but for documentation-heavy sites the bulk ingestion lifts citation accuracy meaningfully.
Both Files Coexist; They Are Not Alternatives
When a site is in the top-right quadrant, the right move is to deliver both files. llms.txt is the lightweight index every crawler can read; llms-full.txt is the bulk file engines that support it can ingest. Delivering only the bigger file skips the lightweight signal; delivering only the smaller file skips the bulk lift on docs-heavy sites.
The 2 files together give the model 2 ways in: skim the index, or ingest the bulk. For documentation-heavy sites, both paths get used by different engines, and delivering both is the cleanest move. For lighter sites, the bulk file is overkill and the index alone does the work.
The format difference also explains why some teams deliver the wrong file first. llms.txt is so small that it looks like a token gesture; llms-full.txt is so large that it looks like the "real" file. The instinct to launch the bigger one first leads to a file most engines do not read, sitting next to a missing file most engines do read. The right sequence is always llms.txt first, settled, then llms-full.txt on top if the site is in the top-right quadrant. Site shapes that benefit from the bigger file still benefit more when both files deliver together, because the index is what most current crawlers parse and the bulk file is what the docs-focused engines ingest. Skipping the smaller file to "save effort" usually costs more in lost signal than it saves in build time.
5 Kinds of Sites Where llms-full.txt Is Worth Delivering
These are the site shapes where the bigger file pays back consistently. If your site does not fit one of these categories, the honest answer is that llms.txt alone gets you most of the benefit at a fraction of the work.
Software Documentation Sites
API references, SDK docs, framework guides, anything where engineers expect deep technical reference content. The bulk file lets the model ingest the full documentation set in one read, which is exactly the case where citation accuracy on technical questions lifts substantially. Most developer-tool sites benefit from delivering both files.
Reference and Educational Sites
Encyclopedia-style sites, academic resource collections, structured educational content with many interlinked pages. The model benefits from reading the full set together to build the connections between entries. Delivering the bulk file gives the model the corpus rather than a curated subset.
Technical Product Sites With Deep Reference Content
Hardware product manuals, infrastructure platform sites, anything where the buyer needs deep technical detail before deciding. The bulk file gives the model the full technical context, which lifts answer quality for queries about your specific product configuration, integration patterns, or operational details.
Research and White Paper Libraries
Academic publication archives, industry research libraries, white-paper-heavy thought-leadership sites. The bulk file gives engines the full text of the research rather than abstracts, which is the case where citation accuracy on research-grounded queries improves materially.
Large Public Knowledge Bases
Customer-facing help centers with hundreds of articles, public-facing support knowledge bases, troubleshooting libraries. The bulk file gives the model the full text of the knowledge base, which is exactly the case where users ask the AI engine the same questions your knowledge base already answers in detail.
Notice the pattern. Every category is reference-heavy, deep on technical detail, and shaped for full-text ingestion. If your site does not fit one of these descriptions, the bulk file is almost certainly overkill, and the better spend is on getting llms.txt right and delivering the next piece of first-party content.
3 Cases Where llms-full.txt Is Overkill
The reverse list matters as much. These are the site shapes where delivering the bigger file does not pay back, even though some teams default to "more is better."
Small Business and Local Service Sites
Clinics, dental practices, accounting firms, local trades. These sites typically have 5 to 30 pages of first-party content; the curated llms.txt already lists them all, so concatenating the bodies adds size without adding any signal the index does not already give the model.
Marketing-Heavy Brand Sites
Sites where most pages are landing pages, product overviews, or visual brand content. The bulk file would inline mostly marketing prose that does not earn citations anyway. Spend the time on first-party content instead, then add it to the curated llms.txt.
E-Commerce Catalogs With Thin Editorial
Product catalogs, online stores, marketplaces. Most pages are product detail pages, which inline into llms-full.txt without adding citable substance. The bulk file would bloat without helping. Build llms.txt with the curated editorial and category pages that actually carry first-party content.
The Forward Read
llms-full.txt adoption is going to widen over the next 12 to 18 months, but unevenly. Documentation-focused engines and indie AI tools are the early readers, with broader engine support arriving as the file convention stabilizes. The site shapes that benefit are not changing; the set of engines reading the bulk file is. The honest plan in 2026 is to deliver llms-full.txt only if your site is one of the kinds that benefits, watch the adoption curve through 2027, and add support for newer file conventions only when the engines reading them include the ones your audience actually uses.
5 Questions Before You Deliver llms-full.txt
Before you spend the time on the bulk file, these 5 questions filter out the cases where the work will not pay back. Ask them at the planning stage, not after the file is built.
Does Your Site Land in the Top-Right Quadrant?
Reference-heavy and many pages worth ingesting in full. If the honest answer is no, the bulk file is not the right spend. The 2x2 above is the decision; stick with it rather than delivering the bigger file on the off chance it helps.
Can You Keep It Up to Date?
llms-full.txt has to be regenerated when the underlying pages change, which means either a CI hook that rebuilds it on deploy or a quarterly manual rebuild. A stale bulk file is worse than no bulk file because the model is reading content that has since changed. Confirm the automation before you deliver the first version.
Have You Already Delivered llms.txt Cleanly?
The bulk file pairs with the index file. Delivering llms-full.txt without a clean llms.txt next to it leaves the smaller signal on the table, which is the one most engines actually read today. Deliver llms.txt first, refresh it once, then layer llms-full.txt on top once the index file is settled.
Are There Privacy or License Concerns With Bulk Content?
Inlining the full body of every curated page is functionally an open invitation to ingest your full content. If your pages contain customer data, sensitive examples, or licensed material that should not be redistributed in bulk, llms-full.txt is the wrong format. Sort out the legal and privacy posture before you build the file.
Is the Maintenance Owner Clear?
llms-full.txt needs an owner with the build pipeline access to regenerate it. If the file is delivered without a named maintainer, it goes stale within a quarter. Assign the owner at the planning stage and put the regeneration on a recurring schedule before the first version goes live.
From Decision to Live in 4 Steps
Once the matrix tells you the bigger file is worth delivering, the practical work fits in 4 steps. The first version is a focused engineering build; the harder part is the ongoing pipeline that keeps the file aligned with the content underneath. Sites that deliver the build and skip the pipeline end up with a stale file inside a quarter, which is why we bundle both into a single engagement for clients rather than handing the script over and walking away.
Decision to Live
From the 2x2 Choice to a Working llms-full.txt at Your Site Root
Step 1
Confirm Top-Right Quadrant
Plot your site on the matrix. If it lands anywhere other than top-right, stop. Deliver llms.txt and skip the bulk file.
▸
Step 2
Build the Generator
A small script reads each curated page from llms.txt, strips HTML, prepends a heading, and concatenates the bodies into llms-full.txt.
▸
Step 3
Wire It Into Build or Deploy
Add the generator to your CI pipeline or content workflow so the file regenerates on every deploy. Skip the manual-rebuild trap.
▸
Step 4
Deliver and Monitor
Upload to your site root next to llms.txt. Confirm it serves as plain text. Add the file path to the monthly health check.
Step 2 Is Where Most Teams Underspend
A clean generator is the difference between a file that stays current and one that goes stale. Manual rebuilds drift; CI-driven rebuilds do not. Spend the build time on the script and the wiring; the formatting and uploading are mechanical.
The path is the same whether the site is a documentation platform, a research library, or a public knowledge base. The script changes per stack; the structure does not. Deliver both files together, refresh them on the same cadence, and the answer layer reads your site through 2 paths instead of 1.
Once both files are live and the generator is wired into the build pipeline, the ongoing cost drops to almost zero. Every deploy refreshes the bulk file automatically, the curated index gets touched only when the underlying page list changes, and the monthly health check confirms both files are still serving cleanly as plain text. Teams that get to this state stop thinking about the technical layer and put their attention back on the first-party content the files point at, which is exactly the right shape. The technical layer is plumbing; the substance is the content. Sites that deliver the plumbing once and then forget it can exist outperform sites that obsess over technical details while the content underneath stays generic.
Frequently Asked Questions
If I can only deliver one, should it be llms.txt or llms-full.txt?
llms.txt, in almost every case. The smaller file is read by more engines today, takes less time to write, and lands as a meaningful signal for sites of all sizes. The bigger file pays back only when your site is reference-heavy and has many pages worth ingesting in full. Pick the smaller file first, deliver it cleanly, refresh it once or twice, and only add the bigger file if your site is one of the 4 categories that benefits. Delivering only llms-full.txt skips the lightweight signal most engines currently read, which is the wrong tradeoff for most teams.
How large does llms-full.txt typically get?
For a 30-page documentation site, expect roughly 1 to 5 MB depending on the depth of the pages. For a 200-page reference site, 10 to 30 MB is common. For very large knowledge bases, the file can run into the hundreds of MB, at which point chunking or splitting becomes worth considering. The size itself is not a problem for crawlers that read the file; the problem is staleness if the file is not regenerated when the source pages change. The work that pays back is the build-pipeline integration and the monitoring on top, not the one-time generator. We treat the pipeline as the deliverable, not the script, which is what keeps the file alive past the first quarter.
Do I need both files, or do they compete with each other?
They complement, they do not compete. llms.txt is the curated index that lightweight crawlers and most current engines read. llms-full.txt is the bulk file that documentation-focused engines and indie tools can ingest in one read. Different engines use different files; delivering both gives the model 2 ways in, with no conflict between them. The only mistake is delivering the bigger file in isolation, because then most engines see no signal at all.
Will inlining my full content into llms-full.txt encourage scraping or content theft?
The content in llms-full.txt is the same content that lives on your public pages, served in a more accessible format. If you are concerned about content reuse, the right defense is the same as for any public content: licensing, robots.txt restrictions, and clear terms of service. Sites with proprietary or licensed material that should not be redistributed in bulk should not deliver llms-full.txt at all; sites with public editorial and reference content rarely see meaningful new risk from the file itself, because anything in it was already crawlable from the pages it lists.
How do I generate llms-full.txt without rewriting it by hand?
The script that reads each URL in llms.txt, strips the HTML, and concatenates the bodies is the small part of the work. The hard part is the build-pipeline integration, the monitoring, the staleness detection, and the rebuild logic when source pages restructure. Sites that deliver the generator without the maintenance layer end up with a file that drifts within a quarter, which is worse than no file. The reason we deliver this as part of a broader AI search technical layer for clients is that the script is the obvious piece, and the pipeline is the piece that decides whether the file stays alive. Manual generation is the trap to avoid; an unmonitored generator is the next trap underneath it.
How often should I regenerate llms-full.txt once it is live?
On every deploy, ideally. If the file is wired into CI it regenerates automatically with no team effort. If it cannot be wired into CI, the next-best cadence is weekly for active sites and monthly for stable ones. The file should never go more than a quarter without a regeneration, because the content drift makes it actively misleading at that point. The maintenance burden is small when the generator is automated and large when it is not, which is most of the reason Step 2 in the roadmap above matters as much as it does.
Can Entexis build and maintain llms-full.txt for our team?
Yes, and the work is well within reach as part of a broader AI search content engagement. We start with the matrix to confirm your site is one of the kinds that benefits, write the generator script in your stack of choice, wire it into the build or deploy pipeline so the file regenerates automatically, and put the file on the same monitoring cadence as the rest of the AI search technical layer. We deliver both files on our own site and have the operating experience to know which patterns work and which add cost without payback. If your site is documentation-heavy or reference-heavy and you have been wondering whether the bigger file is worth delivering, we run that decision quickly and either build the file or recommend skipping it based on what your site actually needs.
For the broader thesis behind both files, why first-party data is the AI search moat and why a curated technical layer only works if the pages it points to are worth citing, see: Why First-Party Data Is the AI Search Moat.
The most important thing to take from this is that llms-full.txt is not a default. It is a specialized file for a specific kind of site. Deliver llms.txt first, settle the curated index, then plot your site on the matrix. If you land in the top-right quadrant, the bigger file pays back. If you land anywhere else, save the time and put it on the next piece of first-party content instead.
Want Both Files Done Right, Wired Into Your Build?
At Entexis, we build llms.txt and llms-full.txt as part of the technical layer for AI search visibility. We run the matrix first so we deliver only the files your site actually needs, write the generators in your stack of choice, wire them into your build or deploy pipeline so they regenerate automatically, and put the whole layer on the same monitoring cadence as the rest of the AI search technical infrastructure. We deliver both files on our own site too, so the work is something we already practice rather than something we describe. If your AI search content has been delivering but the technical files underneath are still missing or stale, the answer is probably not another plug-in. It is the small files and structured signals the answer layer actually reads. Start the conversation with Entexis.
Ready to Win AI Search?
Manual SEO cannot keep pace with GEO and AEO. We build the workflows and automation that keep your brand visible across AI answer engines. Tell us what you need.
We'll get back within one business day.
Thank You!
We've received your message and will get back to you within one business day.
Try the AI workflows we build, for real, right now.
Same workflow patterns Entexis rolls into client stacks. Try them in your browser, no signup. If one feels like it'd help your team, we build a private version tuned to your data.
