# llms.txt for e-commerce catalogs

> Ship a root /llms.txt whose H2 link lists run in decision-weight order: product feed, offer and policy data, and category indexes first; brand and blog pages under 'Optional'. Copy the template below and swap in your URLs.

<!-- A production-shaped llms.txt template for a store catalog, ordered by decision weight so agents read your product feed, offers, and policies first. -->
<!-- Canonical: https://agentmint.net/blueprints/llms-txt-for-ecommerce-catalogs/ · Blueprint v1.0 · By Abdalsalaam Halawa · Published 2026-07-08 · Last verified 2026-07-08 -->
<!-- Evidence tags below are load-bearing: <Claim type="spec-fact|reported|hypothesis"> marks how each factual claim is sourced. -->

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 sit above the skip line. Here is a production-shaped template and the ordering rule that makes it work.

<KeyTakeaways
  items={[
    "The spec fixes the file's structure but gives you exactly one prioritization lever: the 'Optional' H2 section. Everything above it is what an agent should read first.",
    "For a catalog, order your H2 link lists by decision weight: the product feed, per-product structured data, and shipping and return policies first; brand, blog, and press pages under 'Optional'.",
    "Point the top links at surfaces an agent can act on directly, the feed and the .md mirrors of your policy and category pages, not at HTML landing pages.",
    "The spec sets no size cap, so density is your discipline: link the category indexes that map the catalog, not every product URL.",
  ]}
/>

<Callout variant="note" title="What this blueprint adds">
  The llms.txt format itself is owned by the proposal at llmstxt.org, and we link out to it rather than restate the grammar. What this blueprint adds is the part the spec leaves open for a store: which of your URLs carry buying-relevant facts, and therefore which links belong above the "Optional" line. That ordering is our pattern, not a spec requirement.
</Callout>

## The format, in one paragraph

<Claim type="spec-fact" source="llms.txt proposal, llmstxt.org" href="https://llmstxt.org">The llms.txt proposal 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`.</Claim> 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.

```markdown
# 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

The spec gives you one place to say what matters less, and nothing to say what matters more, so ordering is the lever you have. <Claim type="spec-fact" source="llms.txt proposal, llmstxt.org" href="https://llmstxt.org">The proposal gives exactly one prioritization signal: an H2 section titled "Optional" marks links whose URLs can be skipped when a shorter context is needed.</Claim> Everything above "Optional" is what the spec expects an agent to read first, which means the sequence of your H2 sections is itself a ranking.

<Claim type="hypothesis">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 below the skip line.</Claim> The [llms.txt](/glossary/#llms-txt) file is a router, not a brochure, so it should route toward the facts that decide selection.

<Claim type="hypothesis">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.</Claim> 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](/handbook/information-density/), 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. <Claim type="hypothesis">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.</Claim> Both of those destinations are their own blueprints: [token-efficient product JSON-LD](/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. <Claim type="hypothesis">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.</Claim> <Claim type="spec-fact" source="llms.txt proposal, llmstxt.org" href="https://llmstxt.org">The proposal sets no explicit maximum file size, token, or byte cap, so that restraint is yours to impose, not a limit the spec enforces.</Claim>

"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, which is exactly what the section is for.

## 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](/blueprints/product-markdown-mirror/) for the policy and category pages this file links, [token-efficient product JSON-LD](/blueprints/token-efficient-product-json-ld/) for the schema reference, and the [edge-worker config](/blueprints/edge-worker-machine-surfaces/) to serve and cache all of them from one place. For the doctrine behind the ordering, read [facts per token on machine surfaces](/handbook/information-density/); for how llms.txt sits alongside robots.txt and your crawler policy, read [AI crawlers, robots.txt and llms.txt for stores](/ai-crawlers-robots-llms-txt/).