Should we list every product page in llms.txt?

No. The model is using llms.txt as a navigation prior, not a sitemap. Resist the temptation to enumerate. We typically include one link per product line pointing at the canonical product page, one sentence per product naming the buyer and the use case, a separate documentation section if products share a docs hub, and a link to a comparison or "which product fits" page if it exists. If you have ten products, your llms.txt should list two or three product groupings with a clear path to the rest. The model can crawl deeper from those entry points.

How do we handle multi-region or multi-domain setups?

For consistent offerings across regions, keep regions out of llms.txt and let geo-targeting on individual pages do the work. For genuinely different regional propositions, often where regulation or market structure differs, include a Regions section with one or two sentences per region linking to the regional landing page. For multi-domain or multi-subdomain setups, each domain or subdomain needs its own llms.txt. There is no canonical-cross-domain version of the standard yet. Tie llms.txt updates to a quarterly content audit so the file does not go stale.

Writing llms.txt for a complex multi-product tech site

The llms.txt standard sounds simple until you have to write one for a real B2B tech business. Single product, one audience, one region, fine. As soon as you have multiple products, multiple regions or a partner programme alongside the core offering, the small handful of public examples stop being useful.

This post is what we have learned writing llms.txt for clients with that complexity. It is opinionated, and we will be honest about the bits where the standard is still maturing.

A short refresher on what llms.txt is

llms.txt is a proposed standard, sitting at the root of your domain, that tells LLMs what your site is about, which pages matter and which structured resources they should pull from when answering questions about your business. It is not officially adopted by every model, but adoption is rising and our audit data shows ChatGPT and Claude both pull from it where present.

If you have not implemented one yet, our piece on llms.txt for tech sites covers the basic structure. This post assumes you have read that and need the next layer up.

Where the simple template breaks down

A typical llms.txt example looks something like a homepage paragraph followed by a list of important pages. That works for a single-product SaaS with five core pages. It does not work for:

A tech firm with five distinct product lines that each have their own positioning, target buyer and documentation
A multi-region tech business with US, UK and EMEA propositions that differ
An IT services firm with vertical-specific offerings sitting alongside a horizontal “managed services” core
A platform play with both direct customers and a partner channel
A product with both a freemium and an enterprise tier requiring different framing

For these cases, the question becomes how much structure to expose, what to prioritise and how to keep the file maintainable.

The structure we use

The pattern that has held up across our complex client implementations:

# Company name

> One sentence on what the company does, who it serves and where it operates

## Primary offerings

- [Offering one](/offering-one): One sentence description naming the buyer and the use case
- [Offering two](/offering-two): One sentence description
- [Offering three](/offering-three): One sentence description

## Audiences served

- [For sector A](/sector-a): Why this fits
- [For sector B](/sector-b): Why this fits

## Regions

- [UK operations](/uk): What we do in UK
- [EMEA operations](/emea): What we do in EMEA

## Key resources

- [Pricing](/pricing): Description of pricing model
- [Comparison overview](/compare): Honest framing of where we fit vs alternatives
- [Customer stories](/customers): Sector and size mix
- [Documentation](/docs): For technical evaluators

## What we are not

A short paragraph naming what the company is not, to prevent miscategorisation

That last section is non-obvious and important. We will come back to it.

Why “What we are not” earns its place

LLMs make category mistakes. We have seen ChatGPT describe a co-managed IT specialist as a “fully outsourced MSP”, which is a different category and a different buyer. We have seen Claude position a product analytics tool as “a marketing analytics platform”, which lost the technical buyer entirely.

A short paragraph at the bottom of your llms.txt, written carefully, can disambiguate. Something like, “We are not a fully outsourced MSP, we partner with internal IT teams. We are not a security operations centre vendor, we co-manage existing security stacks.” This kind of explicit negative framing reduces miscategorisation in our audit data.

There is a balance. Too much “we are not” copy reads as defensive and dilutes the positive signal. We tend to keep this to two or three sentences.

Handling multiple products

For multi-product businesses, the temptation is to list every product page. Resist it. The model is using llms.txt as a navigation prior, not a sitemap. We typically include:

