You added llms.txt to your SaaS product. Good start. But here's what most teams miss: the structure of that file — not just its existence — is what determines whether AI assistants actually surface your product when someone asks "which tool should I use for X."
SaaS sites are messy. Multiple products, dozens of features, pricing pages, docs, API references — all sharing one domain. A flat llms.txt that dumps everything in one place gives AI models almost no signal about what matters. And a file with nothing useful gets quietly ignored.
This guide is specifically about how to structure llms.txt for SaaS products — which sections you need, how to handle multi-product setups, what to cut, and the structural decisions that actually move the needle for AI discovery.
Why SaaS Sites Need a Different llms.txt Approach
The llms.txt standard works for any website, but it got popular through developer tools and docs sites — which are usually single-product and pretty straightforward. SaaS companies run into problems those sites do not have:
- Multiple products or modules serving different audiences with different needs
- Feature-heavy sites where AI models struggle to separate core value from edge functionality
- Use-case variation — the same product can solve completely different problems depending on the customer segment
- Pricing complexity that AI models almost always get wrong without explicit structure
The underlying problem: AI models read your llms.txt to build a mental model of what your product does. If that file does not accurately reflect your product's purpose and who it's for, the model gets the wrong picture — and recommends your competitor instead.
The Core Sections Every SaaS llms.txt Needs
A well-structured SaaS llms.txt has five sections you really cannot skip. These are not spec requirements — they are the specific pieces of context AI assistants use to decide whether to recommend you.
Product Description
Lead with a plain-English description of what your product does, who it serves, and what problem it actually solves. No marketing copy. No superlatives. Just specifics.
A weak product description:
"Acme is the leading AI‑powered platform for modern teams." — Meaningless to an AI model; it could describe anything.
A strong product description:
"Acme is a project management tool for software engineering teams that integrates with GitHub, Jira, and Linear. It's built for teams of 5–200 engineers who need sprint planning, backlog prioritization, and deployment tracking in one place." — Specific enough for an AI to act on.
Feature List (Organized by Job-to-Be-Done)
List your features, but do not organize them the way your product team organized the UI. Organize them by what the user is trying to accomplish. AI assistants respond to job-to-be-done framing — feature-module framing means nothing to them.
Instead of:
- Kanban boards
- Sprint planning module
- GitHub integration
Write it as:
- Plan and track engineering sprints
- Prioritize and manage the product backlog
- Automatically connect GitHub commits to active issues
Ideal Customer Profile
This is the most underused section in SaaS llms.txt files — and one of the highest-leverage things you can add. AI models use the ideal customer profile to decide whether to recommend you for a specific query. Skip it and the model guesses.
Example: "Best for: B2B SaaS companies with engineering teams of 10–500 people using agile methodology who need one place for planning, development, and deployment tracking."
Pricing and Plans
Include plan names, pricing tiers, and what each tier includes. AI assistants are asked "what does X cost" constantly — if that information is in your llms.txt, the AI answers correctly. If it is not, the AI guesses or says "check the website."
Key Documentation Links
Link to your most critical docs: getting started, API reference, integration guides, platform-specific pages. Cap this at 10–20 links. A longer list dilutes the signal — fewer links means more weight per link.
Structuring for Multi-Product SaaS
If your company runs multiple products under one brand — say a CRM, a marketing automation tool, and an analytics platform — a flat llms.txt that mixes all three will confuse AI models. They will not know which product to surface for a given query. The fix is a hierarchical structure.
| Setup | Recommended Structure | Why It Works |
|---|---|---|
| Single product, one domain | One flat llms.txt at root | Simplest setup; AI gets a complete picture in one read |
| Multiple products on subdomains | Separate llms.txt per subdomain + root file linking to each | Each product gets indexed independently |
| Multiple products, path-based routing on one domain | Root llms.txt with product sections + optional /product-a/llms.txt per product | Overview at root, deep context per product |
| Product site + docs site (docs.yourdomain.com) | Main domain file links to docs; docs site has its own llms.txt | Keeps marketing context separate from technical context |
The one rule that applies in every multi-product setup: never mix unrelated products in the same flat section. Use clear headings, keep each product's context self-contained, and do not make AI models guess which product a feature belongs to.
Organize by Use Case, Not Feature
Most SaaS companies structure their llms.txt the way their product is built — by feature module. That's the wrong organizing principle. AI models are queried by use case, not by what's in your navigation menu.
When someone asks ChatGPT "what's the best tool for managing engineering sprints," it's not looking for a product with a "sprint planning module." It's looking for a product description that matches "managing engineering sprints." Write your llms.txt to match how people actually query for solutions, not how your engineers named the internal features.
A use-case-first structure for a project management SaaS:
- Sprint and iteration planning — set sprint goals, plan work, track velocity over time
- Backlog management — create, prioritize, and groom the product backlog
- Developer workflow integration — connect GitHub, GitLab, or Bitbucket; link commits to active issues
- Reporting and metrics — cycle time, throughput, burn-down charts
- Cross-team visibility — roadmaps, dependency tracking, stakeholder updates
Every item describes something the user is trying to do — not a UI element or a product marketing term.
What to Leave Out
A llms.txt that tries to include everything ends up helping nothing. The signal-to-noise ratio matters. Cut these categories without hesitation:
- Blog posts and marketing content. They dilute the product context AI models are building. If you want to include content pages, use
llms-full.txtinstead — see llms.txt vs llms-full.txt When You Need Both for the distinction. - Changelog entries. Version history does not help an AI recommend your product. If a capability is worth surfacing, describe it in the product section instead.
- Support tickets and community forum threads. These are noisy and problem-focused, not capability-focused.
- Legal pages. Terms of service, privacy policy, compliance docs — none of this belongs in
llms.txt. - Low-traffic landing pages. If it is not a core use case or a high-intent conversion page, cut it.
The Integration Section Matters More Than You Think
For SaaS products, the integration section is often where AI recommendations are actually decided. When a user asks "does [tool X] integrate with Slack," the AI needs to find a direct answer — not infer one. A specific integration list makes that possible.
Structure it as a simple list under an "Integrations" heading. Name the integration, describe what it does in one line, and link to the relevant documentation.
Example format:
- Slack — Real‑time notifications for sprint updates, issue changes, and deployments.
/integrations/slack - GitHub — Auto‑link commits, PRs, and deployments to issues.
/integrations/github - Zapier — Connect with 5,000+ apps through no‑code automation.
/integrations/zapier
How to Build Your SaaS llms.txt
The fastest path: generate an initial draft automatically, then edit it into the use-case-first structure above. Generate your free llms.txt file — the tool pulls from your URL and creates a starting draft you can refine in minutes.
Once you have a draft, run through this sequence:
- Rewrite the product description with your exact customer segment and primary use case
- Convert feature lists from feature-module framing to job-to-be-done framing
- Add or expand the ideal customer profile section
- Verify pricing information is accurate, complete, and organized by plan name
- Curate documentation links down to the 10–20 most important pages
- Add the integrations section with one-line descriptions and per-integration doc links
- Cut blog posts, changelog entries, legal pages, and anything that does not serve the AI recommendation goal
Conclusion
How you structure your SaaS llms.txt determines whether AI assistants recommend your product or a competitor with better-organized context. Use-case framing, an explicit ideal customer profile, and a detailed integration list are the three things most SaaS teams skip — and the three that move the needle most. Start with a free generated draft and use this guide to build it into something that actually works.
Frequently Asked Questions
Do I need a separate llms.txt for each product in a multi-product SaaS?
Not always. If your products are on separate subdomains, separate files are cleaner. But if they share a domain, a single root llms.txt with clearly labeled product sections often performs better. The key requirement is that each product's context is self-contained — AI models should not have to guess which features belong to which product.
How long should a SaaS llms.txt be?
Shorter and more curated consistently outperforms longer and comprehensive. Target a file someone could read in under three minutes. If you're past 500 lines, you're probably including content that belongs in llms-full.txt, not the primary file.
Should I include pricing in llms.txt?
Yes. Pricing is one of the most common things users ask AI assistants about SaaS tools. Including plan names and price points — even just "starts at $X/month for teams up to Y users" — means the AI gives accurate answers. Without it, the AI guesses or deflects.
How often should I update my SaaS llms.txt?
Update it any time you launch a major feature, change pricing, add an important integration, or shift your ideal customer profile. Minimum: review it every quarter. A file that describes your product from a year ago can actively mislead AI models about what you offer.
Does llms.txt help with AI-generated search results like Google AI Overviews?
It can. Google's AI Overview and similar features pull from indexed content, and a well-structured llms.txt gives those systems cleaner context. The direct effect on AI Overviews is not fully documented, but the indirect effect — better AI assistant recommendations — is the established win.
What's the difference between llms.txt and a sitemap for AI purposes?
A sitemap lists which URLs exist. llms.txt tells AI assistants what your product actually does and who it's for. A sitemap has no semantic content — it's just paths. llms.txt is a curated, human-readable summary designed for machine comprehension. You need both, and they serve completely different purposes.
Can I write my llms.txt to target a specific AI model?
The standard does not support model-specific targeting — any compliant AI crawler can read it. The principles that help ChatGPT understand your product are the same ones that help Claude or Gemini understand it. Write for accuracy and clarity, not for a specific model's preferences.
Should I link to case studies and customer stories in my llms.txt?
Only if they're genuinely high-signal. A link like "Case study: Acme Corp reduced sprint planning time by 40% using [product]" is worth including — it creates a specific, queryable association. A link to a generic "Customer Stories" page adds noise without signal. Be selective.
What happens if my llms.txt has outdated information?
AI models that have cached your file will give users wrong answers — about features you've changed, prices that have shifted, or integrations you've added. Stale llms.txt files actively damage AI-driven discovery. Set a quarterly calendar reminder to review and update the file before it drifts too far from reality.
Do I need a developer to create or maintain llms.txt?
No. The file itself is plain text with Markdown formatting — any product manager, marketer, or founder can write and update it. Placing it at yourdomain.com/llms.txt requires server or CMS access, but that's usually a five-minute task for any developer. Use the generator to get an initial draft without writing anything from scratch.