How long should a SaaS llms.txt be?

Keep the root file a few kilobytes and let it route. Three production files fetched on September 30, 2026 land in that range: Supabase ships 3.2KB across four sections, Vercel 4.8KB across nine, and Resend 7.5KB across seventeen. Resend is the upper end of comfortable because several of its sections carry a one-line description. Anything much larger usually means documentation content got concatenated into the index — that belongs in a subpath file or llms-full.txt. Stripe's documentation file, for comparison, is 92KB, which is a full-content file rather than an index.

Should I put pricing in llms.txt?

Yes, as a link — never as a description full of numbers. Pricing is the fastest-rotting content on a SaaS site: plans get renamed, seats get repriced, free tiers get moved behind a card. A one-line description saying the pricing page covers plans and per-seat cost survives a repricing; a line quoting dollar amounts is wrong within a quarter, and it is wrong in a file an assistant may quote verbatim. Link the pricing page or its Markdown twin and re-check the link whenever pricing changes.

Do I need a separate llms.txt for help.example.com or docs.example.com?

Yes, if those hostnames serve real content. A file covers the URLs under its own path on its own host, and a client uses the most specific file that covers the URL it is working in. That means a docs subdomain needs its own /llms.txt — link to it from the root file the same way you would link a subpath file, or nothing connects the two and the client never learns it exists.

SaaS · September 2026

llms.txt for SaaS: Which Pages to List

Most verticals have one reader in mind. A SaaS site has two: the buyer comparing plans, and the developer or agent trying to finish an integration task. Here is the page list that serves both, drawn from the files Vercel, Supabase and Resend ship today.

One File, Two Indexes

A local business llms.txt points at services and a booking page. A SaaS file has to carry a marketing index — what the product is, who it is for, what it costs — and a technical index — docs, API reference, SDKs — without becoming a dump of the whole documentation tree. The files that do this well share one structural habit: the marketing half gets prose, the technical half gets links to machine-readable assets.

Resend's file shows the pattern in its opening lines. Beside a one-sentence summary it lists concrete things an agent can do — send a transactional email with POST https://api.resend.com/emails, batch up to a hundred messages, manage contacts and segments — phrased as capabilities rather than navigation. That is the difference between a table of contents and a briefing.

The Eight Buckets Every SaaS File Needs

Sitemap imports produce alphabetical chaos. Group instead into these buckets, in this order, and the file reads like a product brief:

Bucket	Typical targets	Question it answers
Product overview	/product, /why-us	What is this, in one page?
Docs index	/docs/llms.txt or /docs/sitemap.md	How do I do the task?
API contract	/openapi.json, SDK pages	What are the exact request shapes?
Pricing	/pricing or /pricing.md	What does it cost?
Changelog	/changelog	Is this current?
Integrations	/integrations, /mcp	Does it connect to my stack?
Trust	/security, /enterprise, /status	Will procurement sign off?
Self-serve onboarding	/signup, CLI token docs	How does a user start in five minutes?

The last two rows are the ones most SaaS files skip, and they are the ones that turn a read into an action. Vercel's file dedicates a section literally called Self-serve onboarding to domain search, the Hobby plan and CLI tokens — all public, all unauthenticated. Resend devotes separate sections to Enterprise (SLAs, security and compliance, contacting sales) and Support.

Instruction Slots Beat Navigation

Vercel and Resend both open with a When to use section, and Vercel adds a second one describing how agents should use the site. These are not marketing copy — they are usage instructions that survive being quoted. For a SaaS product with a specific job, an instruction slot answers the question an agent cannot infer from your feature list: which of the fifty things this platform does should it reach for right now. Both files use the summary blockquote for the one-sentence pitch; Supabase, in the version checked, omits it entirely and gets straight to links, which is legal but throws away the cheapest prose slot in the file.

Write each link annotation as the question the page answers, the same discipline used in the description rules.

Pricing Is the Volatile Section

Supabase handles pricing the way an index should: one link, no numbers. Its entire pricing section is a single line pointing at the pricing page's Markdown twin. That is the right call for a live pricing table and the wrong place to be clever.

Three rules keep this section from rotting: link the pricing URL, never restate amounts or plan names, and treat any pricing change as a trigger to re-check the file. That last part is how a file goes quietly wrong — see the maintenance system for a ten-minute quarterly pass that catches it.

Split the Docs, Link the Twins

Documentation is where a SaaS file wants to grow, and where growth hurts most. The spec supports subpath files, and a client uses the most specific file covering the URL it is working in — so keep /llms.txt as the company-level index and put the dense subtree at /docs/llms.txt, linked from the root file like any other page. Product documentation with no marketing half — the kind covered in the API docs playbook — can live entirely in that subpath file.

Point at Markdown twins wherever they exist. Supabase links the .md version of every guide and product page; Resend appends .md to pricing, enterprise and changelog links and documents that Accept: text/markdown works too. When clients should receive whole page text rather than an index, that is a separate file with its own budget — Vercel and Supabase both point at llms-full.txt from the top of the index.

What Never Goes In

Application hosts. app.example.com, /dashboard, /billing, /settings — nothing there is readable without a session.
Per-tenant URLs. A customer's workspace subdomain is someone else's data and a leak waiting to be indexed.
Signed links and tokens. Presigned asset URLs, invite links, API keys in a query string.
Gated content described as if public. If the page needs a login, listing it invites a fetch that returns a redirect wall. The triage rules cover the borderline cases.
Every release note. Link the changelog index once; a flat list of four hundred entries doubles the file and answers nothing.

Verify It in Three Commands

# status and delivery
curl -sI https://example.com/llms.txt | grep -iE "^(HTTP|content-type)"

# size sanity — a SaaS index should be low single-digit KB
curl -s https://example.com/llms.txt | wc -c

# find links that 404, including your .md twins
curl -s https://example.com/llms.txt | grep -oE "https://[^)]+" | while read u; do
  printf "%s %s\n" "$(curl -s -o /dev/null -w '%{http_code}' -L "$u")" "$u"
done | grep -v "^200"

Run the same URL through the llms.txt checker to confirm the structure held after whatever generated it, or start from the generator with your sitemap and delete the dashboard and archive noise it cannot judge. A SaaS file earns its keep when it gives an agent the price page, the docs root, the API contract and the signup path in one fetch — everything else is decoration.

Files referenced were fetched on September 30, 2026: Supabase 3,242 bytes, Vercel 4,766 bytes, Resend 7,521 bytes, Stripe documentation index 92,181 bytes. Sizes change as these companies edit their indexes.