llms.txt examples: real files from real sites, annotated

A good llms.txt file is a one-page Markdown briefing: an H1 with your site's name, a one-line blockquote saying what it is, and a few H2 sections of curated links with descriptions. Below are complete examples for four common site types, with notes on what each one gets right.

The minimal starter (any site)

The smallest file that's still genuinely useful:

# Acme Inc

> Acme makes project management software for remote engineering teams.

## Key pages

- [Product overview](https://acme.com/product): What Acme does and who it's for
- [Pricing](https://acme.com/pricing): Plans, costs, and what's included
- [Docs](https://acme.com/docs): Setup guides and API reference
- [About](https://acme.com/about): Company background and team

Why it works: an AI assistant reading this knows in five lines what Acme is, what it costs, and where the details live. The blockquote does heavy lifting — it's the sentence a model is most likely to reuse when describing the site.

A documentation site

Docs sites benefit most from llms.txt, because their value is spread across hundreds of pages that a model can't prioritize on its own:

# FastAPI-Style Docs

> Python web framework for building APIs, with automatic docs and type hints.

## Getting started

- [Installation](https://example.dev/install): Requirements and pip install steps
- [First steps](https://example.dev/tutorial): Minimal app in 10 lines
- [Path parameters](https://example.dev/params): Typed route parameters

## Reference

- [Request body](https://example.dev/body): Pydantic model validation
- [Security](https://example.dev/security): OAuth2, JWT, API keys

## Optional

- [Deployment](https://example.dev/deploy): Docker, cloud, and server setups
- [Release notes](https://example.dev/changelog): Version history

What to copy: the ## Optional section is part of the proposed spec — it marks content an AI can skip when context is tight. Put changelogs, edge-case guides, and archives there.

An e-commerce store

Stores shouldn't list products (they change too often) — they should list the pages that answer buyer questions:

# Northwind Outfitters

> Outdoor gear retailer specializing in ultralight backpacking equipment,
> shipping across North America.

## Shop

- [All categories](https://northwind.shop/categories): Tents, packs, sleep systems, cooking
- [Best sellers](https://northwind.shop/best-sellers): Most popular gear this season

## Customer questions

- [Shipping policy](https://northwind.shop/shipping): Costs, times, and regions served
- [Returns](https://northwind.shop/returns): 60-day return window and process
- [Size guides](https://northwind.shop/sizing): Pack torso sizing and apparel charts

Why it works: when a shopper asks an AI assistant "does Northwind ship to Canada, and what's their return policy?", the file points the model straight at authoritative answers instead of letting it guess from a category page.

A SaaS product

# Signalboard

> Signalboard turns product analytics into weekly plain-English summaries
> for non-technical founders.

## Understand the product

- [How it works](https://signalboard.io/how-it-works): Data sources, processing, output
- [Pricing](https://signalboard.io/pricing): Free tier and paid plans compared
- [Security](https://signalboard.io/security): Data handling, SOC 2, retention

## Compare

- [Signalboard vs. dashboards](https://signalboard.io/vs-dashboards): When summaries beat charts

## Optional

- [Blog](https://signalboard.io/blog): Product updates and analytics guides

What to copy: the comparison page. When users ask AI assistants "Signalboard vs X", you want the model reading your framing of that comparison, not reconstructing it from third-party mentions.

Patterns across every good example

Looking at the files above — and at real published files from companies like Anthropic, Mintlify-hosted docs sites, and the growing list at llms.txt directories — the same patterns repeat:

• One H1, and it's just the name. Not a tagline, not keywords. The blockquote underneath carries the description.
• Every link has a description. A bare URL list tells a model nothing about which link answers which question. The [Title](url): description format is the core of the spec.
• Sections group by user intent, not by your CMS structure — "Customer questions" beats "Pages".
• The whole file reads in under a minute. If you're pasting your sitemap, you've missed the point.
• It stays current. A file pointing at dead URLs is worse than no file — models lose trust in the source. Regenerate it when your key pages change.

Common mistakes these examples avoid

1. HTML instead of Markdown — llms.txt must be plain text. If your server returns your 404 page's HTML at /llms.txt, the file doesn't exist as far as any parser is concerned.
2. Dumping every URL — curation is the entire value. Hundreds of links make the file no better than a sitemap the model already ignores.
3. Marketing copy in descriptions — "The world's most innovative platform" tells a model nothing. "Plans, costs, and what's included" does.
4. Forgetting the blockquote — it's the single most-reused line in the file. Write it like the one-sentence answer to "what is this site?"

Build and check yours

Copy whichever example matches your site type, replace the content, and put the result at your domain root as /llms.txt. Or skip the manual work: the llms.txt Generator builds a spec-compliant file from a form (it can even prefill links from your sitemap), and the llms.txt Validator checks any live file against the spec — including the examples on this page.