llms.txt for Ecommerce: What It Is, What It Isn't and a Store Template

llms.txt is a Markdown file at the root of a website (yourstore.com/llms.txt) that gives AI models a short, curated map of the site: one heading with the site name, a one-paragraph summary, and lists of links to the pages that matter, each with a short note. It was proposed in September 2024 as a way to help language models and AI agents find the useful parts of a site without wading through navigation, scripts and cookie banners.

For an online store, the short answer is this: an llms.txt file takes an afternoon to write, it does not improve your rankings in Google Search (Google says Search ignores it), and no major AI shopping assistant has documented reading it. It can still help agents that do look for it, and many stores already serve one they never wrote. The part that decides whether an AI assistant recommends your products is the product data the links point to. Below: what the file is, what it is not, who uses it, and a template built for a catalog rather than a documentation site.

Where llms.txt came from: Jeremy Howard's 2024 proposal

Jeremy Howard of Answer.AI published the proposal at llmstxt.org on September 3, 2024. The reasoning was practical: a language model has limited room to read, and an HTML page spends much of that room on menus, footers, scripts and tracking code. A small Markdown file written for machines could point a model straight at the content worth reading, in a format it parses easily.

The first adopters were software companies with large developer docs, where a coding assistant benefits from a clean index of API pages. That origin explains why most examples you find online list API references and SDK guides. A store has different content: categories, products, policies and buying guides. The format works for both, but the contents need rethinking.

llms.txt is a proposal, not a standard ratified by a standards body, and nothing obliges an AI company to read it. Keep that in mind when a tool vendor calls it essential.

The llms.txt format, element by element

The proposal defines a fixed order. Only the first element is required:

1. An H1 with the site or project name. For a store: the store name.
2. A blockquote with a short summary of what the site is and the key context a model needs to understand the rest.
3. Optional paragraphs or lists without headings with more detail, for example the countries you ship to or your returns window.
4. Zero or more H2 sections, each a list of links. Every item is a Markdown link, optionally followed by a colon and a note: what is on that page and why it matters.
5. An H2 section named Optional for secondary links an agent can skip when it is short on context.

The proposal also asks sites to offer clean Markdown versions of their pages at the same URL with .md added (/road-bikes becomes /road-bikes.md, or index.html.md for a URL without a filename). The second version of the proposal adds discovery hints: an HTML link element or HTTP Link header with rel="describedby" pointing to the llms.txt file, and rel="alternate" type="text/markdown" pointing to a page's Markdown copy.

You will also see llms-full.txt. It is not part of the proposal. It is a convention that spread from documentation platforms: one file with the full text of the site instead of links to it. For a store with thousands of products, a full-text file quickly becomes too large to be useful, which is why the template further down links to category pages and a feed instead.

WISEPIM publishes its own file at wisepim.com/llms.txt, and it follows this shape: an H1, a one-paragraph summary in a blockquote of what the product does and who it is for, a link to the full documentation as llms-full.txt, and then sections of documentation links with a one-line note each. That is a software company's file. A store's file puts different things in the same slots.

What llms.txt does not do: rankings, crawl control and AI citations

Most confusion about llms.txt comes from expecting it to behave like robots.txt or like a ranking signal. It is neither.

• It is not a Google ranking factor. Google's guide to optimizing for generative AI features in Search lists llms.txt among the things you can ignore. It says you may create the files for other services, but that they will "neither harm nor help" visibility in Search, "as Google Search ignores them." The same guide tells you to keep using structured data and Merchant Center feeds.
• It does not control crawling. llms.txt invites; it does not permit or block. To stop an AI crawler from fetching your pages you still use robots.txt rules for its user agent.
• It is not proof of anything. In April 2025 Google's John Mueller compared it to the keywords meta tag: a claim a site owner makes about the site, which a search engine can check against the site itself. He added that, as far as he knew, none of the AI services had said they used it (Search Engine Journal).
• It is not a sitemap. A sitemap lists every URL for discovery. llms.txt is a selection with context: fewer links, each explained.

Google is the only large search provider that has said in writing what it does with the file. We have not found a public statement from OpenAI, Perplexity, Microsoft or Anthropic that their shopping answers read a store's llms.txt. Treat any promise of more AI traffic from the file alone with suspicion.

Who publishes llms.txt: developer docs first, now every Shopify store

Adoption is wider than the lack of a ranking effect suggests, mostly because platforms now generate the file for you:

The practical consequence: if you run Shopify, you probably already serve an llms.txt that Shopify wrote. Open yourstore.com/llms.txt before you write anything, and decide whether the default says what you want an agent to know.

An llms.txt template for an online store

Documentation-style files list every page. A store's file should do the opposite: describe the catalog in a few lines and point to the pages and data sources that hold the detail. This structure works for most B2C and B2B stores:

