llms.txt for Brands: What to Publish, What to Skip, and How Models Use It

llms.txt is a root-level markdown file that tells language-model systems who you are, what you do, and which pages on your site settle which questions. Done right, it is a briefing. Done wrong, it is a second sitemap that changes nothing about whether ChatGPT or Perplexity can describe your brand accurately.

This spoke sits under the Answer Engine Optimization playbook. Use it when you are ready to ship or rewrite the file as part of your on-site truth layer.

What llms.txt is (and is not)

The emerging convention is simple: publish /llms.txt (and optionally /llms-full.txt) in plain markdown so crawlers and tooling can fetch a compact, human-authored summary of the site. It is voluntary. There is no guarantee every model reads every file on every request. Treat it as a high-signal packet for systems that do fetch it — and as a forcing function for your own clarity even when they do not.

It is not:

• A ranking hack or a paid inclusion channel
• A replacement for indexable HTML pages
• A place to paste your entire blog archive
• A robots.txt alternative for blocking training (use robots and published policies for that)

If your only AEO move is uploading a thin llms.txt, you will be disappointed. If you use it to encode the same facts you want models to repeat, it earns its keep.

The briefing structure that works for brands

Write for a tired analyst who has 30 seconds. Lead with identity, then offers, then proof URLs.

Recommended sections

1. Title + one-line positioning — legal or primary trade name, what you sell, for whom
2. Blockquote summary — 2–4 lines: ICP, geography, founding/credentials if they matter
3. What we do — linked services or products with one factual clause each
4. Who we are — company + key people pages when people are part of trust
5. Proof / resources — case studies, method pages, pricing/packages, FAQ
6. Contact / commercial — how to engage (audit, call, demo) with a single URL
7. Optional: exclusions — who you are not for (reduces wrong-fit recommendations)

Example skeleton

# Northline Field Services
> Commercial HVAC maintenance and retrofit for multi-site retailers
> across the Southeast. Founded 2009. EPA Section 608 certified techs.

