llms.txt examples: 8 real files, annotated

The 30-second answer: what a good llms.txt example looks like

Nearly every file in this article has the same skeleton: an H1 with the site name, a blockquote with a one-paragraph summary, then one or more H2 sections holding a Markdown list of links, each with a short description after a colon. That is the whole format. The small sites stop there; the large ones add a few free-form paragraphs telling an AI assistant how to use the site, and two of the largest skip the blockquote altogether.

The two decisions that separate a useful file from a filler one are which links you include (few, and the ones a visitor would actually ask about) and how you describe them (a real sentence, not the page title repeated). Copy those two habits from the examples below and you are most of the way there.

A note on the spec itself: as of September 2026, llmstxt.org describes v2 of the proposal, revised in August 2026. The original was published by Jeremy Howard in September 2024. v2 keeps the format unchanged, states that the H1 is the only strictly required line, and drops the special meaning of the Optional section. All eight examples remain valid under both.

1. llmstxt.org — the smallest valid file

The spec’s own site publishes a file that is 10 lines and 3 links. It is the clearest demonstration that llms.txt does not need to be long to be correct.

# llms.txt

> A proposal that those interested in providing LLM-friendly content add a /llms.txt file to their site. This is a markdown file that provides brief background information and guidance, along with links to markdown files providing more detailed information.

## Docs

