llms.txt Examples: 6 Real Files, Annotated

Why look at real files instead of the spec

Most llms.txt examples you find in search results fall into two buckets: directories that list hundreds of sites without telling you anything about the files, and articles that show a toy template. Some roundups currently ranking for this keyword print User-agent and Disallow rules inside their "llms.txt" code blocks, syntax that belongs to robots.txt and appears nowhere in the llms.txt spec. Copying from that bucket produces a file no parser expects.

Real files from companies that maintain them are better teachers. The six below cover four different strategies: a massive multi-language docs index (Anthropic), a federated hub of sub-files (Cloudflare), product-first curation (Vercel, Stripe), and a small marketing-shaped file (Cal.com). Each one was fetched live on June 11, 2026, and each annotation points at something you can copy or avoid.

If you want the background first (what llms.txt is, who actually reads it, the honest state of adoption), that lives in our llms.txt explainer. This post assumes you have decided to publish a file and want to see how it is done.

What a valid llms.txt file looks like (format in 60 seconds)

The llms.txt format is a markdown document served at the root path /llms.txt, proposed by Jeremy Howard on September 3, 2024, and specified at llmstxt.org. Its stated purpose is to help LLMs use a website at inference time, when the model is answering a question rather than training. The spec defines this order:

1. An H1 heading with the project or site name. Required, and the only mandatory element.
2. A blockquote (>) with a short summary: what the site is, framed with the context a model needs.
3. Free markdown (paragraphs, no headings) for any details that do not fit the summary.
4. H2-delimited link sections. Each section is a markdown list where every item is [name](url), optionally followed by a colon and a one-line description.
5. An "Optional" H2 section, if present, marks links a model can skip when it needs a shorter context.

Two companion conventions matter. llms-full.txt carries the complete documentation content in one markdown file, where llms.txt is only the curated index. And because the whole thing is markdown, there are no directives: no user agents, no allow rules, no crawl delays. A file that contains Disallow: is a robots.txt fragment with the wrong filename.

That is the entire format. The interesting decisions are editorial: what to include, how to group it, how much to annotate. Those are exactly the points where the six real files below disagree.

1. Anthropic — the heavyweight docs index

File: docs.anthropic.com/llms.txt, which 301-redirects to platform.claude.com/docs/llms.txt. Checked June 11, 2026.

Anthropic's file opens with # Anthropic Developer Documentation and then does something at a scale no other example here attempts: it indexes well over a thousand English documentation pages, plus parallel sections for ten more languages. Links are grouped under product areas (Messages, Managed Agents, Admin, API Reference) and most carry a short annotation.

What to copy: the grouping discipline. Even at this size, a model (or a human) can still find a specific page quickly because the H2 tree mirrors how the product is actually organized. The redirect detail matters too: when Anthropic moved its docs domain, the old llms.txt path was preserved with a 301 rather than left to die.

What to question: there is no blockquote summary; the file goes from H1 straight into link sections via a plain intro line. A file this large also stops being "curated" in any meaningful sense; it is closer to a sitemap in markdown. That works for Anthropic because their consumers are mostly coding tools that want everything. A smaller site copying the everything-approach loses the main benefit of the format, which is selection.

2. Cloudflare — one hub, per-product sub-files

File: developers.cloudflare.com/llms.txt. Checked June 11, 2026.

Cloudflare's developer docs span more than a hundred products, and their llms.txt answers the scale problem differently than Anthropic. The root file is a hub: nine H2 categories (Application performance, Application security, Developer platform, Network security, and so on) containing roughly 120 product links, and each product link points to that product's own llms.txt with the full index for that product. The blockquote says exactly that: each product below links to its own llms.txt.

What to copy: the federation pattern. If your site has clearly separated product areas, a slim root file pointing to per-area sub-files keeps every individual file small enough to drop into a model's context window whole. Cloudflare also annotates every product link with a one-line function description and explicitly marks a deprecated product as deprecated, a small honesty signal that keeps a model from recommending a dead product.

What to question: nothing structural. This is the strongest large-site example of the six. The only caveat is that the pattern is overkill below, say, a dozen product areas.

3. Vercel — strong curation, messy header

