Ask any search engine for “llms.txt best practices” in October 2026 and you get a wall of third-party guides. The spec itself — llmstxt.org, v2, modified August 10, 2026 — sits further down the results. That’s a gap, because the guides are mostly written to v1 habits, and v2 changed several of the things the guides now treat as requirements. This audit goes back to the spec and checks only what it actually says.

What llms.txt is — and is not

The spec is a proposal (authored by Jeremy Howard, published September 3, 2024, now in v2) for a markdown file that gives LLM agents a concise, LLM-friendly map of your site: brief background, guidance, and links to the detailed markdown files (https://llmstxt.org/).

Three honest boundaries before the checklist:

  • It is not a ranking lever. The spec makes no claim that llms.txt affects search rankings, click-through, or citation in any AI product. Its stated purpose is to serve agents that fetch it on demand.
  • It is a courtesy index. Agents that honor the file get a shorter, cheaper path into your content; agents that don’t read it are unaffected. Nothing breaks if you skip it — and nothing magically improves if you add it.
  • Its stated use is inference, not training. The spec’s expectation “was that llms.txt would mainly be useful for inference rather than training, and that is how it has been used.”

What v2 changed (per the live spec)

The spec’s Changes page, under “v2 (August 2026)” (https://llmstxt.org/changes.html), states four changes. All of them concern discoverability and consumption:

  1. Standard link relations for discovery. Given a page, an agent should be able to find its markdown version and the llms.txt that covers it without guessing. rel="alternate" type="text/markdown" points to the page’s markdown version; rel="describedby" points to the covering llms.txt. These can be HTML <link> elements or an HTTP Link: response header — and the header form can be set in web-server or CDN configuration without touching any page.
  2. Both markdown-URL forms are now blessed. v1 specified one form (.md appended to the full page URL: page.html.md). Some publishing tools replace the extension instead (page.md), so v2 allows both.
  3. Subpath files are defined. v1 permitted llms.txt files in subpaths without saying what that meant. v2: a file covers the pages under its path, and where more than one file applies, the most specific one wins. This is what lets a site that controls only a path — a GitHub Pages project site, for example — participate fully.
  4. Consumption is now explicit, and the tooling is gone. v1 described a context-expansion tool for dumping a whole file into an LLM’s context. v2 states the expectation directly instead: agents view or search the llms.txt, then follow the relevant links — so the links should point at LLM-friendly content, and the file itself stays small enough to fit in context. Consequence: the Optional section still exists, but it “no longer carry[s] mechanical semantics” — it is just a convention for secondary links an agent can skip.

What v2 did not change: the core format — a file named llms.txt at the root or any subpath, with an H1 as the only required section, an optional blockquote summary, free-form markdown sections (no headings inside them), and H2-delimited “file lists” where each entry is [name](url) with an optional : note.

One thing to note on what the spec is silent about: llms-full.txt does not appear in the v2 spec. It is a v1-era convention that many 2026 guides still list as a requirement. Treat it as optional legacy practice, not a spec requirement — the v2 mechanism for detail is the file lists linking to per-page markdown, fetched only when an agent needs it.

The 20-minute audit

Work through these six checks in order. Each one has a pass condition taken from the spec.

1. Root file. Does https://yoursite.com/llms.txt exist and parse as the spec’s format? Pass: an H1 with the site name (the only required element), a blockquote with a short summary, then H2 file lists of [name](url): note entries. Fail if it’s a prose essay with no lists, or a 404.

2. Subpath files. Do large sections of the site (docs, pricing, blog) have their own llms.txt? Pass: each subpath file covers only that path, and the most specific file applies. A single root file can cover a small site — that’s fine — but a monolithic root file for a big site defeats the “small enough to fit in context” design.

3. Markdown alternates. Do your important pages offer a .md version? Pass: each listed page has a clean markdown version at the same URL with .md appended (page.html.md) or the extension replaced (page.md) — index.md for URLs without file names. The spec’s point is that the detail lives behind the links; a list pointing at HTML pages still works, but you are not using the feature.

4. Link relations. Do your pages tell agents where the markdown and the llms.txt are? Pass: rel="alternate" type="text/markdown" on pages with a markdown version, and rel="describedby" pointing at the covering llms.txt — as <link> tags in the HTML, or via an HTTP Link: header in server/CDN config (the header form also works for non-HTML resources like the markdown files themselves).

5. Full-content files (the v1 leftover). If you published an llms-full.txt under v1, check whether it’s stale — but know it is not required by v2 and not mentioned in the spec. The spec-grounded question is instead: do the file-list links point at content an agent can actually consume as markdown?

6. Link validity and the spec’s own test. Every URL in your file lists resolves; descriptions are brief and informative (the spec’s own guidelines: concise language, informative link descriptions, no unexplained jargon). Then run the test the spec itself recommends: ask an agent a question about your content, giving it only your llms.txt as a starting point, and see whether it finds what it needs. If it can’t, the file is decoration.

Real adoption evidence (what the spec page actually claims)

We verified the following against the live spec page (modified August 10, 2026); they are the spec’s own claims, and we cite them as such rather than independently re-auditing each site:

  • Scale of adoption: “thousands of sites publish an llms.txt file.”
  • Platform automation: “documentation platforms generate one automatically.” The spec’s integrations list names Mintlify, GitBook and Wix as generating files for hosted sites, plus Yoast SEO and AIOSEO for WordPress and plugins for VitePress, Docusaurus and Drupal.
  • Lighthouse: “Chrome’s Lighthouse audits sites for one as part of its agentic browsing checks.”
  • Model providers: “The AI labs themselves publish llms.txt files for their own developer docs: OpenAI, Anthropic, and Gemini.”

For a B2B SaaS site, the practical read is: the file has moved from novelty to baseline infrastructure, and if your docs already run on a platform like the ones listed, you may already have one — check before writing it by hand.

Where it sits in a full AI-visibility stack

llms.txt is one check, not the strategy. The spec gives it no ranking claim, and nothing in the public data we work with says an llms.txt gets you cited in an answer to a money query. What it does do is make your site cheap and reliable for the agents that do fetch it — a lower bound, not a lever.

Put it in context: your actual AI-visibility position comes from measurement (which queries matter, where you are cited), content architecture (comparison, pricing and trust pages that answers can link to), structured data, third-party citations you can legitimately earn, and files like this one that make the machine-readable path clean. The audit above takes about twenty minutes; the other items take months. Both matter. The order in which you do them is where judgment comes in — and it’s why we document what we do, and how we judge, in our methodology.

One adjacent data point worth understanding before you invest in AI-surface work at all: the click-through evidence on AI Overviews, and what “being un-cited” actually costs. We walk through the two largest published studies in Ahrefs says −58%, Seer says −61%: what the AI Overviews CTR numbers actually mean.

Next step: if you want to see where your site sits in the stack overall — citations on your money queries, month over month, with the reasoning behind every score — the methodology page explains exactly how the measurement runs and what the monthly number does and does not claim.