Does adding facts to llms.txt stop AI assistants from getting my product wrong?

It reduces one failure mode and leaves two. An engine that fetches your llms.txt can read a correct version number, price model or category, and files like Anthropic's do exactly this by pointing at an sdk-versions.json endpoint instead of restating numbers. But the file is only read if the client chooses to fetch it, and the answer the user sees is still assembled from retrieved pages. Treat llms.txt as the correction layer, not as a guarantee.

Should I put prices directly in llms.txt?

Put the pricing model and where the current numbers live, not a price list. Prices change without a deploy, agents cache what they read, and a stale figure quoted confidently is worse than a link. Stripe applies the same logic to SDK versions: its file tells the agent to check the registry for the latest version rather than trusting a memorized number from training data.

How do I stop an AI from confusing my product with a similarly named company?

Name the confusion explicitly in the file. A short 'not to be confused with' line at the top, plus the category, the domain and the founding detail that separates you, gives the model a boundary it can carry into an answer. Negations are unusually useful here because a retriever can match them against a question that mentions the other company.

GEO · November 2026

When AI Describes Your Product Wrong

The model is not lying. It is answering from a training snapshot and whatever fragment retrieval handed it, and neither one contains your current price, your current version, or the fact that you stopped offering that plan in March. llms.txt is the one place where you can put the correction in front of it.

Why the Wrong Version of You Survives

Three mechanisms produce the same symptom. The first is the training cutoff: a model that learned about your site in 2024 keeps that shape until something newer is retrieved. The second is answer caching — a generated paragraph about your product gets reused across sessions, so an error introduced once propagates without a single fresh fetch. The third is entity collision, where a similarly named company, an old product line or a generic term absorbs your brand and the answer blends two companies into one.

None of these are fixed by writing better marketing copy, because none of them are about persuasion. They are about whether a verifiable sentence exists at the URL an agent fetches. That is the gap the file is designed to close, and it is why the first ten lines matter more than the next two hundred links.

The Five Facts That Break First

Fact	How it breaks	What the file should state
Category	An old positioning gets merged with a competitor's	The category, in the words buyers search
Pricing model	A retired tier is still recommended	Model plus a link to current numbers
Current version	An obsolete SDK gets installed, then fails	Where the latest version is published
Retired features	Agents recommend endpoints you removed	Deprecation list with the replacement
Identity	You are confused with a similarly named company	An explicit boundary line

What the Stronger Files Already Do

We fetched seven production files on November 4, 2026. All seven answered 200, and the spread in size is the point: a 3.3 KB file can carry more usable facts than a 471 KB one.

Host	Bytes	Content-Type
docs.stripe.com	97,533	`text/markdown`
docs.anthropic.com	93,865	`text/plain`
render.com	52,276	`text/markdown`
docs.github.com	28,642	`text/markdown`
vercel.com	5,397	`text/plain`
supabase.com	3,298	`text/plain`
posthog.com	482,837	`text/plain`

Three of them use the opening lines for exactly this job rather than for a table of contents:

Stripe spends its first paragraph on version discipline: never hardcode a version from training data, check the registry first. It is a fact about the world that the model cannot otherwise know.
Anthropic publishes an SDK versions section that points at a JSON endpoint instead of restating numbers, so the file cannot go stale on its own.
Render routes the agent before listing anything: read this file and treat it as a procedure, not as reference documentation.
Vercel opens with a When to use Vercel section — five bullets that define the product's job, which is the cheapest form of category correction there is.

The pattern is worth copying: facts first, index second. If your file opens with two hundred links and no sentence about what the thing is, an agent has to infer your category from URL slugs.

A Product-Facts Block You Can Paste

Six to ten lines, before the first H2 section, written as facts rather than positioning:

# Northwind

> Northwind is a warehouse-management API for mid-market retailers in the US and EU.
> It covers inventory sync, order routing and carrier label printing — not storefronts
> and not accounting. API access is on every paid plan; there is no free tier.

- Current API version: 2026-09-01 (changelog: https://example.com/api/changelog.md)
- Pricing model: per-warehouse seats plus per-label fees; current prices only at https://example.com/pricing
- Retired: the /v1/shipments endpoint was removed in June 2026; use /v2/shipments
- Not to be confused with Northwind Traders (retail grocery, unrelated company)

Every line there is checkable, and each one kills a specific error: the category line stops the merge with a storefront tool, the version line stops an old SDK install, the retired line stops a dead endpoint, the negation stops the name collision. The writing conventions behind these lines are the same ones covered in llms.txt descriptions, applied to facts instead of page summaries.

Negative Facts Are the Highest-Value Lines

Marketing teams resist writing what the product does not do, but negations are the most retrievable sentences in the file. A question like "does Northwind include accounting?" matches the phrase not accounting directly; nothing in a features page matches it half as well. The same logic covers deprecations: the line stating that an endpoint was removed in June 2026 answers a question that support tickets still generate months later.

Keep the negatives short and absolute — no hedging, no "currently", no "at this time". A soft negative reads to a model like a maybe, and a maybe gets resolved in the direction the user was already leaning. Render and Stripe both take this approach with routing and version instructions; the general shape of an instruction that survives is covered in llms.txt instructions for AI agents.

Where the File Stops Helping

Three limits worth knowing before you rewrite everything. The client has to fetch the file: none of the major assistants inject it automatically, and coverage still varies by engine — the crawl evidence is in which AI engines read llms.txt. Retrieval still chooses the page: if the fact lives only in llms.txt and no page repeats it, the answer may never see it. And a fact that contradicts your own site is worse than silence, because the model now has two candidate answers and the older one often wins.

So the file is a correction layer on top of pages that must agree with it. State the fact in llms.txt, repeat it on the pricing page and in the changelog, then keep the three in sync — the drift problem is the same one covered in llms.txt maintenance.

A Ten-Minute Fact Audit

Ask an assistant what your product costs, what version is current, and what it does not do. Save the answers.
Mark each wrong claim and find the page that should have corrected it. If no page contains the fact, that is the real bug.
Write the six-line facts block at the top of your file, using the template above.
Check every URL in it still answers 200 with text — a dead changelog link defeats the point.
Run the file through the llms.txt checker to confirm the structure still parses, then repeat step 1 in a month.

If the file does not exist yet, the llms.txt generator will build the index from your sitemap in a minute — spend the time you saved on the facts block, because that is the part an agent quotes.