1. H1: the store name as shoppers know it.
2. Blockquote: what you sell, to whom, in which countries and currencies, in two or three sentences.
3. Key facts (no heading): shipping costs and free-shipping threshold per country, delivery times, returns window and who pays return shipping, warranty terms, payment methods, whether prices include VAT, and B2B terms if you sell to businesses.
4. ## Categories: one line per top-level category with a link and a note that carries real facts: number of products, main brands, size or spec ranges. Twelve lines beat twelve hundred.
5. ## Buying guides and size charts: fit guides, compatibility tables, how to choose a size or model. This is the content agents use to answer "which one should I buy."
6. ## Policies: shipping, returns, warranty, privacy and terms, each with a one-line summary.
7. ## Product data: your product sitemap and, if you publish one, a public product feed. Note the format and how often it refreshes.
8. ## Optional: about us, physical stores, blog, careers, press.

Worked example: a Dutch bike parts store

Here is that structure filled in for a fictional store, Velowinkel, that sells bike parts and accessories in the Netherlands and Belgium. Each item below is one line or block of the file:

• H1: Velowinkel
• Blockquote: Velowinkel sells bike parts, tires and accessories for road, gravel and city bikes to shoppers in the Netherlands and Belgium. Prices are in EUR and include 21% Dutch VAT. Around 6,800 products from 140 brands.
• Key facts: Free shipping in the Netherlands from EUR 50, EUR 4.95 below that; Belgium EUR 6.95. Ordered on a working day before 22:00, delivered the next working day in the Netherlands. 30-day returns, free return label for unused items. Payment by iDEAL, Bancontact, card and PayPal.
• ## Categories: Tires (/tires): 1,240 tires and inner tubes, ETRTO sizes 23-622 to 57-622, tubeless and clincher, valve types Presta and Schrader. Drivetrain (/drivetrain): chains, cassettes and chainrings, 9- to 12-speed, Shimano, SRAM and Campagnolo compatible. Lights (/lights): 310 front and rear lights, StVZO-approved models marked. One line per category, eight in total.
• ## Buying guides: Tire width guide (/guides/tire-width): which tire widths fit which rim widths, with a compatibility table. Chain compatibility (/guides/chain-compatibility): which chain fits which cassette by speed and brand.
• ## Policies: Shipping (/shipping), Returns (/returns): 30 days, free label, excludes cut-to-length cables. Warranty (/warranty): two years under EU consumer law, manufacturer warranty on frames and wheels.
• ## Product data: Product sitemap (/sitemap_products_1.xml). Product feed (/feeds/products-nl.xml): Google Shopping XML format, all in-stock products, refreshed daily at 02:00.
• ## Optional: About Velowinkel (/about), Workshop in Utrecht (/workshop), Blog (/blog).

In the real file each of those parentheses is a full Markdown link. Notice what carries the weight: the notes. "Tires: 1,240 tires and inner tubes, ETRTO sizes 23-622 to 57-622" tells an agent whether this store can answer a question about a 28 mm road tire before it fetches a single page. "Tires: our tire range" tells it nothing.

Product feeds, Markdown product pages and large catalogs

A store with 50 products can link each one. A store with 20,000 cannot, and should not try: the file would be longer than the context an agent wants to spend on it. Three better routes for large catalogs:

• Link a public product feed. If you already generate a feed for Google Shopping or a comparison site, it contains titles, prices, availability, GTINs and attributes in a structured format. Whether to make it public is a business choice: competitors can read it too. The product feed management guide covers how to structure one.
• Offer Markdown versions of category and product pages. Generate them from your product fields rather than converting the HTML: title, brand, GTIN, price and availability, then attributes as a plain list (tire width: 28 mm, ETRTO: 28-622, bead: foldable, weight: 215 g), compatibility, what is in the box, and the return policy. A product without those fields produces an empty Markdown page.
• Keep llms-full.txt for policies and guides, not the catalog. Full product text for thousands of SKUs is better served by the feed and the product pages themselves.

Whatever route you choose, the file only describes data that exists elsewhere. Our post on technical SEO for ecommerce covers the crawlability side: canonical URLs, sitemaps and status codes all still apply to the pages llms.txt links to.

Why the attributes behind each link decide AI recommendations

Mueller's objection points at the real issue. An AI assistant that is asked for a waterproof rear light with USB-C charging and StVZO approval does not trust a summary file; it reads product pages, structured data and merchant feeds, and it compares facts. If "waterproof" is buried in a marketing paragraph and the IP rating is missing, the product loses that comparison no matter how well the llms.txt describes the category.

So the useful order of work for a store is the reverse of the hype:

1. Fill the attributes shoppers filter and ask on: dimensions with units, materials, compatibility, certifications, power and battery specs, size ranges. Read how language models use product data for why typed fields beat prose.
2. Expose them in structured data on the product page. The schema.org guide for product taxonomies shows which properties matter, and the free product schema generator builds a Product JSON-LD block to compare against yours.
3. Send them in your feeds, including the feeds that AI assistants ingest directly. The ChatGPT Shopping feed guide lists the fields OpenAI asks for.
4. Then write llms.txt as the map to all of the above.

Seven checks before your store's llms.txt goes live

Once the file is live, read your server logs for requests to /llms.txt and the .md pages. That tells you which agents fetch it, which is more reliable than any claim about which ones should.

WISEPIM works on the layer underneath the file: it fills missing attributes, descriptions and translations with AI, checks every product against channel rules in Quality Guard, and generates feeds through Feed Hub, so the pages and feeds your llms.txt points to hold the facts an assistant compares on. The agentic commerce feature page shows what that looks like on a catalog.