How to Add llms.txt to Your Documentation Site

Adding llms.txt to a docs site is not the hard part. The hard part is avoiding the two obvious mistakes:

1. treating it like a one-time SEO checkbox
2. turning it into a badly formatted sitemap

The mechanics are boring. You write a small text file, serve it at /llms.txt, and make sure it points to the right docs.

The judgment is the real work. You have to decide what an agent should read first, which pages are canonical, and what deserves to stay out.

This post is the implementation version. If you want the conceptual overview, start with What Is llms.txt? A Practical Guide for SaaS Docs Teams. If you want examples of good structures, read llms.txt Examples: Real Patterns for API Docs, Help Centers, and Developer Docs.

Start With the Real Goal

Before you touch the file, decide what you want it to do.

For most documentation sites, the goal is not "make every page discoverable." You already have internal links and probably a sitemap for that.

The real goal is narrower:

• tell an agent what this docs set covers
• point it at the best starting pages
• reduce ambiguity about the right path

That sounds small, but it changes how you write the file.

If you start from "what pages matter most for a successful implementation?" you usually get a good llms.txt.

If you start from "how do I include everything?" you usually get garbage.

Step 1: Pick the Canonical Docs Host

Publish llms.txt on the host where your real docs live.

Examples:

• https://docs.example.com/llms.txt
• https://example.com/docs/llms.txt

This sounds obvious, but teams get it wrong surprisingly often. They put the file on the marketing domain while the actual docs live somewhere else, or they publish multiple copies across hosts with slightly different content.

Do not do that unless you genuinely maintain separate documentation sets.

Agents should have one obvious place to look.

Step 2: Choose 10 to 20 Pages, Not 200

This is the most important part.

Start with the pages that get someone from "I know nothing" to "I can use this product without guessing."

For API docs, that usually means:

• quickstart
• authentication
• core API overview
• errors
• rate limits
• webhooks
• one or two SDK pages

For product or support docs, it might mean:

• getting started
• workspace or account setup
• permissions
• billing
• common troubleshooting pages

If your first draft has 60 links, it is probably not curated enough.

The file should feel like a technical onboarding note, not a full export.

Step 3: Group Links by Real Tasks

A flat list works for tiny docs sets. It breaks down quickly for real products.

Use headings that reflect how people and agents actually navigate the work:

1# Acme API Docs
2
3Developer documentation for Acme's REST API, SDKs, authentication,
4webhooks, and rate limits.
5
6## Start Here
7
8- [Quickstart](https://docs.acme.com/quickstart): Make your first request
9- [Authentication](https://docs.acme.com/authentication): API keys and OAuth
10- [API Overview](https://docs.acme.com/api): Core resources and request model
11
12## Core Tasks
13
14- [Create a customer](https://docs.acme.com/customers/create)
15- [Handle webhooks](https://docs.acme.com/webhooks)
16- [List invoices](https://docs.acme.com/invoices/list)
17
18## Operational Docs
19
20- [Errors](https://docs.acme.com/errors)
21- [Rate Limits](https://docs.acme.com/rate-limits)
22- [Pagination](https://docs.acme.com/pagination)

This is still simple Markdown, but it carries much more signal than a raw link dump.

Step 4: Write Short Descriptions Where They Earn Their Keep

Descriptions are useful when they disambiguate.

Good:

• Authentication: API keys, OAuth, scopes, and token refresh
• Errors: Error codes, retries, and failure handling
• Quickstart: Make your first authenticated request

Bad:

• Authentication: Learn about authentication
• Quickstart: Quickstart guide

You do not need descriptions for every line, but when a page title is vague or there are multiple plausible entry points, one short clarifying phrase helps a lot.

Step 5: Publish It at /llms.txt

Once you have the content, the file itself is easy.

If you run a static docs site, this may be as simple as adding a new file to the public output.

If you run a web framework, you can either:

• serve a static file
• or generate it from a small source of truth

The boring static-file approach is usually fine.

Example:

1curl https://docs.example.com/llms.txt

If that returns a clean plain-text or markdown file, you are most of the way there.

Step 6: Keep the File Human-Readable

This matters more than people think.

If the file is painful for a human engineer to scan in a terminal, it is probably overgrown.

A good check is: can someone open the file and understand the docs structure in under 30 seconds?

If not, shorten it.

This is one reason I prefer hand-maintained or lightly generated llms.txt files over fully automated exports. The automation is seductive, but it tends to optimize for completeness instead of clarity.

Step 7: Update It When the Recommended Path Changes

llms.txt is only useful if it reflects your current docs reality.

That means you should update it when:

• the quickstart changes
• a different SDK becomes the default recommendation
• the auth flow changes
• you launch a new canonical integration path
• old docs are deprecated

You do not need to edit it every week. You do need to treat it like part of the docs system instead of a launch artifact that never gets touched again.

A Concrete Next.js Example

If your docs are served through Next.js, the simplest option is often just to place the file in public/llms.txt.

That gives you:

1public/
2  llms.txt

And the file is served from:

1https://docs.example.com/llms.txt

If you want the file to be generated from shared metadata, you can also create a route that returns plain text. That is useful if you want to keep the links in sync with another source of truth, but it is not required.

The static version is easier to reason about and harder to accidentally break.

Common Failure Modes

1. Publishing it on the wrong host

If your docs are on docs.example.com and the file is on example.com, you are making the system harder to use.

2. Dumping every docs URL into the file

This turns the file into a second-rate sitemap.

3. Linking to stale or duplicate pages

If you have two auth guides and only one is canonical, pick one.

4. Using internal taxonomy instead of task language

Agents benefit more from Quickstart, Errors, and Webhooks than from labels like Platform, Resources, or Knowledge.

5. Expecting llms.txt to fix weak docs

It helps with discovery. It does not fix bad examples, unclear architecture, or huge HTML blobs.

We wrote more about that here: llms.txt Isn't Enough.

A Practical Template

If you want a good starting point, use something like this:

1# Your Product Docs
2
3Technical documentation for Your Product. Covers setup, authentication,
4API usage, SDKs, webhooks, rate limits, and troubleshooting.
5
6## Start Here
7
8- [Quickstart](https://docs.example.com/quickstart): First successful integration
9- [Authentication](https://docs.example.com/authentication): API keys, OAuth, and scopes
10- [API Overview](https://docs.example.com/api): Core resources and request model
11
12## Common Tasks
13
14- [Webhooks](https://docs.example.com/webhooks): Receive and verify events
15- [Errors](https://docs.example.com/errors): Understand failures and retries
16- [Rate Limits](https://docs.example.com/rate-limits): Backoff and request limits
17
18## SDKs
19
20- [Node SDK](https://docs.example.com/sdks/node)
21- [Python SDK](https://docs.example.com/sdks/python)

That is enough to be useful.

You can always add nuance later.

The Short Version

If you want the practical checklist, it is this:

1. publish one llms.txt on the canonical docs host
2. keep it short
3. link the pages that matter for real tasks
4. group them by how the work actually happens
5. maintain it when the recommended path changes

The implementation is easy.

The part that matters is editorial discipline.

That is also why a good llms.txt is a docs quality signal in disguise. Teams that know which pages matter can write one quickly. Teams that cannot usually discover that the file is exposing a deeper information architecture problem.