llms.txt for SaaS Docs: What to Include and What to Skip← Back to blog/Engineering<br>llms.txt for SaaS Docs: What to Include and What to Skip<br>The difficult part of llms.txt is not the format. It's deciding what deserves to be in the file at all.<br>Faizan Khan<br>2026-06-01 • 8 min read

Most bad llms.txt files fail for a boring reason: they are trying too hard to be complete. They include too many links, too much adjacent content, and not enough judgment.

That usually comes from a reasonable instinct. Nobody wants to leave out something important. But llms.txt is one of those cases where completeness is not the goal.

The job of the file is to narrow the search space for an agent.

So the real question is not "what can we include?" It is "what should an agent read first if it is trying to actually use this product?"

If you have not read the basics yet, start with What Is llms.txt? A Practical Guide for SaaS Docs Teams. If you are deciding how to structure the file mechanically, read How to Add llms.txt to Your Documentation Site.

This post is about the harder editorial question: what belongs in the file, and what should stay out?

Start From the Job the Docs Need to Do

For most SaaS products, an agent using your docs is trying to do one of a few things:

complete first-time setup

authenticate correctly

call the right endpoint or use the right SDK

fix an error

configure an integration

understand a concept that blocks implementation

That should shape the file.

llms.txt is not a brand surface. It is not a docs directory. It is not a page inventory. It is a curated task map.

If a page does not materially help one of those tasks, it probably does not belong in the first version.

What to Include

For most SaaS docs teams, the default keep-list is pretty stable.

1. The real quickstart

Not the page you call the quickstart. The page that actually gets someone to a successful first integration.

If your current quickstart is mostly marketing framing or architectural background, do not pretend it is the best first step. Use the page that gets the work done.

2. Authentication

This is almost always worth including.

If your product supports more than one auth model, make the recommended path obvious.

3. Core API or product entry point

For API docs, that might be the main API overview or a reference landing page.

For product docs, it might be the setup overview or the main workflow page.

4. Errors, rate limits, retries, or troubleshooting

These are disproportionately useful for agents because they show up mid-task, not just at the start.

5. Webhooks, SDKs, or integrations that represent real adoption paths

Include the things people actually use, not every possible integration surface.

6. One or two concept pages if the product has real architecture

If your docs require understanding environments, tenancy, sync models, or permissions before implementation makes sense, include those pages explicitly.

What to Skip

This is where most files get noisy.

1. Marketing pages

Do not include:

product overview pages written for buyers

pricing

generic landing pages

announcement posts

Even if those pages are technically part of the same site, they do not usually help an agent solve a docs task.

2. Changelog noise

A changelog can be useful, but most products should not treat it as core llms.txt material.

If one release introduced a breaking auth change or a new required integration path, maybe that deserves a mention elsewhere. But a long release note archive should not dominate the file.

3. Thin or outdated pages

If you would not send a new engineer there, do not send an agent there either.

llms.txt is not the place to preserve internal guilt about docs debt.

4. Duplicate versioned docs

If you have multiple versions of the same guide, choose the canonical one unless older versions are still active and materially different.

5. Internal tools, dashboards, or auth-gated pages

This sounds obvious, but it is worth saying. The file should reflect the useful public docs surface.

6. Giant link lists with no structure

Even if every page is individually valid, a wall of links is still a weak file.

The Useful Test: Would You Hand This to a New Engineer?

This is probably the best editorial test I know for llms.txt.

Open the file and ask:

If a competent engineer joined the team today, would this be a good starting map?

If the answer is yes, you are probably close.

If the answer is no, the problem is usually one of three things:

too many links

the wrong links

groupings that reflect internal org charts instead of user tasks

That test is simple, but it catches most of the mistakes.

What Different SaaS Docs Surfaces Usually Need

Not every docs site should include the same categories.

API docs

Bias toward:

quickstart

authentication

API overview

errors

rate limits

webhooks

primary SDKs

Help center

Bias toward:

getting started

workspace or account setup

permissions

billing

high-volume...