Most llms.txt files I review on SaaS sites are technically valid and practically useless. They have the H1, a one-line summary and forty links dumped from the sitemap in no particular order. A language model that reads one learns almost nothing about what the product does or which pages answer which questions. This article walks through annotated llms.txt examples line by line, so you can see what separates a file that helps an AI system from one that only exists.
I am assuming you already know what the file is and why it exists. The focus here is on the anatomy of good examples: how each section is built, what a SaaS company should put in it, how a minimal file compares with a full one, and where the file stops mattering for Google rankings and AI citations.
An llms.txt file is a markdown document served at the root of a domain (yoursite.com/llms.txt) that gives language models a curated, plain-text map of a site's most useful pages. It matters to SaaS teams who want ChatGPT, Claude, Perplexity and Gemini to find accurate product, pricing and documentation content without parsing navigation menus, scripts and cookie banners.
The Anatomy of a Spec-Compliant llms.txt File
A compliant llms.txt file is a short markdown document with a fixed order of sections. The proposal maintained by Answer.AI defines that order, and every good example follows it. The order matters because parsers built for the format, and the models reading the file directly, expect the identity of the site first, then context, then links.
According to the AnswerDotAI llms-txt specification on GitHub, a file following the spec contains an H1 with the name of the project or site, which is the only required section, and a blockquote with a short summary containing key information necessary for understanding the rest of the file. Everything after that is optional but expected in practice.
- An optional byte-order mark at the very start of the file
- An H1 with the site or product name (the only required element)
- A blockquote summary that states what the product is and who it serves
- Zero or more paragraphs or lists of free-text context, with no headings
- Zero or more H2 sections, each containing a markdown list of links with optional notes
- An H2 titled Optional, holding secondary links a model can skip when context is tight
There is no governing body enforcing that structure. As of mid-2026, llms.txt is a community convention with no backing from the IETF, W3C, or any recognized standards body. That has a practical consequence: validators and generators disagree at the edges, and the safest example is one that follows the original proposal exactly.
The H1 and the summary blockquote
The H1 is the name of your product, nothing else. I have seen files that put a tagline in the H1 (for example, # Acme: The Best Analytics Platform for Modern Teams). That pushes marketing copy into the one line a parser treats as an identifier. Keep the H1 to the brand or product name a user would type into ChatGPT.
The blockquote does the real positioning work. In a SaaS context it should answer four things in one or two sentences: what category the product is in, who buys it, what it does, and one distinguishing fact. A model reading only the first few lines of the file should be able to describe the product correctly. If your summary would fit any competitor in the category, it is too vague.
Free-text context and H2 link sections
After the blockquote, the spec allows plain paragraphs or lists with no headings. This is where you add facts a model would otherwise get wrong: the current pricing model, supported integrations, deprecated product names, or the fact that a feature is in beta. Treat it as a short correction layer for common misreadings of your brand.
Each H2 section then groups links by job. The link format is a markdown list item with the page title as anchor text, the URL, and an optional note after a colon. That note matters more than most teams realise. A link titled Pricing tells a model little. A link titled Pricing with the note "single plan, monthly billing, free trial, cancel anytime" tells it what the page will confirm before it fetches anything.
The Optional section
An H2 named exactly Optional has a defined meaning in the spec: the links under it can be dropped when a shorter context is needed. This is the right place for changelogs, older blog posts, press pages and legal documents. Putting them in the main sections dilutes the signal. Leaving them out entirely loses pages that occasionally answer a real question.
Three Annotated llms.txt Examples for SaaS Sites
The best way to see how the sections work together is to read complete files. The three examples below are realistic patterns I would use for different SaaS situations. The company names are placeholders, and every element maps to the spec described above.
A minimal file for an early-stage product
An early-stage product usually has a homepage, a pricing page, a handful of feature pages and a small blog. The goal of the file is to state clearly what the product is and point to the pages that confirm it. Here is a minimal example that is still useful.
# Ledgerline
> Ledgerline is a revenue recognition tool for B2B SaaS finance teams. It connects to Stripe and your accounting system and automates ASC 606 schedules without spreadsheets.
Ledgerline is sold on monthly and annual plans with a free trial. It does not process payments and is not a billing system.
## Product
- [How Ledgerline works](https://ledgerline.example/product): Data flow from Stripe to the general ledger
- Integrations: Supported billing and accounting systems
- Pricing: Plans, trial terms and what each plan includes
## Guides
- ASC 606 for SaaS explained: Plain-language walkthrough of the five-step model
- [Deferred revenue schedules](https://ledgerline.example/blog/deferred-revenue): How schedules are built for annual contracts
## Optional
- [Changelog](https://ledgerline.example/changelog): Product release history
- [About](https://ledgerline.example/about): Company background and teamLine one is the H1 with the bare product name. The blockquote names the buyer (B2B SaaS finance teams), the integrations (Stripe and accounting systems) and the outcome (automated revenue schedules). The free-text paragraph that follows does something easy to miss: it states what the product is not. Category confusion is one of the most common reasons an AI assistant describes a tool incorrectly, and a single sentence of negative definition prevents it.
The Product section has three links, each with a note describing the page's content. The Guides section points to the two articles most likely to answer questions where the product belongs in the response. The changelog and about page sit under Optional because they rarely answer a buyer's question.
A documentation-heavy file for a developer tool
Developer tools are where llms.txt started, and the patterns are more mature. The original proposal was written with documentation in mind: coding assistants need to find the right API reference quickly, and HTML docs sites are expensive to parse. A docs-heavy example splits links by task, not by site navigation.
# Pipewise
> Pipewise is an open-source event streaming SDK for TypeScript and Python. It sends product events to any warehouse with typed schemas and automatic retries.
The current major version is v3. The v2 API is deprecated and its docs are listed under Optional. Install with npm or pip as shown in the quickstart.
## Getting started
- Quickstart: Install, configure and send a first event
- Authentication: API keys, scopes and key rotation
## API reference
- TypeScript client: Full method reference for the TS SDK
- [Python client](https://docs.pipewise.example/reference/python.md): Full method reference for the Python SDK
- Schemas: Defining and versioning event schemas
## Destinations
- [BigQuery](https://docs.pipewise.example/destinations/bigquery.md): Setup and permissions
- Snowflake: Setup and permissions
## Optional
- [v2 migration guide](https://docs.pipewise.example/migrate-v2.md): Moving from the deprecated v2 API
- Architecture notes: Internal design decisionsTwo details make this example stronger than a typical docs export. First, the links point to .md versions of the pages. The spec proposes that sites offer a clean markdown version of each page at the same URL with .md appended, so a model can fetch the content without the HTML wrapper. Documentation platforms increasingly generate these automatically. Second, the free-text block names the current version and flags the deprecated one. Without that line, an assistant may happily generate code against an old API because the old docs had more backlinks.
The public GitHub repository for the proposal and community directories of llms.txt files collect many live examples from developer platforms. Reading a few is worth the time. You will notice that the best ones are short, opinionated and grouped by what a developer is trying to do.
An llms-full.txt companion file
An llms-full.txt file is a different artifact with the same purpose. Instead of linking to pages, it concatenates the full markdown content of the key pages into one document. A model or an agent can then load the entire corpus in a single request. The convention grew up alongside the original proposal and is common on documentation sites.
The table below shows the practical difference: llms.txt is a map that stays small, and llms-full.txt is the territory, which grows with your content.
| Attribute | llms.txt | llms-full.txt |
|---|---|---|
| Content | Curated links with short notes | Full page text in markdown |
| Typical size | Small, readable in seconds | Large, grows with the docs |
| Best for | Navigation and positioning | Agents that need complete context |
| Maintenance | Edit when key pages change | Regenerate on every content change |
| Defined in original proposal | Yes | Community extension |
For most marketing-led SaaS sites, llms.txt alone is enough. An llms-full.txt makes sense when you have substantial documentation and expect coding assistants or support agents to work with it. If you publish one, regenerate it from source on deploy. A stale full-text file is worse than none, because it hands a model outdated facts in a format it trusts.
What Separates a Strong Example From a Weak One
A strong llms.txt example is curated, specific and current. A weak one is a sitemap pasted into markdown. The format is simple enough that almost every generator produces a valid file, so validity is not the bar. Usefulness is.
When I audit a file, these are the signs that it was generated and never edited:
- The blockquote repeats the homepage hero headline instead of stating category, buyer and function
- Every blog post on the site is listed, with no grouping and no notes
- Link titles are slugs or page titles with the brand name appended to each one
- Sections mirror the site's top navigation instead of the questions buyers ask
- Pricing, integrations and security pages are missing or buried
- Deprecated products and old pricing still appear with no warning
- The file has not changed since it was first published, while the site has
Generators are a starting point. Free llms.txt generators crawl your site and output a compliant file in seconds. That is useful for getting the structure in place. The output still needs an editor: someone who knows which five pages answer most sales questions, which feature names changed last quarter and which competitor your product gets confused with. That judgement is the part a crawler cannot supply.
Validators check syntax, not substance. An llms.txt validator confirms that the H1 exists, the blockquote is formatted correctly, links parse and the sections follow the expected order. It will not tell you that your summary is generic or that your best comparison page is missing. Run a validator to catch formatting errors, then read the file as if you were a model meeting your product for the first time.
Notes on links carry the most weight per character. A model deciding whether to fetch a page has the anchor text and the note to go on. A note such as "setup steps for Salesforce, including field mapping and sync frequency" is far more useful than "Salesforce integration". Writing good notes takes an hour for a typical SaaS site and is the highest-return edit you can make.
There is also a sizing question. The file should be short enough that a model reads all of it. In my experience a SaaS marketing site rarely needs more than a few dozen links in the main sections. If you find yourself listing hundreds, you are rebuilding your sitemap, and the curation that makes the format valuable is gone.
How llms.txt Fits Into Google SEO and AI Search Together
llms.txt does not affect Google rankings. Google has not said it uses the file as a ranking signal, and Google Search relies on its own crawling, robots.txt and sitemaps. The file's value sits on the AI side: it gives assistants and agents a clean entry point into your content when they are asked to fetch or summarise your site.
Even there, adoption by the major AI providers is uneven and largely unconfirmed. Some coding tools and agent frameworks read the file directly. General-purpose assistants mostly cite pages they find through their own retrieval systems. That is why I treat llms.txt as low-cost hygiene. If you want the longer argument about What llms.txt Actually Does for visibility, the short version is this: it helps models read you correctly once they arrive, and it does little to make them arrive.
The content the file points to decides whether you get cited. A curated list of thin pages is still a list of thin pages. The pages that earn citations in ChatGPT, Claude, Perplexity and Gemini tend to answer a specific question directly, carry structured data, cite sources and get updated as facts change. Those are also the qualities Google's helpful content guidance rewards, so the work serves both channels.
Vercel is a useful reference point for what dedicated AI optimisation can produce. 10% of Vercel's signups now come from ChatGPT as a result of its AI optimisation work. That outcome came from a broad program of documentation and content quality, and the llms.txt file was one part of it. The lesson for a smaller SaaS team is that the file matters as an index for content worth indexing.
Measuring the effect also takes a different approach from classic rank tracking. Moving From Rankings to tracking whether assistants mention your brand, and in what context, is how you tell whether your content and your llms.txt are doing their jobs. Pair that with Search Console data for Google, and you see both channels in one view.
- Publish pages that answer buyer questions directly in the first paragraph
- Add schema markup, FAQ blocks and cited sources so both Google and AI systems can parse claims
- Link related pages internally so topic clusters are visible to crawlers and models
- Refresh pages that sit just off page one using Search Console data
- List your strongest pages in llms.txt, with notes, and update the file when they change
- Track how ChatGPT and Claude describe your brand to see whether the content is landing
This is where the distinction between a tracking tool and an execution engine matters. A tracker tells you where you are invisible. Someone still has to research the topics, write the pages, link them, publish them and keep them current, and then keep the llms.txt file aligned with all of it. The comparison of Profound AI vs. Autonomous GEO approaches turns on exactly that gap between measuring and doing. For a broader look at how the tooling categories split, Your Guide to LLM visibility tools lays out the options.
Gofylo is built for the execution side. It researches keywords from your competitors and live search results, groups them into topic clusters and writes 30 articles a month in your brand voice, each in a few minutes, in 18+ languages. Every article ships with schema markup, internal links, FAQ blocks and verified source citations, and publishes directly to WordPress, Webflow, Shopify, Wix, Notion, Ghost, Framer or a custom webhook. Published articles get refreshed from your Search Console data, and the AI Visibility Score shows how ChatGPT and Claude see your brand. That gives your llms.txt file a steadily growing set of pages worth pointing to, without a content team maintaining them by hand.
Write your llms.txt file this week, then fill it with pages that earn citations. Start a 3-day free trial of Gofylo at $79/month to publish 30 AI-ready articles a month to your CMS, or run the free AI Search Grader first to see how AI assistants describe your brand right now.