## What we do
- [Planned maintenance](https://example.com/services/maintenance): quarterly
  PM for rooftop units; SLA-backed response windows.
- [Heat pump retrofit](https://example.com/services/retrofit): store-level
  electrification projects with M&V reporting.

## Who we are
- [About Northline](https://example.com/about): leadership, licensing, service area.
- [Safety & compliance](https://example.com/compliance): certifications and COIs.

## Start here
- [Request a site audit](https://example.com/contact): multi-location assessment.

Notice what is missing: a dump of /blog/page/2, marketing adjectives, and duplicate nav labels with no facts attached.

What to publish

Include facts a model should be allowed to repeat without inventing:

• Canonical brand name and any public “also known as”
• Primary offers with plain-language scope
• Service area or ICP boundaries
• Links to pages that expand each claim
• Notable, verifiable credentials (certifications, years, named partnerships)
• Preferred commercial entry point

Keep each bullet one idea. Link the URL that settles the claim. If the claim is not on the destination page, either add it there or delete the bullet.

What to skip

• Every blog URL from the last five years
• Login, cart, and utility routes
• Thin tag archives and parameter URLs
• Superlatives with no proof (“leading,” “best-in-class”)
• Pricing you are unwilling to stand behind in a chat answer
• Internal codenames and unreleased products
• Competitor attack lines (models will still find comparisons; keep your file factual)

Also skip contradictory drafts. If LinkedIn says founded 2019 and the site says 2017, fix the sources before encoding either year in llms.txt.

How models and tooling use the file

In practice you will see three behaviors:

1. Direct fetch — some agents and research tools request /llms.txt when exploring a domain
2. Indirect use — the same content appears in HTML pages that retrieval already prefers; the file keeps your team honest
3. No use — some sessions never fetch it; your HTML truth layer still has to be strong

So the ROI is dual: better machine briefing when fetched, and a canonical outline that improves About/Services copy when you align them.

Pair llms.txt with Organization JSON-LD and clean canonical pages. The file is one layer of the stack in the AEO playbook, not the whole stack. For schema specifics, see Schema Markup for Answer Engines.

Implementation checklist

1. Inventory the 10 URLs that should settle buyer questions.
2. Draft the briefing offline; read it aloud — if it sounds like nav labels, rewrite.
3. Align founding year, HQ, and offer names with About and schema.
4. Publish at https://yourdomain.com/llms.txt with text/plain or markdown, crawlable, no auth.
5. Link it from a humans-facing page if you want transparency (footer or AI/info page).
6. Optional: maintain llms-full.txt for longer documentation; keep the root file short.
7. Re-test brand prompts in ChatGPT and Perplexity after publish; log whether descriptions tighten.
8. Revisit monthly or on every pricing/offer change.

Governance tips for teams

Assign one owner (usually marketing ops or the founder on smaller teams). Sales and PR do not freestyle alternate origin stories. When you launch a new offer, update the HTML page first, then llms.txt, then any PR boilerplate. That order prevents the file from advertising a page that still says the old thing.

Multi-brand companies: one file per registrable domain, or clear sections that never mix entity IDs. Do not stuff five unrelated businesses into one briefing.

Field examples: weak vs strong bullets

Weak: - [Services](/services): Everything you need to grow
Strong: - [Outbound sequencing](/services/outbound): Human-approved AI sequences for B2B teams with 5–50 SDRs; HubSpot and Salesforce.

Weak: - [Blog](/blog): Insights
Strong: - [AEO playbook](/blog/answer-engine-optimization-playbook): Full method for AI citations; start here for visibility work.

Weak: - Founded by innovators in 2015ish
Strong: - Founded 2015 in Charleston, SC. Not affiliated with Acme Robotics (Delaware).

The strong versions survive compression. The weak ones become hallucinated mush.

Multi-brand and multi-language notes

If you operate several brands on one domain (unusual but real), separate sections with explicit brand headings and never reuse the same product names across brands without labels. Prefer brand subdomains or distinct domains when the entities are truly separate.

For multilingual sites, either:

• Publish language-specific briefings (/en/llms.txt patterns only if your stack already localizes that way and you document the convention), or
• Keep one English canonical briefing that points to localized HTML answer pages

Do not machine-translate the briefing into five languages and leave conflicting founding years in each. Pick a source language for facts.

Maintenance calendar

Trigger	Action
Pricing change	Update linked package page first, then briefing bullet
New service line	Add bullet + deep link; remove if beta and not public
Office move	HQ line + About + schema same day
Executive hire used in sales	Add Person link only if a public bio exists
Quarterly	Read the whole file aloud; cut anything stale

Put the file in the same repo as the site when possible so it ships with deploys. Orphan docs in Notion drift.

How this pairs with robots.txt and training policies

robots.txt governs crawler access. Published terms and meta rules govern training preferences where honored. llms.txt governs clarity for systems that ask for a summary. Use all three deliberately:

• Block paths you never want retrieved (staging, internal search)
• State training preferences in the channels your counsel approves
• Keep llms.txt focused on public commercial truth

Do not try to hide public marketing pages in llms.txt while advertising them on LinkedIn. The open web still exists.

QA before you call it done

1. Fetch production URL with curl -I — 200, not behind auth.
2. Paste the file into a blank chat and ask: “Summarize this company in three sentences.” If the summary invents scope, your briefing is vague.
3. Click every link. Dead links teach machines to ignore you.
4. Diff against Organization schema names.
5. Run three brand prompts and note whether descriptions tighten over the next two weeks.

Operator workshop: draft your file in 45 minutes

Block a calendar slot with the founder (or whoever can bind facts) and a marketer who knows the URL map. Whiteboard only four columns: Claim, Evidence URL, Owner, Public?. Fill ten rows max. Anything without an evidence URL dies. Anything not public dies. Rewrite the survivors into markdown bullets with links.

Then do a hostile edit pass: delete every adjective that does not change a decision. “Trusted,” “innovative,” and “full-service” almost never survive. Numbers, certifications, ICP boundaries, and geography do.

Finally, paste the draft into a blank model chat and ask three prompts: (1) What does this company sell? (2) Who should not hire them? (3) Which URL should I read first? If the model invents a fourth product line, your briefing leaked ambiguity. Fix the markdown before it ever hits production.

Ship behind a PR that also updates About and Organization schema in the same merge. Split deploys are how llms.txt becomes the only accurate document on the site — which sounds good until HTML retrieval ignores it and quotes the stale About page instead.

Common objections from stakeholders

“Nobody reads plain text files.” Humans might not. Tooling and agents do — and the drafting exercise improves human pages regardless.

“We will wait for an official standard.” Waiting is a decision to stay ambiguous. The briefing pattern is useful even if filenames evolve.

“Our lawyers want the file empty.” Empty is fine if counsel blocks public claims; then invest in HTML pages they will approve. Do not publish a teasing file full of hedges that teach nothing.

“We already have a sitemap.” Sitemaps list URLs. Briefings state truths. Different jobs.

Versioning and changelog

Keep llms.txt in git. On material edits, add an HTML changelog page or a short “Last reviewed” line at the bottom of the file with an ISO date. Models do not require the date, but your team does. When someone asks why ChatGPT still mentions a beta product, you can prove when the bullet was removed and whether the HTML page lagged.

FAQ

What is llms.txt?

It is a voluntary markdown file at the root of a website that summarizes the organization, offers, and key URLs for language-model systems and related tooling. Think briefing document, not sitemap clone.

How do I write llms.txt for a business?

State who you are, who you serve, what you offer, and link to the pages that prove each point. Keep it short, factual, and consistent with your About page and schema. Skip blog dumps and hype adjectives.

Does every AI model read llms.txt?

No. Support varies by product and session. Publish it anyway as part of a broader AEO truth layer, and make sure the same facts exist in HTML.

Should llms.txt block AI training?

That is not its job. Use robots.txt, meta rules, and your published terms/policies for crawler control. Use llms.txt to clarify facts for systems that request a summary.

How long should the file be?

Long enough to disambiguate the brand and point to answer pages — often 40–120 lines for a focused company. If you need a manual, use llms-full.txt or documentation URLs.

Can llms.txt fix hallucinated brand facts alone?

Rarely alone. It helps when retrieval finds it, but you still need consistent HTML, schema, and off-site corroboration. See Avoiding Hallucinated Brand Facts.

Closing

Ship a briefing, not a URL landfill. When llms.txt matches your schema and canonical pages, you give answer engines fewer reasons to invent you.

For the full system — entities, content clusters, citation measurement — read the AEO playbook. To have Spurlock Studios baseline your file and the rest of the truth layer, start at /visibility or book a visibility audit.