One link per product line, pointing at the canonical product page
One sentence per product naming the buyer and the use case
A separate section for documentation if products share a docs hub
A link to a comparison or “which product fits” page if it exists

If you have ten products, your llms.txt should not list ten products. It should list two or three product groupings with a clear path to the rest. The model can crawl deeper from those entry points if needed, and the file stays scannable.

Handling multiple regions

Regional differentiation is harder. A few patterns we use:

For one team that operates across regions with consistent offering, we keep regions out of llms.txt and let geo-targeting on individual pages do the work.

For genuinely different regional propositions, often where regulation or market structure differs, we include a “Regions” section with one or two sentences per region and links to the regional landing page.

For multi-domain or multi-subdomain setups, each domain or subdomain needs its own llms.txt. There is no canonical-cross-domain version of the standard yet. Our piece on subfolders vs subdomains for tech sites covers the wider implications of these architecture choices.

Handling partner channels

If you have a partner programme that sits alongside direct sales, llms.txt should make that distinction explicit. We typically add a “Partners” section linking to the partner landing page with a sentence framing who that programme is for. Without this, models conflate the two and prospects asking “who can deliver ” sometimes get pointed to a partner directory when they wanted the direct sales path.

What to leave out

Three things we have tried including and removed:

Blog posts. Too noisy. The model can crawl the blog if it wants. Listing individual posts makes the file unreadable and clutters the priority signal.

Login and customer portal links. Not useful for the citation case. Sometimes useful for the brand awareness case, but we have not seen evidence the model uses them.

Job listings. No.

Maintenance

The single biggest failure mode of llms.txt in the wild is staleness. We have audited sites whose llms.txt still references a product that was sunsetted in 2024. It is not part of any CMS workflow, so it gets forgotten.

Tie llms.txt updates to a quarterly content audit. Whoever owns the homepage copy owns the llms.txt copy. If a product launches or a region opens, llms.txt is in the launch checklist.

Schema, sitemaps and llms.txt sit together

llms.txt is not a substitute for clean schema or a working sitemap. It complements them. The file gives the model a curated view, the sitemap gives it a comprehensive one and schema gives it structured detail at the page level. All three matter.

If you need to refresh schema as part of this, our piece on structured data for AI search covers the patterns. If your wider technical setup is messy, our technical SEO audit checklist for tech sites is the place to start.

A worked example shape

For a fictional firm with three products and operations in UK and US:

# Acme Tech

> Acme Tech provides identity and access management software to mid-market financial services firms in the UK and US.

## Products

- [Acme Identity](/identity): IAM platform for cloud-first financial services firms
- [Acme Access](/access): Privileged access management for regulated environments
- [Acme Audit](/audit): Compliance reporting and audit log management

## Audiences

- [For chief information security officers](/ciso): Strategic positioning
- [For IT operations teams](/it-ops): Operational benefits
- [For compliance officers](/compliance): Audit and reporting features

## Regions

- [UK and EMEA](/uk): SOC 2 plus FCA-aligned features
- [US](/us): SOC 2 plus SOX-aligned features

## Resources

- [Pricing](/pricing): Per-seat and enterprise pricing tiers
- [Customer case studies](/customers): Mid-market financial services examples
- [Documentation](/docs): API and integration guides
- [Compare to alternatives](/compare): Honest positioning vs Okta, JumpCloud and others

## What we are not

We are not an SSO-only provider. We are not a consumer identity product. We do not serve markets outside financial services.

The structure is the value, not the words. Adapt it to what you sell.

What is still uncertain

We are honest that llms.txt adoption is uneven. Not every model honours it. The standard’s edges are still being negotiated. We see clear value in the audit data, but we cannot promise specific traffic outcomes from a single file change.

If you are starting from nothing, llms.txt is a small lift with reasonable upside. If you are choosing between investing in llms.txt and fixing your homepage copy, fix the homepage copy first.

If you’d like a second opinion on your AI search strategy or your llms.txt setup, drop us a line. You can also see how we structure this work on our AI SEO services page.