File: vercel.com/llms.txt. Checked June 11, 2026.

Vercel's file is a curated index of several hundred links across twenty-plus H2 sections (AI, Build & Deploy, CDN, CLI, Storage, REST API Reference, and others), with a pointer to vercel.com/docs/llms-full.txt for the complete content. The editorial idea is product-first: sections map to what a developer is trying to do on Vercel, not to the docs site's folder tree.

What to copy: the index-plus-export split. The slim file orients a model; the full export feeds tools that want everything in one request. Also note the self-description in the opening ("Vercel is the AI Cloud"), which is positioning language aimed directly at the systems that will paraphrase it.

What to question: the header breaks spec order. The file opens with a blockquote-formatted pointer line before the H1, and then renders two H1-level headings (# Documentation followed by # Vercel Documentation). The spec requires the H1 first and exactly one of them. Parsers are mostly forgiving, but "mostly" is doing real work in that sentence — a strict llms.txt parser keys on the H1 to find the project name. If a company as prominent as Vercel can drift off-spec, yours can too: validate the file, don't eyeball it.

4. Stripe — the spec used the way it was written

File: stripe.com/llms.txt. Checked June 11, 2026.

Stripe's file is the closest thing on this list to a reference implementation. It opens # Stripe, follows immediately with a true blockquote that explains what Stripe is in plain language (financial infrastructure for accepting payments and embedding financial services), and points to stripe.com/llms-full.txt for the single-file version. Roughly 400 annotated links sit under more than twenty product H2s: Payments, Connect, Billing, Tax, Terminal, Radar, Issuing, Treasury, Climate, and on through the catalog.

What to copy: two things. First, the blockquote. A model that reads only the first ten lines of this file already knows what Stripe is, who uses it, and where the complete docs live. That is the blockquote doing its job. Second, Stripe actually uses the spec's Optional section: a long tail of how-to guides sits in a section a model is allowed to drop when context is tight. It is the only file in this set that uses the mechanism, and it is the spec-native way to separate must-read from nice-to-have.

What to question: little. If you maintain a large product catalog and want one file to study line by line, pick this one.

5. Cal.com — a marketing file, not a docs file

File: cal.com/llms.txt. Checked June 11, 2026.

Cal.com's file is the outlier in this set, and that is exactly why it is here. It is small, around 30 links, and it is not a documentation index. The H1 is a positioning statement ("Scheduling Infrastructure for Individuals, Teams, and Organizations"), the blockquote covers the product, plans, and the licensing split between the commercial product and the MIT-licensed community edition, and the H2 sections read like a structured sales page: Products & Plans, Solutions by Use Case, Competitive Positioning, Integrations, Recent Developments.

Two details stand out. The file opens with an "Instructions for AI Agents" section, which gives direct guidance to the systems reading it. And it closes with a visible last-updated timestamp (May 29, 2026, at check time), which tells both models and humans the file is maintained, not abandoned.

What to copy: this is the most relevant template for a DTC store or any non-docs site. You do not have API references; you have products, use cases, policies, and differentiators. Cal.com shows what curating that into llms.txt looks like. The update timestamp is free to add and worth copying everywhere.

What to question: sections like "Competitive Positioning" are self-serving by definition, and a model may treat them with the same skepticism a reader would. Keep claims in such a file factual; models cross-check against other sources.

6. Supabase — slim index plus llms-full.txt

File: supabase.com/llms.txt. Checked June 11, 2026.

Supabase publishes the leanest file in this roundup: # Supabase Docs, about 28 links under two sections, with the first line of content pointing to supabase.com/llms-full.txt for the complete documentation in a single file. They also expose per-language resource files, so a model working in a specific framework can pull only the relevant slice.

What to copy: the restraint. Supabase's docs are large, but the index file stays small and defers bulk to the full export. For most mid-sized sites, this is the right ratio: a model can ingest the whole index in one read and decide what to fetch next. The per-language slicing is a nice extension if your docs serve distinct stacks.

What to question: like Anthropic, there is no blockquote summary, and the file leans on the reader already knowing what Supabase is. Adding three sentences of context would cost nothing.

Patterns worth copying (and three mistakes to avoid)

Across the six files, the moves that repeat:

Pattern	Who does it	Why it works
Blockquote summary up top	Stripe, Cal.com	A model gets the what-is-this answer without fetching anything else
Slim index + llms-full.txt export	Vercel, Stripe, Supabase	Index fits in context; export serves bulk consumers
One-line annotation per link	All six	A bare URL list forces the model to guess what each page contains
H2 tree mirrors product structure	Anthropic, Cloudflare, Vercel, Stripe	Navigation logic transfers from product to file
Per-area sub-files at scale	Cloudflare	Each file stays small enough to read whole
Optional section for the long tail	Stripe	Spec-native way to mark skippable content
Visible update timestamp	Cal.com	Signals maintenance to models and humans

And the mistakes, all observed in the wild:

1. Robots.txt syntax in a markdown file. User-agent, Allow, Disallow, and Crawl-delay are robots.txt directives. They appear in zero of the six real files above and nowhere in the spec, yet ranking articles print them inside llms.txt code blocks. If your file contains a colon-delimited directive, you have written the wrong file.
2. Breaking the header order. Content before the H1, or multiple H1s: Vercel's file shows even sophisticated teams drift here. The H1 is the anchor a parser keys on; put it on line one.
3. Dumping instead of curating. Pasting your entire sitemap into llms.txt recreates the problem the format exists to solve. If everything is important, nothing is; move bulk content to llms-full.txt and keep the index selective.

One honesty note before you invest a sprint in this: publishing llms.txt does not guarantee any AI system reads it today. Adoption among publishers is real (you just saw six files), but consumption by crawlers is a separate, weaker story, and we cover it in the explainer. The cost of a good file is an hour; price the bet accordingly.

A starter llms.txt template

For a product or DTC site (the Cal.com-shaped case), this skeleton follows the spec and the patterns above:

# Acme Skincare

> Acme Skincare is a direct-to-consumer skincare brand. We make
> fragrance-free moisturizers and SPF for sensitive skin, ship to
> the US and EU, and offer a 60-day return policy.

## Products
- [Daily Moisturizer](https://acme.com/products/daily-moisturizer): Bestseller, fragrance-free, 50ml
- [Mineral SPF 30](https://acme.com/products/mineral-spf-30): Zinc-based, no white cast

## Policies
- [Shipping](https://acme.com/shipping): Regions, carriers, delivery windows
- [Returns](https://acme.com/returns): 60-day policy, process, exclusions

## Company
- [About](https://acme.com/about): Founding story, formulation standards
- [Contact](https://acme.com/contact): Support email and hours

## Optional
- [Blog](https://acme.com/blog): Ingredient deep-dives and routines

Swap the sections for what your site actually has, keep one line of annotation per link, and put anything skippable under Optional. If you would rather not hand-write it, our free llms.txt generator crawls your site and produces a spec-valid file you can edit from. That beats starting at a blank line, and it will not put Disallow anywhere.

For the editorial decisions past the template, like what to include and how often to regenerate, see llms.txt best practices.

FAQ

Do I need llms-full.txt as well as llms.txt?

Only if you have bulk content worth exporting. llms.txt is the curated index: a markdown file of annotated links that orients an AI system on your site. llms-full.txt is the bulk variant: the complete documentation content in one markdown file. Stripe, Vercel, and Supabase publish both, with the index pointing to the full export; a small product site usually needs only the index.

Where does the llms.txt file live?

At the root of the host: https://yourdomain.com/llms.txt. Cloudflare extends this with per-product sub-files deeper in the path, but the entry point a model checks first is the root.

Can I put User-agent or Disallow rules in llms.txt?

No. Those are robots.txt directives. The llms.txt format is plain markdown (a name, a summary, link sections) and contains no access-control syntax at all. None of the six real files in this post contain a single directive. If you want to control which AI crawlers access your site, that is a robots.txt and WAF question, not an llms.txt question.

Do I need an llms.txt file to show up in AI search?

No single file makes or breaks AI visibility, and major AI crawlers' consumption of llms.txt is unproven today; our llms.txt explainer covers the evidence. The file is a low-cost bet: an hour of work for a clean, machine-readable map of your site. Sites covered in this post treat it that way: published and maintained, not relied on as the whole strategy.