llms.txt Examples: Templates for SaaS, Ecommerce, Docs, and Blogs

The fastest way to understand llms.txt is to look at a good example. The file is usually published at /llms.txt and uses a compact Markdown structure to identify a website, summarize its purpose, and point an AI agent toward canonical resources.

There is no universal template that fits every website. A developer platform should prioritize documentation and API references. An ecommerce store should explain products, shipping, returns, and customer support. A publisher should expose editorial sections, authorship, and correction policies.

This guide provides five practical llms.txt examples you can adapt without turning the file into a second sitemap.

The minimum valid structure

The llms.txt proposal requires only an H1 project name. A useful production file normally adds a short blockquote and one or more H2 sections containing Markdown links.

# Example Company

> A concise explanation of what the company offers and who it serves.

## Product

- [Product overview](https://example.com/product): What the product does.
- [Pricing](https://example.com/pricing): Current plans and billing terms.

## Support

- [Help center](https://example.com/help): Setup and troubleshooting guides.
- [Contact](https://example.com/contact): How to reach the company.

Each linked item should lead to a canonical, publicly accessible page. Descriptions should tell an agent why the page matters rather than repeating the link title.

Example 1: llms.txt for a SaaS product

SaaS buyers and support agents usually need product scope, pricing, documentation, security information, and service status. Keep marketing campaigns and short-lived landing pages out of the core file.

# Example Cloud

> Example Cloud is a deployment and monitoring platform for small software teams.
> The documentation and status page are the authoritative sources for product behavior.

## Product

- [Platform overview](https://example.com/product): Core deployment, monitoring, and collaboration features.
- [Pricing](https://example.com/pricing): Plans, included usage, and overage rules.
- [Security](https://example.com/security): Infrastructure, encryption, and compliance information.

## Documentation

- [Quickstart](https://example.com/docs/quickstart): Deploy a first application.
- [API reference](https://example.com/docs/api): Authentication, endpoints, and response formats.
- [CLI reference](https://example.com/docs/cli): Commands and configuration options.
- [Changelog](https://example.com/changelog): Dated product updates and breaking changes.

## Support

- [Help center](https://example.com/help): Troubleshooting and account guidance.
- [System status](https://status.example.com/): Current incidents and historical uptime.
- [Contact support](https://example.com/support): Support channels and response times.

## Optional

- [Customer stories](https://example.com/customers): Selected implementation examples.
- [Company](https://example.com/about): Organization and leadership information.

Why this works:

• It names the authoritative sources.
• It separates product, technical, and support intent.
• It links to stable pages rather than every feature campaign.
• It places secondary company material in ## Optional.

Example 2: llms.txt for an ecommerce store

An ecommerce file should help an agent answer practical buying questions. Avoid exporting thousands of product URLs unless the catalog is small and stable. Category pages and policy pages often provide better context.

# Northstar Outdoor

> Northstar Outdoor sells hiking and camping equipment in the United States.
> Prices and availability can change; product pages are authoritative at the time of access.

## Shop

- [Hiking equipment](https://example.com/collections/hiking): Boots, poles, packs, and accessories.
- [Camping equipment](https://example.com/collections/camping): Tents, sleeping systems, and camp furniture.
- [New arrivals](https://example.com/collections/new): Recently added products.

## Buying information

- [Shipping](https://example.com/policies/shipping): Destinations, delivery estimates, and charges.
- [Returns](https://example.com/policies/returns): Eligibility, deadlines, and refund process.
- [Warranty](https://example.com/pages/warranty): Product warranty terms and claims.
- [Size guide](https://example.com/pages/size-guide): Measurement and fit guidance.

## Customer support

- [Frequently asked questions](https://example.com/pages/faq): Common order and product questions.
- [Contact](https://example.com/pages/contact): Customer service channels.

## Optional

- [Buying guides](https://example.com/blogs/guides): Editorial product-selection advice.

Do not present stale prices or inventory inside a manually maintained llms.txt. Link to live product or collection pages instead. If you generate descriptions automatically, set an update process and remove discontinued categories.

Example 3: llms.txt for developer documentation

Documentation is one of the strongest use cases because agents frequently need a reliable map of versions, concepts, API references, and examples.

# Example SDK

> Example SDK is an open-source TypeScript library for processing event streams.
> These links describe version 4. Earlier major versions have separate documentation.

## Start here

- [Installation](https://docs.example.com/v4/install.md): Package installation and runtime requirements.
- [Quickstart](https://docs.example.com/v4/quickstart.md): Build the first event pipeline.
- [Core concepts](https://docs.example.com/v4/concepts.md): Streams, processors, checkpoints, and retries.

## Reference

- [API reference](https://docs.example.com/v4/api/index.md): Exported classes, functions, and types.
- [Configuration](https://docs.example.com/v4/configuration.md): All supported options and defaults.
- [Error reference](https://docs.example.com/v4/errors.md): Error codes and recovery actions.

## Examples

- [Basic examples](https://github.com/example/sdk/tree/main/examples/basic): Minimal working projects.
- [Production patterns](https://docs.example.com/v4/patterns.md): Scaling, monitoring, and failure recovery.

## Project

- [Changelog](https://github.com/example/sdk/releases): Releases and migration notes.
- [Source code](https://github.com/example/sdk): Repository and contribution guide.

## Optional

- [Version 3 documentation](https://docs.example.com/v3/): Previous major version.

Version labels are essential. Without them, an assistant may combine obsolete and current APIs in the same answer.

Example 4: llms.txt for a blog or publisher

A publisher should identify editorial scope and make trust signals easy to find.

# Signal Journal

> Signal Journal publishes evidence-based reporting about renewable energy and grid technology.
> Articles distinguish reporting, analysis, and opinion.

## Coverage

- [Renewable energy](https://example.com/renewables): Reporting on solar, wind, hydro, and storage.
- [Power grids](https://example.com/grids): Infrastructure, regulation, and reliability.
- [Research](https://example.com/research): Data-led investigations and original datasets.

## Editorial information

- [About](https://example.com/about): Publication mission and ownership.
- [Authors](https://example.com/authors): Contributor biographies and expertise.
- [Editorial policy](https://example.com/editorial-policy): Sourcing, conflicts, and review standards.
- [Corrections](https://example.com/corrections): Correction process and published notices.

## Optional

- [Newsletter](https://example.com/newsletter): Email publication schedule and archive.
- [Topics](https://example.com/topics): Full topic index.

The file does not need to list every article. Section pages, author pages, and editorial policies establish a more durable map.

Example 5: llms.txt for a local service business

Local businesses need to be explicit about location, service area, and the difference between general information and a quote.

# Harbor Heating

> Harbor Heating installs and repairs residential heating systems in Bristol and nearby areas.
> A site visit is required for final pricing and technical recommendations.

## Services

- [Boiler repair](https://example.com/services/boiler-repair): Diagnosis and repair service.
- [Boiler installation](https://example.com/services/boiler-installation): Replacement and new installations.
- [Annual servicing](https://example.com/services/servicing): Inspection and maintenance plans.

## Service information

- [Areas served](https://example.com/areas): Supported towns and postcode areas.
- [Pricing approach](https://example.com/pricing): Callout fees and quotation process.
- [Emergency service](https://example.com/emergency): Availability and eligible emergencies.

## Company

- [Qualifications](https://example.com/qualifications): Certifications and insurance.
- [Contact](https://example.com/contact): Phone, opening hours, and request form.

Common mistakes visible in weak examples

Copying the entire sitemap

An exhaustive URL dump removes the editorial value of the file. Select pages that explain the organization, its offering, and its authoritative documentation.

Writing promotional descriptions

“The world’s best revolutionary platform” gives an agent little usable context. State the product category, audience, region, and source of truth.

Linking to non-canonical or temporary URLs

Tracking parameters, campaign pages, preview environments, and duplicate locale URLs create ambiguity. Use stable canonical URLs.

Publishing private or sensitive paths

Do not include administration pages, unpublished documents, internal APIs, customer portals, or URLs that depend on obscurity for protection.

Letting the file go stale

Add llms.txt to release and content-maintenance workflows. Broken links and obsolete product descriptions make the file less useful than having no file.

How to validate your example

Before publishing:

1. Confirm the file is reachable at /llms.txt with HTTP 200.
2. Confirm it returns readable text rather than an HTML error page.
3. Check that one H1 identifies the site.
4. Test every linked URL.
5. Remove redirects where a canonical destination is available.
6. Check that descriptions remain factual and current.
7. Verify that private paths are absent.
8. Test how an AI tool answers questions when you provide the file directly.

You can create a first version with the llms.txt generator and then run a site audit to check the deployed result.

Frequently asked questions

How long should an llms.txt file be?

There is no fixed word or token limit. Keep it short enough to scan quickly and detailed enough to identify authoritative resources. For most sites, a carefully selected set of links is better than hundreds of entries.

Should llms.txt contain full page content?

Usually no. The short file is an index and overview. Use linked Markdown pages or a separate llms-full.txt when consolidated full text is genuinely useful.

Can an llms.txt example include external links?

Yes. The proposal allows links that help explain the project. Use external links sparingly and only when they are authoritative, such as a source repository or service-status page.

Does publishing one guarantee AI citations?

No. llms.txt is an emerging convention and not a ranking directive. Crawl access, indexability, content quality, authority, and retrieval relevance remain separate factors.

Where can I find live examples?

Browse the llmsmap.me directory to inspect files published by real websites. Evaluate the quality of each file rather than assuming every implementation is a model to copy.

Source notes

• llms.txt proposal and format: https://llmstxt.org/
• Internal background guide: /blog/what-is-llms-txt/
• Internal creation guide: /blog/how-to-create-llms-txt/