AI Search
llms-full.txt
llms-full.txt is a plain text file some sites publish at their root that holds the full text of their documentation or key pages in Markdown, so an AI tool can read everything in one request. It is a convention that documentation platforms generate, not part of the llms.txt proposal, and Google Search does not use it.
- Industry term
By QueryRev ResearchPublished Updated6 min read
Why it matters.
It answers a practical problem of llms.txt. That file is a short map: a title, a summary and lists of links, which an agent reads and then follows. The proposal says the file itself should stay small enough to fit in context, with the detail behind the links and fetched only when needed[1]. A tool that wants all the text at once has to follow every link. A second file that holds the text saves it the trips.
The name is a convention, and it is not in the proposal. The original post proposed no file of this name. It described tooling that expanded an llms.txt into two context files, llms-ctx.txt and llms-ctx-full.txt, built with the llms_txt2ctx program[2]. The proposal, first published in September 2024, was revised as version 2 in August 2026, and the revision drops that tooling: its change notes say context expansion is no longer part of the proposal[3]. The llms-full.txt name comes from elsewhere.
It comes from documentation platforms. Mintlify’s documentation says its llms-full.txt file combines the entire documentation site into a single file, as context for AI tools, with each page given as its title, source URL, description and full Markdown content. The platform hosts the file at the root of the site and also at /.well-known/llms-full.txt[4]. Other platforms may follow other layouts, and the file has no specification to check it against.
Google Search does not read it. Google’s guide to generative AI features says a site does not need AI text files to appear in Google Search, because Google Search itself does not use them, and that creating and maintaining them neither harms nor helps visibility or rankings there[5]. The file is for other tools, such as an assistant a developer points at a documentation site. It is not a lever on Search.
Adoption of the smaller file shows how little is settled. In QueryRev’s study, 848 sites publish an llms.txt, with a median file of about 7 KB and 38 links[6]. The study did not count llms-full.txt, so this entry gives no figure for it.
How it is measured.
Whether the file exists, and how big it is. Request /llms-full.txt from the root of each host. A 200 with a plain text or Markdown body is a file; a page of HTML served in its place is not. Record its size, because a file that holds a whole site can be megabytes, which a tool may cut off.
Whether it matches the site. Pick ten pages at random, find each one in the file by its source URL, and compare the text. A file generated at build time is only as current as the last build, so the date of the build matters. For a file written by hand, check every page it lists still answers 200.
Whether it is used. Google does not use the file, so Search Console has nothing to report on it. Server logs show which agents request it and how often; a file nobody requests costs nothing to keep but earns nothing either. Count requests by user agent over a month before deciding that it matters.
Measured by
- File present and its size
- Pages it holds
- Match with the live pages
A worked example.
Illustrative: an invented site, to show the method.
An invoicing app publishes its documentation on a platform that generates both files. Its llms.txt lists 38 links, one line each. Its llms-full.txt holds the Markdown text of the pages behind them, each under its title and source address.
A developer asks an assistant about the app’s API. With the short file the assistant fetches the API reference page and answers from it. With the long file it can read the whole documentation in one request, at the cost of a very large body to load. The site checks that the long file is rebuilt with each release and that the two files list the same pages.
What to do, step by step.
Decide who the file is for. If your documentation is read by developers through assistants, a full-text file may help them; if your audience arrives from Google Search, it will not change that.
If your documentation platform generates the file, leave it on and check what it contains. If you write it, give each page its title, its source URL and its Markdown text, in the same order as your llms.txt.
Keep it in step with the pages. Rebuild it with every release, and list in it only the pages that answer 200 and are meant to be public.
Watch its size. Run the llms.txt checker, which reports the file by size, and split it if a tool cuts it off.
Do not rely on it for search. Keep the pages themselves crawlable and indexable, which is what Google Search uses[5].
Read your server logs for the file once a month and keep it only if agents request it.
Mistakes to avoid.
Treating it as part of the llms.txt standard. The proposal describes llms.txt, and its change notes say context expansion is no longer part of it[3]. A file named llms-full.txt is a convention of documentation platforms[4], and tools differ in whether they read it.
Expecting it to help in Google Search. Google says Search does not use AI text files and ignores them[5]. Keeping the file does no harm there, and does no good.
Letting it go stale. A copy of the documentation that is a release behind answers with old facts, and a tool that trusts it repeats them. Rebuild it with the pages.
Putting private pages in it. The file is public. Pages behind a login, drafts and anything marked noindex do not belong in it. One platform’s documentation says its generated file leaves such pages out by default[4]; a file you write has no such rule.
Publishing a huge file without checking it loads. A file that holds a whole site can be too big for a tool to read in one request. Check its size, and give agents the short file and the pages as well.
How QueryRev treats it.
The free llms.txt checker reads a site’s robots.txt, llms.txt and llms-full.txt, and reports the last by size beside the others. In the product, a change to any of these files is a change to the site: it passes your policy and is written to the Change Ledger with its before and after. See the guide to llms.txt.
Questions people ask.
What is the difference between llms.txt and llms-full.txt?
llms.txt is a short map in Markdown: a title, a summary and lists of links to the pages that matter. llms-full.txt holds the full text of those pages in one file. The first is described by the llms.txt proposal; the second is a convention that documentation platforms generate.
Does Google use llms-full.txt?
No. Google says Google Search does not use AI text files such as llms.txt, and that having them neither helps nor harms a site’s visibility or rankings in Search. The same holds for a full-text file. It is for other tools that choose to read it.
Do I need an llms-full.txt?
Not unless the people or tools you want to reach read it. It suits documentation that developers feed to assistants. For most sites a short llms.txt and well-built pages cover the same ground, and the pages are what search engines use.
Sources and citation.
Primary sources only: the search engines, the AI vendors, standards bodies and QueryRev’s own research. Each is cited in the text by its number.
The /llms.txt file, v2llmstxt.org ·
/llms.txt: a proposal to provide information to help LLMs use websitesAnswer.AI ·
Changes: v2 (August 2026)llmstxt.org ·
llms.txtMintlify Documentation ·
Google’s Guide to Optimizing for Generative AI Features on Google SearchGoogle Search Central ·
State of AI crawler access, October 2026QueryRev Research ·
Cite this definition
A suggested citation. Its link goes to the definition, whose anchor does not change.
QueryRev Research. “llms-full.txt.” QueryRev AI glossary, 24 October 2026. https://queryrev.com/glossary/llms-full-txt#definition
Related terms