AI search guide
llms.txt Example for SaaS, Documentation and Tool Websites
Use a practical llms.txt example for SaaS, documentation, and tool websites, with notes on what to include and avoid.
Simple llms.txt example
A simple llms.txt file should name the site, explain the public purpose in one or two sentences, and link to the most useful canonical resources. It should be short enough to review manually and clear enough that an automated reader can understand what the site is about.
Use a simple version when the site is early-stage or has only a few strong public pages. Do not pad it with archive pages, tag pages, redirected URLs, or pages that are blocked by robots.txt.
# Example Company Example Company provides public tools and documentation for AI search readiness. ## Start here - [Product overview](https://example.com/) - [Documentation](https://example.com/docs) - [Pricing](https://example.com/pricing) - [Support](https://example.com/support) This file is an emerging discovery aid and does not guarantee indexing, ranking, or citation.
A practical llms.txt example
Use this structure as a starting point, then replace each link with canonical public resources from your own site.
# Example SaaS Public resources for understanding Example SaaS. ## Product - [Overview](https://example.com/) - [Features](https://example.com/features) - [Pricing](https://example.com/pricing) ## Documentation - [Docs](https://example.com/docs) - [API reference](https://example.com/docs/api) ## Trust and support - [Support](https://example.com/support) - [Privacy policy](https://example.com/privacy) This file is an emerging discovery aid and does not guarantee indexing, ranking, or citation.
SaaS example
A SaaS llms.txt file should prioritize the product overview, features, pricing, integrations, documentation, security pages, support, and policies. The goal is to help automated readers find the most authoritative public explanation of the product.
Documentation site example
A documentation-heavy site should prioritize getting started guides, API references, changelogs, release notes, troubleshooting, and versioned docs. Avoid old versions unless they remain publicly supported.
# Example Docs ## Start here - [Getting started](https://docs.example.com/start) - [API reference](https://docs.example.com/api) - [Changelog](https://docs.example.com/changelog)
Tool website example
A tool website should prioritize the main tool page, examples, limits, privacy notes, support, and related guides. If the tool creates reports, include documentation that explains how to interpret those reports.
# Example Tool ## Tool resources - [Run the tool](https://example.com/tool) - [Examples](https://example.com/examples) - [How to interpret results](https://example.com/guides/results)
What not to include
Do not include private dashboards, staging hosts, internal documents, API keys, unpublished roadmaps, login-only URLs, tracking redirects, search result pages, or duplicate parameterized URLs. If a URL is not meant for public discovery, it does not belong in llms.txt.
Avoid unsupported promises such as guaranteed AI visibility, guaranteed LLM inclusion, or guaranteed citations. llms.txt is still an emerging convention, so the correct expectation is easier discovery of preferred public resources, not guaranteed use by any model or answer engine.
Mistakes to avoid
Do not copy an example verbatim. The file should describe your own site. Avoid listing every URL, including private resources, linking to redirected URLs, or making unsupported claims about guaranteed LLM visibility.
Validate the example before publishing
After adapting an example, validate that the file has a readable heading, useful canonical links, plain text output, and no conflicting robots.txt policy.
How llms.txt differs from robots.txt and sitemap.xml
robots.txt communicates crawl policy. sitemap.xml communicates canonical URL discovery for search systems. llms.txt communicates curated public context. The three files should support one another, but they do different jobs.
Before publishing an example, compare its links with robots.txt and sitemap.xml. If robots.txt blocks a URL, remove it from llms.txt or update the crawler policy. If a URL redirects, list the final canonical destination instead.
For tool and documentation sites, this comparison is especially important because useful pages often live under /docs/, /guides/, /api/, or /support/. Those directories are sometimes blocked during development and forgotten after launch.
Review checklist for examples
Before copying an example into production, replace every placeholder with a real canonical URL, remove pages that redirect, and verify that each destination has enough public text to explain the topic. A thin linked page does not become useful because it appears in llms.txt.
The strongest examples are specific to the site. A SaaS file should not look exactly like a documentation file, and a tool website should include pages that explain how to use and interpret the tool.