llms.txt for e-commerce stores: what it is and whether you need one

AI assistants increasingly summarize stores and recommend products. llms.txt is a proposed way to hand them a clean map of your site. Here's what it actually does, what it doesn't, and whether a store should bother.

What is llms.txt?

llms.txt is a markdown file at the root of your domain (yourstore.com/llms.txt) that gives LLMs a structured, human-readable map of your site: what you sell, where the important pages are, what your policies say. It's a proposed standard, not an official one — think of it as robots.txt's younger sibling that describes instead of restricts.

There's also a llms-full.txt variant, which inlines the full content of your key pages rather than just linking to them, for systems that prefer to ingest everything in one fetch.

The pitch is simple: an assistant answering "does this store ship to Canada and what's their return window?" can either parse your JavaScript-heavy theme and hope, or read a markdown file that answers directly.

What is llms.txt not?

It is not access control, and it is not a rankings hack.

If you want to allow or block AI crawlers, that's robots.txt — with user-agent directives for GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, and friends. llms.txt has no say in who crawls you; it only helps whoever you've already let in understand what they're looking at.

And it doesn't buy placement. No AI vendor has promised that publishing one earns citations or recommendations. Anyone selling "llms.txt optimization" as guaranteed AI visibility is selling something else.

Why should a store care?

Because assistants recommend what they can parse, and most e-commerce themes are hostile to parsing. Product data buried in hydrated JavaScript, policies hidden in accordion footers, sizing charts as images — a human navigates all of that; a model fetching your page in one pass often can't. When an assistant compares you against a competitor whose store is legible, being parseable beats being pretty.

AI-referred traffic is still a small share for most stores, but it's the fastest-growing referral class — and unlike SEO, the surface area is cheap to cover early. (If you want to see whether that traffic is already buying from you, we covered measuring ChatGPT-referred purchases separately.)

What should a store's llms.txt include?

Keep it short and factual — a map, not a brochure:

• Who you are, in one line. What you sell and to whom.
• Product categories with links to the canonical collection pages.
• Shipping and returns policy — destinations, timelines, return window, who pays return shipping. This is what assistants get asked about most.
• Sizing and fit info, or a link to a text-readable size guide (not an image).
• Support contact and hours.
• Links to your bestseller or flagship product pages.

Skip marketing copy. A model quoting your llms.txt to a shopper should sound accurate, not promotional.

Does it replace structured data?

No — they complement each other. JSON-LD Product and Offer markup gives machines per-page facts: price, availability, ratings, variants, in a format both search engines and AI crawlers already consume. llms.txt gives them the site-level context JSON-LD can't: how the catalog is organized, what your policies are, where to look first. A store that has both is legible at every zoom level. If you only have time for one, ship the JSON-LD first — it has broader, proven consumption today.

So do you need one?

Honest answer: adoption by AI vendors is uneven, and nobody outside those companies knows exactly how much weight any of them give the file. Publish it because it costs an hour and positions you for where discovery is heading — not because it guarantees a single citation. It's a cheap option on a growing channel, and the downside is a markdown file nobody reads.

We follow our own advice: Caply publishes its llms.txt at /llms.txt, and the scanner's Agent Readiness check looks for yours — along with your robots.txt AI-crawler policy and whether your tracking would even see an agent-driven purchase. That last part is Caply's actual job: managed Pixel + Conversions API that sends every Purchase to Meta server-side with hashed email, deduplication, and a per-event Match Forecast score, so conversions get counted no matter how the buyer — or their agent — arrived. Plans are on /pricing if the scan turns something up.

Being visible to assistants and being measurable when they send you buyers are two halves of the same problem. llms.txt is a small, cheap piece of the first half.