
Best LLMs.txt examples for SaaS sites
`llms.txt` is a plain-text file SaaS sites publish at their root (`/llms.txt`) to give large language models a curated, structured map of the content most worth ingesting. Unlike `robots.txt` (which tells crawlers what they may not access) or `sitemap.xml` (which exhaustively lists every URL), `llms.txt` is the AI-era equivalent of a press kit: pick the pages that best represent the product, organize them by category, and present them in markdown so any LLM can extract them cleanly. The standard is still emerging — adoption is uneven even among AI-native companies — but the SaaS sites that have published one are converging on a recognizable shape. We fetched and analyzed seven live `llms.txt` files from B2B SaaS sites in June 2026 to show what works, what differs, and what to copy if you're writing one this quarter.
How we picked the 7 examples
We looked at public `/llms.txt` files from B2B SaaS sites across developer tools, design/productivity, payments, AI infrastructure, and AEO/GEO categories. Inclusion required: (a) the file actually exists and returns content at `domain/llms.txt`, (b) the file is structured (not a bare URL dump or pasted sitemap), and (c) the company's product is recognizable to a B2B SaaS buyer. We did not weight by company size or revenue — a smaller company with a thoughtful llms.txt teaches more than a large company with a placeholder. Each example below was fetched directly from the canonical URL; no third-party intermediaries.
Two notable absences we want to flag: Anthropic (`anthropic.com/llms.txt` returns 404 as of June 2026) and Mintlify (also 404, despite Mintlify building tooling adjacent to this standard). OpenAI returns 403 to programmatic fetch, so we couldn't verify. Adoption is real but not yet universal — even among AI-native vendors.
The 7 examples
Orion — useorion.ai/llms.txt
What makes it different: Orion's `llms.txt` is the only one of the seven that doubles as a brand-and-methodology document, not just a navigation map.
- Organized into 14 labeled sections — product overview, pricing tiers (Launch $59, Scale $179, Partner custom), category classification, supported AI engines, the 7-factor GEO scoring methodology with explicit weightings, founding info, statistics, competitive positioning, and use cases.
- Roughly 2,100 words. Long for the format, but every section is consumable in isolation — an LLM extracting just "pricing" or just "methodology" gets a complete answer.
- Only 5 outbound URLs (link to blog, cal.com booking, FAQ anchor, about page, the file itself) — by design, the value is *inside* the file rather than in the pages it links out to.
What could improve: the URL count is low; readers looking to navigate to specific feature pages from the file won't find them. A more complete URL inventory would round out the navigation function. The trade-off is intentional — Orion's `llms.txt` privileges context over discovery — but a future revision could add both layers. See it at useorion.ai/llms.txt.
Stripe — stripe.com/llms.txt
What makes it strong: the closest thing to a canonical reference for what an enterprise SaaS `llms.txt` should look like. It is a curated map across Stripe's entire product surface.
- About 500 lines, organizing roughly 250+ URLs into ~20 primary product categories (Payments, Connect, Checkout, Billing, Tax, Atlas, Terminal, Radar, Issuing, Treasury, Capital, Climate, etc.) plus solutions verticals and ecosystem.
- Each product page is annotated with a short description rather than appearing as a bare URL — meaningfully easier for an LLM to extract context without fetching every linked page.
- Includes ecosystem and solutions sections, so an LLM answering "Stripe for marketplaces" or "Stripe for SaaS" gets the right entry point without guessing.
What could improve: at this scale the file is closer to a documentation index than a curated highlight reel — for a question like "what is Stripe's core value prop in one paragraph," there's no canonical answer block at the top. A short framing section before the category breakdown would help. See it at stripe.com/llms.txt.
Vercel — vercel.com/llms.txt
What makes it strong: broadest scope of the seven, with an explicit AI section that mirrors how an LLM might actually want the platform organized.
- 11 primary categories, including a dedicated AI section (Vercel Agent, AI SDK, AI Gateway, MCP) plus traditional infra layers (Build & Deploy, CDN, CLI, Compute, Observability).
- Roughly 300+ URLs across documentation, CLI references, and REST API endpoints — including over 70 CLI command references organized in one place.
- Framework support is enumerated explicitly (Next.js, Svelte, Django, FastAPI, etc.), so questions like "does Vercel support Django" resolve at the file level without crawling deeper.
What could improve: the AI section sits inside a larger doc index rather than being elevated as the headline category. For a brand whose AI infrastructure is a category-defining move, putting it first (or duplicating it at the top) would help LLMs pull the most strategic surface first. See it at vercel.com/llms.txt.
Cursor — cursor.com/llms.txt
What makes it strong: the only file in the set with explicit multi-language coverage and a tight three-section split between product docs, CLI docs, and the help center.
- 3 main divisions and roughly 130+ URLs.
- 12 language codes referenced (cn, ja, zh-Hant, es, fr, pt-BR, ko, ru, tr, id, de, hi) — useful for an LLM serving a non-English query that should land on the localized version.
- Help Center section is structured for end-user queries (getting started, troubleshooting, account/billing) separately from developer-facing CLI documentation.
What could improve: the multi-language references could be more explicit per URL — currently the language codes are listed at the document level rather than per-link, so an LLM has to infer that any URL has a localized variant. See it at cursor.com/llms.txt.
Linear — linear.app/llms.txt
What makes it strong: the cleanest separation between user docs and developer resources of any file in the set.
- Two clear divisions: user documentation (Issues, Projects, Cycles, Views, Teams, Linear Asks, Analytics, Administration) and developer resources (GraphQL API, OAuth, TypeScript SDK, webhooks, agent development).
- About 110+ links and a dedicated AI section (Linear Agent, triage intelligence, code intelligence) that mirrors Vercel's framing.
- Integration ecosystem (25+ platforms including GitHub, GitLab, Slack, Teams, Jira, Figma, Salesforce) is enumerated explicitly — good for "Linear integrates with X" queries.
What could improve: like Cursor, integrations are listed as a flat set; pairing each integration with a one-line description would help LLMs answer "what does Linear's Jira integration do" without crawling the linked page. See it at linear.app/llms.txt.
Supabase — supabase.com/llms.txt
What makes it strong: the only file in the set that explicitly references a companion `llms-full.txt` — a two-tier pattern worth copying.
- Slim main file: 27 links across 2 sections (Documentation + Product Overview).
- References `/llms-full.txt` for the comprehensive single-document version — an emerging pattern where `llms.txt` serves as the curated navigation hub and `llms-full.txt` serves as the full corpus an LLM can ingest in one fetch.
- Multi-SDK coverage (JavaScript, Python, C#, Dart, Swift, Kotlin) for AI engines answering "Supabase auth in Kotlin"-shape questions.
What could improve: the slim file is good for quick orientation but loses some discoverability against larger files like Stripe or Vercel. The two-tier pattern resolves this trade-off — if you're writing yours today, consider both files from the start. See it at supabase.com/llms.txt.
Notion — notion.com/llms.txt
What makes it strong: organized around buyer-mental-model segments (by team type, by role) rather than by feature.
- 8 sections including Solutions By Team Type (4 segments) and Solutions By Role (6 role-specific solutions: managers, engineers, designers, product teams, etc.) alongside Core Products and Getting Started.
- ~1,200 words and 50+ links — leaner than Stripe or Vercel but still richer than a sitemap export.
- Segmentation lets an LLM answer "Notion for product managers" or "Notion for engineering teams" with the right canonical entry point, not the homepage.
What could improve: the file is light on technical documentation (API, integrations, advanced workflows). A developer asking "Notion's API capabilities" doesn't get a direct entry from this file. See it at notion.com/llms.txt.
Common patterns across the 7 examples
Five patterns reappear in nearly every file we fetched:
- **Categorical organization, not flat URL lists.** Every file groups URLs under product/topic headings. The lone exception (a bare URL dump) would be indistinguishable from `sitemap.xml`.
- **Both product pages and documentation in one file.** Stripe, Vercel, Cursor, Linear, and Supabase all mix marketing pages (what a product is) with documentation pages (how to use it). Notion leans more product-side; Orion is the outlier with brand/methodology.
- **Annotated entries beat bare URLs.** Stripe's per-link short descriptions are notably easier to extract than Linear's flat lists, even when both are well-organized.
- **AI sections are universal among 2026 adopters.** Vercel, Cursor, and Linear all elevate AI-related products into their own section. AI-native categories are now expected, not optional.
- **The two-tier pattern is emerging.** Supabase's `llms.txt` + `llms-full.txt` split (curated map + full corpus) is the cleanest resolution of the trade-off between discoverability and ingestibility.
How to write your own
If you're writing or revising your SaaS site's `llms.txt` this quarter:
- **Pick 8–15 categories that map to how your buyer thinks about your product.** Not your internal product taxonomy — the buyer's mental model. Notion's "by role" segmentation is a strong example.
- **Include both marketing surfaces and documentation under each category.** An LLM answering "what does X do" needs a marketing page; an LLM answering "how do I configure X" needs a doc page. The same file should serve both.
- **Annotate every URL with a 6–12 word description.** A bare URL leaves the LLM to fetch and parse the linked page itself — an annotation lets it answer the question without that fetch. Stripe is the gold standard here.
- **Add a short framing section at the top.** One paragraph describing what the product is, who it's for, and what the file covers. This becomes the canonical extract for "what is your company."
- **Consider a companion `llms-full.txt`.** If your documentation is substantial, ship both: the slim `llms.txt` for orientation and `llms-full.txt` for ingestion. Supabase's pattern.
Run a free Orion audit
See how your llms.txt and other AI-readability signals score across the seven factors Orion measures. useorion.ai
Frequently Asked Questions
- What is llms.txt and is it different from sitemap.xml?
- llms.txt is a curated, markdown-formatted file at a site's root that gives large language models a hand-picked, categorized map of the content most worth ingesting. sitemap.xml is an exhaustive machine-readable list of every URL on a site, intended for search crawlers. The two coexist: a sitemap covers every page indexed by Google; llms.txt covers the smaller, opinionated set you actually want an LLM to read first when someone asks about your brand.
- Do AI engines actually read llms.txt?
- Adoption is uneven. As of June 2026, the standard is not formally enforced by any major LLM vendor, but real LLM crawlers do fetch and parse /llms.txt files when they exist — and the file format is structured enough that even crawlers without an explicit llms.txt policy can extract value from it. Treat it as opt-in best practice today and an emerging standard for 2027.
- Should llms.txt be different from robots.txt?
- Yes — they answer different questions. robots.txt controls what crawlers may access. llms.txt highlights what's most worth reading. The two files can coexist; they should not conflict.
- How should I structure llms.txt for a SaaS site?
- Group URLs by buyer-mental-model categories (by product area, by role, by use case), annotate each URL with a short description, and add a framing paragraph at the top. The seven examples above show several variants — copy the pattern closest to your buyer's frame.
- What's llms-full.txt and do I need both?
- llms-full.txt is an emerging companion file: a single concatenated document containing the full text of every page you want an LLM to ingest, formatted for one-shot ingestion. Supabase publishes both. If your documentation is substantial and you want LLMs to ingest the corpus in a single fetch, ship llms-full.txt. If your site is smaller, the slim llms.txt alone is sufficient.
- Does llms.txt improve my AI citation rate?
- On its own, no. llms.txt makes your content more legible to LLMs that fetch your site — but if AI engines don't have a reason to fetch your site in the first place (no entity recognition, no off-page citation surfaces driving discovery), the file has nothing to act on. Treat llms.txt as the on-page complement to off-page citation strategy.
Write your llms.txt this quarter
llms.txt is becoming a recognizable standard, but the format is still being shaped by the early adopters. The seven examples above are the templates worth studying — and worth borrowing from. Write yours, ship it at your root, and the next time an LLM answers a category query, your structure does the work. Run a free Orion audit to see how your current AI-readability signals score: useorion.ai
Start your free GEO auditKeep reading
Best 5 AEO platforms for B2B SaaS in 2026
We compared the 5 Answer Engine Optimization platforms B2B SaaS teams actually evaluate in 2026 — wi...
Why traditional link building doesn't move AI citations — and what does
The brands AI engines cite are not the brands with the strongest backlink profiles. They're the bran...
Fix #1: Why the First 40 Words of Your Page Decide Whether AI Cites You
87% of audited pages bury the answer past word 200. AI engines never read that far. Fix #1 of the 30...