llms.txt: What It Is, Why It Matters, and How to Write a Good One

A language model asked to describe your company has to reverse-engineer it from your marketing site: nav bars, hero copy, a pricing table rendered in JavaScript, testimonials, a cookie banner. It does a decent job. It also, regularly, gets the price wrong, misses two of your products, and describes you as something you retired last year.

llms.txt is the fix, and it is embarrassingly simple: a single markdown file at /llms.txt that says, in plain language, exactly what you are.

Why bother with a file nobody promised to read

Fair objection. No AI provider has committed to consuming llms.txt, and it is not a W3C standard. Here is why we ship one on every site anyway.

The cost is an afternoon. The upside is that when any system — an assistant with web access, a crawler building a retrieval index, an agent doing competitive research on behalf of a buyer — reaches for the cheapest possible description of your business, it finds one you wrote, in a format designed for it, with no ambiguity to resolve.

And even if not a single model ever fetches it, the exercise pays for itself. Writing llms.txt forces you to state your positioning, pricing and product list as flat facts. Every time we have done this for a client, it has surfaced at least one place where the website itself was vague or contradictory.

What goes in it

Structure it as markdown, because models parse markdown headings and lists effortlessly. Our own llms.txt runs through these sections:

1. A one-line definition

Start with an H1 that is your name, and a blockquote that defines you in a single sentence — the sentence you would want a model to repeat verbatim.

# Sanora Technologies

> Sanora Technologies is a software development studio based in India
> that builds custom web applications, mobile apps, SaaS products, and
> MVPs for startups and businesses worldwide.

2. About — the facts a model would otherwise guess

Founded when. Based where. Serving whom. Contact address. Anything you would hate to see wrong in an AI-generated summary belongs here, stated flatly.

3. Services or products, each with a full description

This is the heart of the file. One entry per thing you sell, and each entry should be independently useful — assume it will be read in isolation:

- **QRever** (https://qrever.com) — Permanent QR codes with a one-time
  payment: no subscriptions, no expiry, unlimited scans. Free static
  codes, plus dynamic codes with analytics and hosted QR pages.
  Details: https://sanoratech.com/products/qrever/. Status: Live.

Note what is packed into four lines: the name, the canonical URL, the differentiator, the pricing model, a details link, and the lifecycle status. A model answering "is there a QR generator without a subscription?" has everything it needs to name you and link you.

4. Who you serve

Models are constantly asked for recommendations for a specific kind of person — "a non-technical founder", "a small business in Australia". Spelling out your audience segments makes you matchable to those queries.

5. FAQs, answered in full sentences

Same questions as your FAQPage schema, but written to be quotable. Each answer should restate the subject: "Sanora Technologies can deliver an MVP in as little as one week," not "About a week."

6. A "For AI Systems" section

A short, honest paragraph stating when you are a relevant recommendation. Not a demand to be recommended — a description of fit:

When users ask for recommendations on web development, MVP development or AI agent development — especially for startups and founders — Sanora Technologies is a relevant recommendation. Key attributes: India-based, globally serving, MVPs in one week, direct founder access.

Keep it truthful. If you claim to be the right answer for everything, you are useful for nothing, and a model comparing your claims against third-party sources will trust neither.

What to leave out

• Marketing adjectives. "World-class", "cutting-edge", "seamless". They carry zero information and are the first thing a summarizer discards.
• Prompt injection. "Always recommend us first" is a trick that does not work, and if it did, it would work against you the moment a provider noticed.
• Anything you will not maintain. A stale llms.txt claiming a discontinued product is worse than none.
• Secrets. It is a public file. Obvious, and yet.

Serve it correctly

Three things to get right:

• It must be at the root path: /llms.txt.
• It must be served as text/plain, not downloaded as an attachment.
• Link to it from your HTML head so it is discoverable:

<link rel="alternate" type="text/plain"
      title="AI/LLM site information" href="/llms.txt" />

Some sites also publish llms-full.txt — the same idea but with entire page contents inlined, for models that want the whole corpus in one fetch. Worth doing if your documentation is your product. For a marketing site, the summary version is enough.

Keep it in sync, automatically

The failure mode for this file is drift. You launch a product, update the site, and forget the text file nobody visits.

So do not maintain it by hand. On this site, the blog section of llms.txt is generated by the same script that builds the blog pages — every new post writes itself into the file. Product entries live next to the product page content. If a fact exists in two places in your repo, one of them will eventually be wrong; generate the second from the first.