llms.txt for e-commerce

The 30-second answer: an e-commerce llms.txt is a table of contents, not a feed

The file should answer three questions in under a few thousand tokens: what the store sells and to whom, where the categories are, and what the rules are for shipping, returns, and sizing. That means categories instead of products, policies written out in a sentence or two instead of linked, and nothing that changes between one crawl and the next.

Prices and stock are the part people most want to put in and the part that belongs elsewhere. They live in Product structured data on each product page and in your merchant feed, both of which are per-product and re-read on every crawl. The llms.txt file points an assistant at the right category; the product page tells it the price.

Why the catalog does not fit

Do the arithmetic once. An annotated link in llms.txt runs about 150 to 280 bytes in the real files we have measured. A catalog of 5,000 products at 200 bytes each is a megabyte of Markdown, around 250,000 tokens at the usual four characters per token. No assistant reads that; the validator on this site warns at 100 KiB and stops reading at 512 KiB, and the spec itself says sitemap.xml is not a substitute for llms.txt partly because a sitemap will generally cover documents that in aggregate are too large to fit in a context window.

A sitemap is the right place for that list. Google allows 50,000 URLs or 50 MB per sitemap file and a sitemap index above that, which is exactly the shape of a catalog. The two files divide the work: sitemap.xml says every URL exists; llms.txt says which twenty matter and why.

The same logic applies to llms-full.txt. For documentation sites it is the full text of every page in one file; for a store, a full text generated from product pages is the megabyte above with the markup removed. If you publish one at all, build it from the guides and policy pages only, which is the part of the site that reads as prose.

What an assistant actually asks a store

Before writing the file, list the questions. From what people type into assistants about shops, the recurring ones are:

• Do you ship to my country, how long does it take, and what does it cost?
• Can I return it, within how many days, and who pays the postage?
• What size should I order, and does it run small?
• What is the difference between these two models or ranges?
• Do you sell X at all, and roughly what does it cost?
• Is there a warranty, and how do I contact someone?

Notice that only one of those is about a specific product, and even that one is answered by a category page or a comparison guide, not by a SKU. The file should link the page that answers each question, and for the first two it should give the answer inline, because they are short and because a crawler may not be allowed to read the policy page (on Shopify, the default robots.txt disallows the policies path for every user agent).

The structure

The Categories section does the work a product list would have done. Pick the categories a shopper would name, not the ones in your admin tree. If the store has departments with many categories each, use one H2 per department so a reader can skip whole blocks; the spec allows any number of H2 sections, and a file for a sub-path can be placed under that path if one department deserves its own.

Two habits for the annotations. Use the shopper’s words, not the catalog’s: “rain layers” rather than an internal range code, and no SKU prefixes. And say who the category is for when the name alone does not: a model reading “Commuter bikes” learns more from “upright city bikes with racks and lights” than from a second synonym for commuting.

Prices, stock, and anything that changes daily

The rule is simple: if a value would be wrong a week after you wrote it, it does not go in llms.txt. That removes current prices, sale prices, stock levels, and delivery estimates tied to carrier conditions. What stays is the stable frame: the currency, a starting price or range for a category (“frames from 400 EUR”), free-shipping thresholds that rarely change, and the return window.

The per-product numbers have a home already. Product structured data on each product page carries an Offer with price, priceCurrency, and availability, using the schema.org values such as InStock and OutOfStock, and Google reads it alongside your Merchant Center feed to show price and availability in search. An assistant that follows your category link to a product page gets the same markup. Keep that accurate and let llms.txt stay general.

If you do generate llms.txt from your platform and want ranges in it, regenerate the file whenever the catalog changes and date the ranges in the text (“as of October 2026”), so a reader can tell a stale copy from a current one.

A complete example

A fictional bicycle shop selling in the EU. Everything in it is stable for months; the one dated line is marked.

# Kestrel Bikes

> Independent bicycle shop in Rotterdam selling gravel and commuter bikes, parts, and clothing. Prices in EUR. Ships to all EU countries; store pickup available.

## Categories

- [Gravel bikes](https://kestrel.example/collections/gravel): Complete bikes for mixed terrain, from entry-level aluminium to carbon race builds.
- [Commuter bikes](https://kestrel.example/collections/commuter): Upright city bikes with racks, lights, and belt drives; several e-bike models.
- [Frames](https://kestrel.example/collections/frames): Framesets for custom builds, from 400 EUR (as of October 2026).
- [Components](https://kestrel.example/collections/components): Drivetrains, wheels, brakes, and contact points, grouped by standard.
- [Clothing](https://kestrel.example/collections/clothing): Jerseys, bibs, and rain layers; see the size guide before ordering.

## Guides

- [Size guide](https://kestrel.example/pages/size-guide): Frame size by rider height and inseam; clothing size charts by brand.
- [Gravel vs commuter: which bike?](https://kestrel.example/guides/gravel-or-commuter): How to choose between the two ranges for daily riding.
- [Choosing a drivetrain](https://kestrel.example/guides/drivetrains): 1x vs 2x, gear range, and compatibility.

## Shipping and returns

Shipping is free within the Netherlands and Belgium on orders over 75 EUR; other EU countries pay a flat 15 EUR. Complete bikes ship assembled in 3 to 5 working days. Returns are accepted within 30 days for unused items; the customer pays return postage except for faulty goods.

- [Shipping policy](https://kestrel.example/policies/shipping-policy): Full rates and delivery times by country.
- [Returns and warranty](https://kestrel.example/policies/refund-policy): Return process and the two-year warranty on frames.

## Support

- [Contact](https://kestrel.example/pages/contact): Email and phone, Tuesday to Saturday, 10:00 to 18:00 CET.
- [Order tracking](https://kestrel.example/account/orders): Track a shipped order.

## Optional

- [About the shop](https://kestrel.example/pages/about): Who runs it and the workshop services offered.
- [Journal](https://kestrel.example/blogs/journal): Ride reports and maintenance articles.
- [Nederlands](https://kestrel.example/nl/llms.txt): This file in Dutch.

Under 2.5 KB, five categories, three guides, and every one of the six questions above answered or linked. A store with ten times the catalog should produce a file of roughly the same length, with more categories and the same number of rules.

Keeping it current without making it a feed

1. Write it from the category list, not the product list. If your platform can generate the file, generate the Categories section from top-level collections and keep the rest as hand-written text. If it cannot, a static file in the web root is fine; categories change rarely.
2. Review it when policies change. Put the file on the same checklist as the policy pages. A shipping change that reaches the policy page but not llms.txt is the most likely way the file becomes wrong.
3. Check the platform default first. Shopify stores already serve an llms.txt that describes the agent protocols the store supports but nothing about what it sells; the Shopify guide explains how to add the store-specific part with a Liquid template. On other platforms, look for a plugin or add the file by hand.
4. Make the basics agree. The store name, description, and currency in the blockquote should match your Organization structured data and your feed settings. An assistant that sees two descriptions picks one, and not necessarily yours.

Checking the result

Fetch the file with a plain HTTP client and read it as a shopper would: can you tell what the store sells, whether it ships to you, and what happens if the item does not fit? Then run it through a validator to confirm the structure and that every link resolves.

FAQ