- [llms.txt proposal](https://llmstxt.org/index.md): The proposal for llms.txt
- [Python library docs](https://llmstxt.org/intro.html.md): Docs for `llms-txt` python lib
- [ed demo](https://llmstxt.org/ed.md): Tongue-in-cheek example of how llms.txt could be used in the classic `ed` editor, used to show how editors could incorporate llms.txt in general.

What to copy

• The blockquote does real work. It says what the thing is, what format it uses and what it links to, in two sentences. An assistant that reads only this line already knows whether the site is relevant.
• Links go to Markdown, not HTML. index.md and intro.html.md are the Markdown twins of the HTML pages. The spec recommends exactly this; when you can offer a .md version, link to it.
• One section is enough. There is no Optional block, no About paragraph. If your site has three important pages, the file can be this short.

2. Answer.AI — a company site, not a docs site

Most published examples are developer documentation. Answer.AI, the research lab where the spec was written, uses one for a plain company website, which makes it a better template for most businesses.

# Answer.AI company website

> Answer.AI is a new kind of AI R&D lab which creates practical end-user products based on foundational research breakthroughs.

Answer.AI is a public benefit corporation.

## Docs

- [Launch post describing Answer.AI's mission and purpose](https://www.answer.ai/posts/2023-12-12-launch.md): Describes Answer.AI, a "new old kind of R&D lab"
- [Lessons from history's greatest R&D labs](https://www.answer.ai/posts/2024-01-26-freaktakes-lessons.md): A historical analysis of what the earliest electrical and great applied R&D labs can teach Answer.AI, and potential pitfalls, by R&D lab historian Eric Gilliam
- [Answer.AI projects](https://www.answer.ai/overview.md): Brief descriptions and dates of released Answer.AI projects

What to copy

• The one-line paragraph after the blockquote. “Answer.AI is a public benefit corporation” is a fact an assistant would otherwise have to guess at. This is the slot for the two or three facts about your business that are most often asked and most often got wrong.
• Descriptions say who and what. The second link names the author of the post. If a page has a byline, date or audience that matters, put it in the description.
• Three links, deliberately chosen. The site has far more posts. The file lists the ones that explain the company.

3. FastHTML — the reference example, with instructions for the model

The spec uses a trimmed version of this file as its worked example. The full file is 45 lines, 21 links, and lives at /docs/llms.txt rather than the site root — the spec explicitly allows a file at any path to cover the pages under it.

# FastHTML

> FastHTML is a python library which brings together Starlette, Uvicorn, HTMX, and fastcore's `FT` "FastTags" into a library for creating server-rendered hypermedia applications. ...

Things to remember when writing FastHTML apps:

- Although parts of its API are inspired by FastAPI, it is *not* compatible with FastAPI syntax and is not targeted at creating API services
- FastHTML is compatible with JS-native web components and any vanilla JS library, but not with React, Vue, or Svelte
- Use `serve()` for running uvicorn (`if __name__ == "__main__"` is not needed since it's automatic)

## Docs

- [FastHTML concise guide](https://www.fastht.ml/docs/ref/concise_guide.html.md): A brief overview of idiomatic FastHTML apps
- [HTMX reference](https://raw.githubusercontent.com/bigskysoftware/htmx/master/www/content/reference.md): Brief description of all HTMX attributes, CSS classes, headers, events, extensions, js lib methods, and config options

## API

- [API List](https://www.fastht.ml/docs/apilist.txt): A succint list of all functions and methods in fasthtml.

## Examples

- [Todo list application](https://raw.githubusercontent.com/AnswerDotAI/fasthtml/main/examples/adv_app.py): Detailed walk-thru of a complete CRUD app in FastHTML showing idiomatic use of FastHTML and HTMX patterns.

## Optional

- [Starlette full documentation](https://gist.githubusercontent.com/.../starlette-sml.md): A subset of the Starlette documentation useful for FastHTML development.
- [FAQ](https://www.fastht.ml/docs/explains/faq.html.md): Answers to common questions about FastHTML.

What to copy

• “Things to remember” is the misconception list. Each bullet corrects a mistake a model is likely to make (confusing it with FastAPI, assuming React works). A business equivalent: “we do not ship outside the EU” or “the free plan has no API access.”
• External links are allowed. Two of the Docs links go to GitHub and a gist. If the best explanation of something lives on another site, link it.
• Optional holds the long tail. Fourteen explainer pages sit under Optional so the first three sections stay short.

4. Svelte — one index, three sizes

Svelte’s 23-line file is less a page list than a menu of bundles. It is the cleanest example of designing for the assistant’s context budget.

# Svelte Documentation for LLMs

> Svelte is a UI framework that uses a compiler to let you write breathtakingly concise components that do minimal work in the browser, using languages you already know — HTML, CSS and JavaScript.

## Documentation Sets

- [Abridged documentation](https://svelte.dev/llms-medium.txt): A shorter version of the Svelte and SvelteKit documentation, with examples and non-essential content removed
- [Compressed documentation](https://svelte.dev/llms-small.txt): A minimal version of the Svelte and SvelteKit documentation, with many examples and non-essential content removed
- [Complete documentation](https://svelte.dev/llms-full.txt): The complete Svelte and SvelteKit documentation including all examples and additional content

## Individual Package Documentation

- [Svelte documentation](https://svelte.dev/docs/svelte/llms.txt): This is the developer documentation for Svelte.
- [SvelteKit documentation](https://svelte.dev/docs/kit/llms.txt): This is the developer documentation for SvelteKit.

## Notes

- The abridged and compressed documentation excludes legacy compatibility notes, detailed examples, and supplementary information
- The content is automatically generated from the same source as the official documentation

What to copy

• Say what was removed from each bundle. The descriptions for small / medium / full state the trade-off so an assistant can pick the right one without opening all three.
• Per-package llms.txt files. Each sub-project has its own file under its own path. If your site has clearly separate products, this scales better than one giant list.
• A Notes section with no links is fine. The spec allows plain lists; the file uses one to explain how the bundles are generated.

5. Vercel — “when to use” and “how agents should use”

Vercel’s file (64 lines, 24 links) is a company site and a docs index in one. Its first two sections contain no links at all; they tell the assistant what the platform is for and how to behave.

# Vercel

> Vercel is a cloud platform for building, deploying, and scaling web applications and AI workloads.

Use this index to find machine-readable documentation and platform resources. Follow the linked indexes when you need individual pages.

## When to use Vercel

- Deploy and scale web applications, APIs, and AI workloads from a Git repository or the Vercel CLI.
- Automate projects, deployments, domains, and account resources through the Vercel REST API or SDK.

## How agents should use Vercel

- For research, fetch the Markdown documentation indexes below and follow their links to individual Markdown pages.
- For REST API calls, read the OpenAPI description and authentication documentation before choosing an operation. Ask for approval before changing account resources.

## Documentation

- [Vercel product documentation](https://vercel.com/docs/products.md): Curated product index with links to documentation.
- [Full documentation content](https://vercel.com/docs/llms-full.txt): Complete documentation and REST API reference in one file.

## Optional

- [Agent resource catalog](https://vercel.com/.well-known/ai-catalog.json): Experimental catalog of agent-facing resources.
- [Product taxonomy](https://vercel.com/docs/taxonomy.json): Canonical product names, aliases, and deprecations.

What to copy

• A “When to use” section. Five bullets that answer “is this the right product for me?” — the question an assistant is usually trying to answer on a visitor’s behalf.
• Safety guidance for agents. “Ask for approval before changing account resources” is a sentence any site with an API or a booking flow could borrow.
• Tagged links. Several docs links carry ?from=llms-txt, so Vercel can see in its logs which visits came via the file. Cheap, and a real answer to “is anyone reading this?”

6. Cloudflare developer docs — a hub that points to 107 spokes

Cloudflare’s documentation covers well over a hundred products. Rather than list thousands of pages, the root file (138 lines, 107 links, about 16 KB) links to one llms.txt per product.

# Cloudflare Developer Documentation

Explore guides and tutorials to start building on Cloudflare's platform.

> Each product below links to its own llms.txt, which contains a full index of that product's documentation pages and is the recommended way to explore a specific product's content.

## Application performance

- [Cache / CDN](https://developers.cloudflare.com/cache/llms.txt): Make websites faster by caching content across our global server network
- [DNS](https://developers.cloudflare.com/dns/llms.txt): Deliver excellent performance and reliability to your domain

## Developer platform

- [Workers](https://developers.cloudflare.com/workers/llms.txt): Build, deploy, and scale serverless applications globally with low latency and minimal configuration

## Other

- [Docs for agents](https://developers.cloudflare.com/docs-for-agents/llms.txt): Learn how AI agents and LLMs consume Cloudflare documentation

What to copy

• Hub and spoke. The root file stays readable and each product file is complete. This is the pattern for any large site with distinct sections: a marketplace, a university, a multi-brand group.
• Group by what the visitor wants, not by your org chart: “Application performance”, “Application security”, “Developer platform”.
• One thing not to copy: the summary blockquote comes after a plain paragraph. The spec puts the blockquote directly under the H1. Assistants cope, but a strict validator will flag it.

7. Stripe docs — a large index with rules for LLM agents

Stripe publishes two files: stripe.com/llms.txt for the marketing site (305 links) and docs.stripe.com/llms.txt for the documentation (707 lines, 453 links, about 92 KB, served as text/markdown). The docs file is the most opinionated of the eight.

# Stripe Documentation

When installing Stripe packages, always check the npm registry for the latest version rather than relying on memorized version numbers. ...

## Docs

- [Testing](https://docs.stripe.com/testing.md): Simulate payments to test your integration.
- [API Reference](https://docs.stripe.com/api.md)
- [Receive payouts](https://docs.stripe.com/payouts.md): Set up your bank account to receive payouts.

## Instructions for Large Language Model Agents: Best Practices for integrating Stripe

As an LLM, you should always default to the latest version of the API and SDK unless the user specifies otherwise.

Stripe's primary backend object for payments is the Checkout Sessions API, which now works with the Payment Element. Prioritize the Checkout Sessions API, ... and never recommend the Charges API. ...

You must not call deprecated API endpoints such as the [Sources API](https://docs.stripe.com/api/sources/object.md) ...

What to copy

• Tell the model what not to recommend. Stripe has years of deprecated APIs, and they are in the data models were trained on. The instructions section steers assistants to the current ones. Any business with an old pricing page or a discontinued product has the same problem in miniature.
• Split by audience. Marketing site and docs get separate files, each on its own host. Readers asking “what does Stripe cost?” and “how do I create a PaymentIntent?” never share an index.
• What not to copy: the size, and the missing blockquote. At 92 KB this is near the top of what a context-limited assistant will read in full, and the file opens with a plain paragraph where the spec expects a summary blockquote. Stripe can afford both because the links are the product; most sites cannot.

8. Anthropic — 629 links and a languages section

docs.anthropic.com/llms.txt now redirects to platform.claude.com/llms.txt: 699 lines, 629 links, about 68 KB. Two things at the top are unusual and worth noting.

# Anthropic Developer Documentation

This file provides an overview of the Anthropic API documentation and developer resources.

## Root URL

Claude Developer Platform Console (Requires login)

https://platform.claude.com

## Available Languages on Website

The full documentation is available in the following languages on https://platform.claude.com/docs:

- English (en) - 629 pages - /docs - Content included below
- German (Deutsch) (de) - 252 pages - /docs/de - Visit website for content
- Japanese (日本語) (ja) - 252 pages - /docs/ja - Visit website for content
...

## English

### Docs home

- [Documentation](https://platform.claude.com/docs/en/home.md)

### Messages

- [Overview](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview.md) - Agent Skills
- [Features overview](https://platform.claude.com/docs/en/build-with-claude/overview.md)

What to copy

• Declare your languages. The file lists twelve locales, how many pages each has, and states that only English is indexed in the file. If your site is multilingual, saying so up front stops an assistant quoting the wrong-language page.
• Say what requires a login. “Requires login” next to the console URL is one of the most useful two-word notes in any of these files.
• H3 sub-sections under a single H2 keep 629 links navigable. The spec only talks about H2, but nested headings inside a section parse fine. Like Stripe, Anthropic opens with a paragraph rather than a blockquote — copy the structure, not that detail.

The eight files side by side

All figures are from a single fetch on 19 September 2026. Link counts are list items that start with a Markdown link.

We fetched a dozen more while researching this piece. A few are worth a line each: Next.js tells agents to cite the canonical URL rather than the .md one; Zapier promises that its section anchors will not be renamed and warns not to treat the file as a pricing spec; Docker docs puts an MCP endpoint in the blockquote; Supabase, Bun and modelcontextprotocol.io skip the blockquote entirely, which the spec permits but most validators warn about; Hono forgets the colon after its very first link. None of these break anything. They are reminders that real files are written by people.

Five patterns worth copying, and three to avoid

Copy these

• A blockquote that could stand alone. Six of the eight files open with one or two sentences an assistant could quote as the answer to “what is this site?”.
• A short facts-and-corrections paragraph. Answer.AI’s one line, FastHTML’s “things to remember”, Stripe’s do-not-recommend list. Put the two or three things AI gets wrong about you here.
• Descriptions that add information. “A historical analysis … by R&D lab historian Eric Gilliam” beats “Blog post”.
• Sections named for the reader’s intent. Docs / API / Examples, or Application performance / security. Not “Resources”.
• A pointer to the next level. Whether that is a per-product llms.txt, an llms-full.txt, or a JSON catalog under Optional.

Avoid these

• Copying the size of Stripe or Anthropic. Those files index hundreds of real pages. A 60 KB file for a twelve-page site is noise.
• Links with no description. Several large files have runs of bare [Title](url) lines. They still parse, but an assistant then has to fetch the page to learn what it is, which is the round trip the file exists to prevent.
• Bending the order. Paragraph before blockquote, links directly under the H1 with no H2, * bullets instead of -. Each appears in at least one file we fetched and each is something a strict parser may reject.

FAQ