llms.txt is a short index of links; llms-full.txt is your whole content in one Markdown file. When each is worth it, and how to build both on deploy.
LLaunchScaler·Published ·8 min read
llms.txt is a short index of links to your most useful pages, while llms-full.txt is the full text of those pages combined into one Markdown file. Publish llms.txt if you publish either, add llms-full.txt when developers load your documentation into coding assistants, and generate both from the same source on every deploy so they never disagree with your site.
Both are optional. Google says you don't need "AI text files" to appear in its AI features, so this is a decision about serving agents and documentation tools well, not about search rankings.
What is the difference between llms.txt and llms-full.txt?
llms.txt is a map: a title, a summary and lists of links, small enough to fit in an agent's context. llms-full.txt is the territory: every page's content in one file, so a tool can load it all from one URL. They differ in who defined them, how big they get and how much upkeep they need.
llms.txt
llms-full.txt
What it holds
An H1, a blockquote summary and H2 sections of Markdown links with descriptions
The full Markdown content of each page, one after another
Defined by
The llms.txt proposal at llmstxt.org (Jeremy Howard, 2024; v2 August 2026)
Mintlify, developed with Anthropic; not defined in llms.txt v2
How an agent uses it
Reads the index, then fetches only the links it needs
Loads the whole file, or searches it, from a single URL
Questions, answered
What people ask about this
01
What is the difference between llms.txt and llms-full.txt?
llms.txt is a short Markdown index: a title, a summary and lists of links to your key pages. llms-full.txt puts the full text of those pages into one Markdown file, so a tool can load everything from a single URL.
Mintlify caps its generated index at 100,000 characters before splitting; Stripe's docs file was about 92 KB
Mintlify's docs about 1.7 MB, Vercel's docs about 9.7 MB, Anthropic's developer docs about 38.6 MB
Upkeep
Changes when pages are added, renamed or removed
Changes whenever any page's content changes
Audited by Lighthouse
Yes, in the Agentic Browsing category
No; Lighthouse fetches /llms.txt only
The sizes explain the split. An index a few kilobytes long can sit in any agent's context. A documentation set of several megabytes cannot be read whole in one pass, so tools that use llms-full.txt tend to load it into their own search or pull the parts they need.
Where did llms-full.txt come from?
Mintlify, the documentation platform, created it. Its blog says "this file structure was developed by Mintlify in collaboration with customer Anthropic." The llms.txt proposal's current version does not define it: version 2 describes agents reading the index and following links, and dropped the earlier tooling that expanded an llms.txt into one large context file.
So llms-full.txt is a convention, not a spec. Mintlify generates both files for every documentation site it hosts, serves them at the root and at /.well-known/llms.txt and /.well-known/llms-full.txt, and advertises them in an HTTP Link header with rel="llms-txt" and rel="llms-full-txt". Other large documentation sites, Vercel's and Anthropic's among them, publish an llms-full.txt too.
In Mintlify's format, each page in llms-full.txt appears as its title, its source URL, its description and then its full Markdown content. That structure is worth copying, because it lets a tool cite the original page for any passage it uses.
Who reads llms-full.txt?
Documentation tools and coding assistants. Mintlify describes the file's job as making it "easier to paste a single URL to load context into an AI tool," which is what a developer does when setting up a coding assistant with a library's docs. The llms.txt proposal says these files "are used most heavily for software documentation, where coding agents follow them."
Mintlify also says that "AI agents actively visit a site's llms-full.txt over twice as much" as llms.txt alone. That is one documentation platform's claim, not an industry figure, but it matches the use case: an agent that wants everything takes the single file.
Search engines are not on the list. Google says its AI features need no AI text files, and neither OpenAI, Anthropic nor Perplexity mentions llms-full.txt in its crawler documentation. The guide to llms.txt covers who reads the index file.
What does an llms-full.txt look like?
It starts with the same H1 and summary as your llms.txt, then repeats one block per page: a heading with the page title, the source URL, a one-line description, and the page's content in Markdown. Keep headings inside each page one level down so the page boundaries stay clear.
# Acme Scheduling documentation
> Full text of the Acme Scheduling docs, one page per section, newest structure first.
# Quick start
Source: https://docs.acmescheduling.com/quick-start
Set up a clinic, add providers and publish a booking page.
## Create a clinic
Sign in, open Settings > Clinics and choose New clinic...
## Add providers
...
# Webhooks
Source: https://docs.acmescheduling.com/webhooks
Event types, payloads and signature verification.
## Event types
`appointment.created`, `appointment.cancelled`...
Leave out navigation, cookie notices, footers and anything a reader would not want quoted. The file should contain what the pages say, not how the site is built.
What should you leave out of llms-full.txt?
Leave out anything you would not publish as a page. The file is public and easy to copy whole, so a gated guide, an internal runbook or a draft that slips into it is exposed in one request. Mintlify's rules are a sensible default: both files list pages from the default language and version only, and exclude hidden pages and pages marked noindex.
Four exclusions cover most sites. Drop pages behind a login; Mintlify notes that on partly authenticated sites the files stay public but list only public pages. Drop old versions of the docs, or an agent will quote an API you retired. Drop draft and preview content by building from the same published source your site uses. And drop duplicate translations unless your readers need them, since every extra language multiplies the file's size.
How do agents find the files?
By convention first: tools try /llms.txt at the root, and Mintlify also serves both files under /.well-known/. Version 2 of the llms.txt proposal adds a way to announce them explicitly, with standard link relations that work as HTML <link> elements or as an HTTP Link header.
The proposal recommends rel="describedby" pointing from a page to the llms.txt file that covers it, and rel="alternate" type="text/markdown" pointing to the page's Markdown version. Mintlify's Link header goes further and advertises both files by name, rel="llms-txt" and rel="llms-full-txt". A header set once in your CDN or server configuration covers every page without editing templates.
How should you serve them?
Serve both as plain text or Markdown, UTF-8 encoded, with a 200 status. In September 2026, OpenAI's llms.txt and the llms-full.txt files from Mintlify, Vercel and Anthropic were all served as text/plain; charset=utf-8, while Stripe's and Google's Gemini API docs served their llms.txt as text/markdown; charset=utf-8. Either type works.
A few more decisions:
Keep /llms.txt returning 200 or a clean 404. Lighthouse's audit fails a 500-range response and marks a 400-range one not applicable, so a broken route is worse than no file.
Decide whether search engines should index the text files. A long text file can duplicate every page on your site. LaunchScaler, for example, serves its own /llms-full.txt, every blog post in full, with an X-Robots-Tag: noindex header, so the article pages stay the ones that appear in search.
Cache them like any static asset, and purge the cache when you regenerate them.
How do you generate both at build time so they never drift?
Build both files from the same content your pages are built from, in the same deploy step. A hand-edited llms-full.txt goes stale the first time someone edits a page and forgets the file. Generated files cannot disagree with the site because they come from the same source at the same moment.
This Node script reads a folder of Markdown pages with title, description and url in their frontmatter, and writes both files into the folder your site serves:
// scripts/build-llms.mjs (run after your content build, before deploy)
import { readFileSync, readdirSync, writeFileSync } from "node:fs";
import path from "node:path";
import { parse } from "yaml";
const SRC = "content/docs", OUT = "public";
const pages = readdirSync(SRC).filter((f) => f.endsWith(".md")).sort().map((f) => {
const [, fm, body] = readFileSync(path.join(SRC, f), "utf8").match(/^---\n([\s\S]*?)\n---\n([\s\S]*)$/);
return { ...parse(fm), body: body.trim() };
});
const head = "# Acme Scheduling\n\n> Appointment software for clinics with 2 to 50 providers.\n";
const index = pages.map((p) => `- [${p.title}](${p.url}): ${p.description}`).join("\n");
writeFileSync(path.join(OUT, "llms.txt"), `${head}\n## Docs\n\n${index}\n`);
const full = pages.map((p) =>
`# ${p.title}\nSource: ${p.url}\n${p.description}\n\n${p.body.replace(/^(#+) /gm, "#$1 ")}`
).join("\n\n");
writeFileSync(path.join(OUT, "llms-full.txt"), `${head}\n${full}\n`);
Wire it into the build, for example "build": "next build && node scripts/build-llms.mjs" or its equivalent for your stack, and it runs on every deploy. The replace call pushes each page's own headings one level down, so every page title stays the only H1 in its block. Then add one check to CI: fetch both files from a preview build and confirm they return 200 and contain the title of a page you just changed.
Which one should you publish?
Publish llms.txt first if you publish anything, because it is small, cheap to keep current and the one Lighthouse audits. Add llms-full.txt when your readers are developers who load documentation into coding assistants. A marketing site with a few pages rarely needs either, and gains nothing in Google from them.
Your site
llms.txt
llms-full.txt
Developer product with API documentation
Yes
Yes, generated from the docs
SaaS with a marketing site and a small help centre
Text files for agents are the last layer. Run the free scan on LaunchScaler: it takes a URL, needs no account and runs 156 checks across 6 of its 7 categories at no cost. It reports a missing llms.txt as a warning, never a failure, and checks what matters first: whether robots.txt lets OAI-SearchBot, Claude-SearchBot and PerplexityBot in, whether a firewall challenges them, and whether your main content is in the raw HTML they read.
Mintlify says it developed the llms-full.txt structure with its customer Anthropic. The current llms.txt proposal at llmstxt.org, version 2 from August 2026, does not define an llms-full.txt file.
03
Who uses llms-full.txt?
Documentation tools and coding assistants. Mintlify describes the file as a way to paste a single URL to load context into an AI tool, and the llms.txt proposal says these files are used most heavily for software documentation.
04
What content type should llms-full.txt be served with?
Plain text or Markdown with UTF-8, for example text/plain; charset=utf-8 or text/markdown; charset=utf-8. In September 2026, Mintlify, Vercel and Anthropic served their llms-full.txt files as text/plain; charset=utf-8.
05
Should I publish llms-full.txt for a marketing site?
Usually not. It earns its place when developers load your documentation into coding assistants. A marketing site with a handful of pages gets what it needs from a short llms.txt, or from nothing extra at all.
AI agents fail on challenges, fake buttons, unlabelled fields, hover-only menus and moving layouts. The test and the fix for each, in the order to check.
Measure AI visibility by hand: 10 buyer questions, 7 engines, 4 metrics (mention rate, citation rate, share of voice, accuracy), and how to read the noise.
