What Is llms.txt? A Practical Guide for SaaS Docs Teams

If you run a docs site for a SaaS product, you already publish structure for humans and search engines. You have navigation for people. You probably have a sitemap.xml for Google. llms.txt is the missing layer for AI agents: a small file that tells them where your useful documentation lives and where to start.

It is not complicated. It is not a new protocol stack. It is just a practical way to make your docs easier for agents to discover.

This post covers what llms.txt is, what to put in it, how SaaS docs teams should think about it, and where it stops being enough.

The public spec at llmstxt.org is short and worth reading. What follows is the practical version for teams maintaining real product docs.

What llms.txt Is

llms.txt is a plain-text or markdown file, usually served at the root of a docs site, that gives AI agents a curated index of your documentation.

Think of it as a hand-written map.

Not a crawler dump. Not every URL on your site. Just the pages an agent should actually read first.

A minimal version looks like this:

1# Acme Docs
2
3Acme's developer documentation for authentication, API requests, webhooks,
4rate limits, and SDK setup.
5
6## Start Here
7
8- [Quickstart](https://docs.acme.com/quickstart): Set up your first API request
9- [Authentication](https://docs.acme.com/authentication): API keys, OAuth, and scopes
10- [Errors](https://docs.acme.com/errors): Error codes and retry guidance
11
12## Common Tasks
13
14- [Webhooks](https://docs.acme.com/webhooks): Receive event notifications
15- [Rate Limits](https://docs.acme.com/rate-limits): Understand limits and backoff
16- [Node SDK](https://docs.acme.com/sdks/node): Integrate with Node.js

That is the core idea. Give the model a small, opinionated set of entry points instead of making it guess.

Why SaaS Docs Teams Should Care

More people are using AI tools as the first interface to your docs.

They paste a URL into Claude Code. They ask Cursor how to authenticate with your API. They ask ChatGPT how to set up webhooks for your product. In all of those cases, the model has to figure out where the useful documentation is and which pages matter.

If your docs are well structured, a model can usually muddle through. But llms.txt gives it a shortcut:

• what your product docs cover
• which pages matter most
• where to start for common tasks
• which references are canonical

That is especially useful for SaaS docs because most products have the same failure mode: too many pages, too much duplication, and no obvious "start here" path for a machine.

Humans can recover from that by browsing. Agents are much better if you point them directly.

What Goes in a Good llms.txt

The easiest mistake is treating llms.txt like a full export of your docs.

That usually makes it worse.

A good llms.txt is short, curated, and biased toward pages that help an agent complete real tasks.

For most SaaS docs teams, include:

• a one-sentence description of the product or docs set
• the quickstart or first successful integration path
• authentication or authorization docs
• API reference entry points
• common operational topics like errors, rate limits, and webhooks
• SDK pages if they are real adoption paths
• one or two pages for core concepts if your product has non-obvious architecture

If you support multiple audiences, group the links:

1## API Basics
2- [Quickstart](...)
3- [Authentication](...)
4- [Rate Limits](...)
5
6## Integrations
7- [Webhooks](...)
8- [Zapier](...)
9- [Slack integration](...)
10
11## SDKs
12- [Node SDK](...)
13- [Python SDK](...)

This is easier for a model to use than one giant flat list.

What to Leave Out

The second mistake is stuffing llms.txt with everything adjacent to documentation.

Do not use it as a sitemap replacement.

Usually leave out:

• marketing pages
• changelog noise unless it is critical for current API behavior
• duplicate versioned pages if one version is canonical
• broken, outdated, or thin pages
• internal dashboards or pages behind auth
• giant link lists with no explanation

If a page is not something you would send a new developer to on day one, it probably does not belong near the top of llms.txt.

The file should reduce ambiguity, not create more of it.

How to Add llms.txt to Your Docs Site

For most teams, the implementation is boring in a good way.

1. Pick the canonical host

If your docs live on docs.example.com, publish it there. If your main documentation lives on example.com/docs, publish it on the same host users actually rely on.

2. Start with the top 10 to 20 pages

Do not try to solve completeness first. Solve usefulness first.

Write the file like a high-signal onboarding note for an engineer:

• what this docs set is
• what to read first
• where to go for common tasks

3. Serve it at /llms.txt

That is the convention agents and tooling are starting to expect.

4. Test it manually

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

If the file is hard to read as plain text, it is probably hard for a model too.

5. Keep it maintained

If your quickstart changes, your auth model changes, or a new SDK becomes the default path, update llms.txt too. Treat it like a small piece of product infrastructure, not a one-time SEO artifact.

llms.txt vs sitemap.xml

These files do different jobs.

sitemap.xml is a crawler-oriented inventory. It tells search engines which URLs exist and when they changed.

llms.txt is a curated guidance layer. It tells AI agents which URLs are worth reading and how the docs are organized at a high level.

That difference matters.

A sitemap is optimized for completeness. A good llms.txt is optimized for usefulness.

If you already have a great sitemap, that helps with discoverability in one sense. But it still does not tell a model:

• which page is the real quickstart
• whether OAuth or API keys are the recommended auth path
• where the webhook docs live
• which reference pages matter most

That is the gap llms.txt fills.

What llms.txt Does Not Solve

This is the part most teams miss.

llms.txt helps with discovery. It does not automatically make your docs cheap to consume, easy to interpret, or agent-ready in the deeper sense.

It does not fix:

• bloated HTML pages
• weak information architecture
• missing decision tables
• broken examples
• unclear product boundaries

And it does not tell an agent how to use your product well. For that, you may also want a skill.md file, better markdown delivery, or a more structured docs experience overall.

That is why we treat llms.txt as the first layer, not the whole solution. If you want the systems view, we already wrote that up in llms.txt Isn't Enough.

A Practical Starting Template

If you want a simple starting point, use 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.yourproduct.com/quickstart): Make your first request
9- [Authentication](https://docs.yourproduct.com/authentication): API keys and OAuth
10- [API Overview](https://docs.yourproduct.com/api): Core endpoints and concepts
11
12## Common Tasks
13
14- [Webhooks](https://docs.yourproduct.com/webhooks): Receive and verify events
15- [Errors](https://docs.yourproduct.com/errors): Debug common failures
16- [Rate Limits](https://docs.yourproduct.com/rate-limits): Handle retries and backoff
17
18## SDKs
19
20- [Node SDK](https://docs.yourproduct.com/sdks/node)
21- [Python SDK](https://docs.yourproduct.com/sdks/python)

That is enough to ship a useful first version.

You can always expand it later once you see how people and tools use it.

The Right Way to Think About It

Do not think of llms.txt as an SEO hack.

Think of it as a documentation affordance for agents.

Humans benefit from sidebars, breadcrumbs, and curated quickstarts. Agents benefit from the same kind of editorial judgment, just expressed in a smaller and more explicit format.

If your docs team already knows which pages matter most, llms.txt is simply the place to write that down in a machine-readable way.

And if you stop there, that is still a meaningful improvement.

If you want the next layer after that, add markdown delivery, cleaner docs structure, and a skill.md that tells agents how to use your product well.