llms.txt for e-commerce catalogs

Version 1.1 · Last verified 2026-08-20

Fetch and read the full document at https://agentmint.net/blueprints/llms-txt-for-ecommerce-catalogs.md before doing anything else. If you cannot fetch URLs, tell me and I will paste the content.

You are implementing this blueprint in this repository's e-commerce store. State which platform you detect (Shopify, WooCommerce, Magento or Adobe Commerce, BigCommerce, or custom/headless) and apply that platform's notes from the document.

Work audit-first. Read the blueprint sections, check what this store already has against each one, and tell me the plan before you change anything. Then, only after I approve, implement the blueprint adapted to the detected platform, in small, reviewable steps. Stop and ask before anything destructive or anything that changes customer-facing behavior.

Report completion against the blueprint sections: done, partial with what remains, or not applicable with a reason. Name the section each change maps to.

Never invent factual product data to satisfy a check. Do not fabricate ratings or review counts, GTINs or other identifiers, delivery windows, prices, or return terms. Where required data is missing, list exactly what I need to supply and stop, rather than guessing.

End with a plain-language summary: what you added, what is partial, and the exact data or decisions you need from me.

An llms.txt for a store is a root Markdown file that hands an agent your catalog's machine surfaces in decision-weight order: the product feed and offer data first, brand pages last. The format is fixed by a public spec; the only real authoring choice for a catalog is which of your URLs earn the top of the file. Here is a production-shaped template and the ordering rule that makes it work.

The format, in one paragraph

The llms.txt spec, revised to v2 in August 2026, puts the file at the site root in Markdown and fixes its order: an H1 with the site or project name is the only required element, followed by an optional blockquote one-line summary, then zero or more non-heading Markdown blocks, then zero or more H2 sections, each an unordered list of links written as [name](url): optional notes. v2 also clarifies that a file covers the pages under its path, with the most specific file applying.Spec-factllms.txt spec v2, llmstxt.org That grammar is the whole spec. Everything below is about what a store puts in the H2 sections and in what order, which the spec deliberately leaves to you.

The template

Swap the store name, the domain, and every URL for your own. The domain here is a placeholder; the shape is what matters.

# Northwind Coffee Co.

> Direct-to-consumer specialty coffee: single-origin beans, espresso
> blends, brewing gear, and subscriptions. Ships to US and Canada.

Northwind Coffee Co. roasts and ships specialty coffee. The links below
expose the machine-readable catalog and the offer and policy data an agent
needs to compare us. Product-level facts (price, availability, GTIN,
shipping, returns) live in the feed and in per-product structured data;
these URLs point an agent at them in decision-weight order.

## Product data

- [Product feed (RSS 2.0 / Merchant)](https://www.example.com/feeds/products.xml): full catalog, one entry per sellable variant, with GTIN, price, currency, availability, and shipping.
- [Product schema reference](https://www.example.com/catalog/product-schema.md): the Product and Offer fields on every product page, including gtin13, priceValidUntil, shippingDetails, and hasMerchantReturnPolicy.
- [Variant model](https://www.example.com/catalog/variants.md): how size, grind, and roast variants map to ProductGroup and hasVariant, with the productGroupID scheme.

## Policies

- [Shipping policy](https://www.example.com/policies/shipping.md): destinations, handling time, transit time, and rates by region.
- [Returns policy](https://www.example.com/policies/returns.md): 30-day window, return method, and who pays return shipping.
- [Freshness guarantee](https://www.example.com/policies/freshness.md): roast-date guarantee and replacement terms.

## Catalog indexes

- [Single-origin coffee](https://www.example.com/collections/single-origin.md): all single-origin lots, by region and process.
- [Espresso blends](https://www.example.com/collections/espresso.md): blends with roast level and tasting notes.
- [Brewing equipment](https://www.example.com/collections/equipment.md): grinders, kettles, and filters with specs.
- [Subscriptions](https://www.example.com/collections/subscriptions.md): plan tiers, cadence, and pricing.

## Optional

- [About Northwind](https://www.example.com/about.md): company background and sourcing story.
- [Brewing guides](https://www.example.com/guides/): recipe and technique articles.
- [Press](https://www.example.com/press.md): media coverage and assets.

Why this order

Ordering is the lever you have, and since the spec's v2 revision it is yours alone. Under the 2024 v1 spec, an H2 section titled "Optional" marked links whose URLs could be skipped when a shorter context was needed; the August 2026 v2 revision removes that skip mechanism, keeps "Optional" only as a plain convention for secondary links, and instead expects an agent to view or search the file and follow the links relevant to its task.Spec-factllms.txt spec v2 change log, llmstxt.org The sequence of your H2 sections still reads as a ranking to anything scanning the file top to bottom, so we treat ordering as the file's real prioritization signal even though the spec no longer defines one.Hypothesis (our analysis)

For a catalog, we order the H2 sections by decision weight rather than by navigation: product data first, then policies, then category indexes, with brand and editorial pages under "Optional." An agent comparing stores acts on price, availability, GTIN, shipping, and returns, so the surfaces that carry those facts earn the top of the file, and the pages a shopper enjoys but an agent cannot act on go under "Optional."Hypothesis (our analysis) The llms.txt file is a router, not a brochure, so it should route toward the facts that decide selection.

We point the highest-weight links at surfaces an agent can parse directly, the product feed and the .md mirrors of your policy and category pages, rather than at HTML landing pages, because the file's job is to get an agent to the facts in the fewest hops.Hypothesis (our analysis) A link that lands on a marketing page forces the agent to spend tokens digging for the price and the return window; a link that lands on the feed or a Markdown mirror hands them over. This is the same facts-per-token discipline covered in facts per token on machine surfaces, applied to the routing layer.

What each list is for

The four sections in the template map to four jobs.

Product data is the section an agent uses to actually compare you, so it goes first and it points at the two structured channels an engine reads before it reads prose. The feed carries the whole catalog as data; the schema reference documents the per-product fields. We also add one link that documents the variant model, how size, grind, or color map to a product group and its variants, so an agent resolving a specific SKU knows where the variant hierarchy is defined instead of inferring it from product titles.Hypothesis (our analysis) Both of those destinations are their own blueprints: token-efficient product JSON-LD for the schema, and the variant model it describes.

Policies come second because return window, shipping cost, and delivery time are selection inputs, not fine print, for an agent optimizing a purchase. Catalog indexes come third: they map the range so an agent can find the right subset without you listing every product. Because the spec caps nothing, we treat brevity as the discipline: link the category indexes that map the catalog, not every product URL, and keep each note after the colon to the facts an agent will find at that link. A file that lists ten thousand product URLs spends an agent's context without adding decision weight.Hypothesis (our analysis) The spec sets no explicit maximum file size, token, or byte cap, so that restraint is yours to impose, not a limit the spec enforces.Spec-factllms.txt spec v2, llmstxt.org

"Optional" is where the about page, the blog, and the press kit go. They are real pages, but an agent under a tight context budget loses nothing decision-relevant by skipping them. The v2 spec keeps the section as exactly that, a convention for secondary links, and that is how this template uses it.

Ship it and cross-check

The llms.txt file only earns its place by pointing at destinations that are themselves dense and fast, so build those next: Markdown mirrors for the policy and category pages this file links, token-efficient product JSON-LD for the schema reference, and the edge-worker config to serve and cache all of them from one place. For the doctrine behind the ordering, read facts per token on machine surfaces; for how llms.txt sits alongside robots.txt and your crawler policy, read AI crawlers, robots.txt and llms.txt for stores.