llms.txt for Ecommerce Websites: Forty of Four Thousand Products Belong in the File

A store with four thousand SKUs (stock keeping units) faces one hard decision about llms.txt, the plain text file at a domain root that tells language models which pages explain the business. The decision is how few links to publish. Most guidance on llms.txt for ecommerce websites was written for documentation sites, where listing every page is reasonable because there are two hundred of them. Retail breaks that assumption at the first collection. Four thousand product links produce a file no model reads to the end, and they bury the six category pages that answer a buyer's question. This piece sets out the selection hierarchy, the exclusion rule that keeps a monthly file accurate, and a worked cut from four thousand items down to forty.
Key takeaways:
- One product line runs about 120 characters, so 4,000 products produce roughly 480,000 characters and close to 120,000 tokens, which is 4.8 times the 100,000 character ceiling Mintlify applies to automatically generated files.
- Forty selected links in an llms.txt for ecommerce websites cost about 4,800 characters and roughly 1,200 tokens, one percent of the catalogue dump.
- Shopify disabled /llms.txt and /llms-full.txt on 20 May 2026 and redirected both to /agents.md, according to the Shopify Developer Community thread on agentic commerce.
- Shopify documentation states that in the agents.md template "only two objects are available:
requestandagents", so a theme cannot loop over the catalogue.- Adobe Analytics recorded AI referred traffic to United States retail sites up 138% year over year in May 2026, converting 54% better than non-AI sources.
Four thousand product links cost roughly 120,000 tokens
Count the characters before counting the benefits of an llms.txt for ecommerce websites. A well formed line pairs a product name, its URL and a one line description in markdown link syntax. On a real catalogue that line runs about 120 characters once the handle and the description are in place. Four thousand of them come to 480,000 characters, which at four characters per token is close to 120,000 tokens.
Mintlify, which generates these files for documentation sites at scale, caps its automatic output. Its documentation states that "automatically generated llms.txt files cannot exceed 100,000 characters", and beyond that limit it truncates the file and notes the omitted pages. A four thousand product dump exceeds that ceiling by 4.8 times before a single policy page is added.
The specification anticipated the problem. Jeremy Howard, author of the llms.txt proposal, published it on 3 September 2024 and framed it against the file retail already publishes: "sitemap.xml will generally cover documents that in aggregate will be too large to fit in an LLM context window, and will include a lot of information that isn't necessary to understand the site." A file listing every product handle reproduces the sitemap in markdown, at a URL agents were told to trust for a summary. The llms.txt specification makes only one section mandatory, the H1 carrying the site name, and treats everything below it as curated selection.
Forty links change the arithmetic of an llms.txt for ecommerce websites. Forty lines at 120 characters come to 4,800 characters, roughly 1,200 tokens, one percent of the catalogue version. A model holds all of it alongside the buyer's question and still has room to reason.
The selection hierarchy for llms.txt for ecommerce websites
Selection inside an llms.txt for ecommerce websites follows catalogue structure, ranked from the most durable content to the most perishable. Six content types earn a slot, each with its own link budget.
- Brand and positioning. One to two links. The about page, plus the page stating who the store buys from and why. Every other link is read against this context.
- Top-level collections. Six to ten links. These pages answer "do you sell X", and they survive inventory churn because a collection URL outlives the products inside it.
- Sub-collections and filtered category pages. Ten to fifteen links. Reserve them for the filters buyers name out loud: size ranges, materials, compatibility families. Skip colour and price facets.
- Buying guides and comparison content. Six to ten links. A model answering "which one should I get" needs prose that compares, and guide pages are where that prose lives in a catalogue.
- Sizing, compatibility and specification references. Three to six links. Fit charts, part finders, material glossaries, all quoted verbatim more often than any other retail page because they are already structured as answers.
- Hero products. Three to five links. Only items that define the brand and hold their URL for years.
| Content type | Link budget | Refresh cadence |
|---|---|---|
| Brand and positioning | 1 to 2 | Yearly |
| Top-level collections | 6 to 10 | Yearly |
| Sub-collections and filters | 10 to 15 | Quarterly |
| Buying guides and comparisons | 6 to 10 | Quarterly |
| Sizing and compatibility references | 3 to 6 | Yearly |
| Hero products | 3 to 5 | Quarterly |
Policies sit outside the hierarchy as a fixed block of three to four links, covering returns, shipping and warranty, because agents check them before recommending a merchant. BigCommerce makes the same argument in its ecommerce guidance and adds a real time product feed as the machine readable companion to the curated file.
The budget matters more than the ranking. A file that spends its whole allowance on tiers two and six, collections and hero products, tells a model what the store stocks and says nothing about how to choose. Tiers four and five carry the reasoning a buyer asks for.
Anything that changes weekly stays out of a monthly file
An llms.txt for ecommerce websites regenerated monthly cannot carry content that changes weekly. That single test removes most of a retail catalogue. Apply it to each candidate URL and ask what changes, and how often.
- URL stability. Seasonal collection pages built per campaign (
/collections/summer-drop-3) are dead links by October. The evergreen parent (/collections/swimwear) survives. - Availability. A product that sells out and returns under a new handle produces a 404 inside the file. Agents that hit a 404 from a curated list have little reason to trust the next line.
- Price. Any page whose value to the reader is the current price belongs in a product feed, which updates continuously, rather than in a static file regenerated on a schedule.
Adobe Analytics measured AI referred traffic to United States retail sites up 393% year over year in the first quarter of 2026, across more than one trillion tracked visits, with revenue per visit from AI referrals running 37% above non-AI traffic in March 2026. Traffic at that scale arrives at whatever the file pointed to, accurate or stale. Fifty broken product links inside an llms.txt for ecommerce websites cost more than forty accurate ones earn, because they spend merchant credibility on inventory that no longer exists.
Shopify redirects /llms.txt to /agents.md by default
Shopify merchants inherit a file before they write one. The platform serves /agents.md on every store, and the /llms.txt and /llms-full.txt routes mirror that content. Merchants in the Shopify Developer Community thread on agentic commerce recorded the sequence: on 8 May 2026 the native routes broke prior proxy and redirect customisations, and on 20 May 2026 Shopify disabled /llms.txt and /llms-full.txt in favour of /agents.md. One developer described the generated default as "stripped to bare bones content and an Ad to sign up on Shopify".
The override arrived on 28 May 2026. The Shopify developer changelog introduced three theme templates, templates/agents.md.liquid, templates/llms.txt.liquid and templates/llms-full.txt.liquid, with a stated fallback order: "If no template is present for a given path, it falls back to your agents.md template, then to the Shopify-generated default."
The template context is restricted, and this is where catalogue dumps die on arrival. Shopify's documentation for agents.md.liquid states that "only two objects are available: request and agents", and that "standard theme objects such as shop and collections don't work in this template". The agents object exposes store metadata including store_name, store_url, mcp_endpoint_url and sitemap_url. A theme template therefore cannot loop over four thousand products: the selection has to be written by hand or generated upstream and pasted in. Shopify forces an llms.txt for ecommerce websites to be an editorial artefact. The mechanics are covered in how to override the Shopify agents.md theme templates.

One file per storefront domain, cross-referenced
Every storefront domain serves its own file at its own root. A merchant running example.com, example.de and a separate marketplace storefront publishes three files, because agents fetch the file at the domain they are already on.
Recognition across the three comes from repeating the same identifying block. Each file opens with the same legal entity name, the same brand description, and an explicit list of sibling domains under a heading such as ## Other storefronts. Three files that name each other read as one merchant. Three files that describe unrelated shops read as three merchants, and the reviews, policies and brand context earned on one fail to transfer.
Locale variants follow the same rule with one addition. Each file links only to URLs in its own locale, and the buying guides listed in the German file are the German translations rather than the English originals. A model answering in German that lands on English guide pages will summarise them into German and lose the terminology the store uses in its own market. Applying an llms.txt for ecommerce websites across locales is a translation problem before it is a technical one.
The same discipline applies at larger scale, where thousands of generated URLs compete for a handful of slots. That case is worked through in keeping llms.txt and llms-full.txt honest on a ten thousand page site.
Worked example: cutting four thousand items to forty
Take a fictional store, Meridian Outdoor, carrying 4,000 SKUs across camping, climbing and trail running, with roughly 30% of the catalogue turning over each season. Here is the cut to forty links inside its llms.txt for ecommerce websites, with the reasoning behind each line.
1 brand line. The about page, which states the buying policy and the repair programme. Cut: the careers page, the press page and the store locator, none of which help a model answer a product question.
6 top-level collections. Camping, climbing, trail running, packs, sleep systems, apparel. Cut: 41 seasonal landing pages, each carrying a campaign token in its URL that expires with the campaign.
12 sub-collections. Chosen by the filters buyers name out loud: tent capacity (2P, 3P, 4P), sleeping bag temperature ratings, rope diameters, shoe drop ranges. Cut: colour, price band and brand facets, 180 URLs in total, none of which a buyer uses to describe what they want.
8 buying guides. How to choose a tent, sleeping bag temperature ratings explained, rope diameter and belay device compatibility, and five more. These carry most of the comparative prose in the catalogue, which makes them the highest value lines.
5 reference pages. Footwear and apparel size charts, the pack volume guide, the rope and device compatibility table, the fabric glossary.
4 policy pages. Returns, shipping, warranty, repair.
4 hero products. Items that have held their URL for more than three years and that the brand is known for.
The total is 40 links across 4,800 characters. Excluded: 3,996 product URLs, 41 campaign collections and 180 facet URLs, together 99% of the site's indexable inventory pages. Writing the one line description under each surviving link decides whether the selection pays off, and it is covered in an llms.txt generator that earns its place at your domain root.
FAQ: llms.txt for ecommerce websites
How many links should an llms.txt for ecommerce websites contain?
Forty links is a defensible target for an llms.txt for ecommerce websites on any catalogue between one thousand and fifty thousand SKUs. The number derives from the token budget rather than the catalogue size: forty lines at roughly 120 characters produce 4,800 characters, around 1,200 tokens, which a model holds in full while answering a question. Stores under two hundred products can list more, because the entire catalogue still fits inside a reasonable context budget.
Should individual products appear in the file at all?
Three to five products belong in an llms.txt for ecommerce websites, chosen for durability. A product earns a slot when it has been in the catalogue for years, defines the brand, and keeps its URL through restocks. Every other product reaches a model through the collection page above it, or through a structured product feed. BigCommerce recommends pointing the file at a real time feed for exactly this reason, since prices and availability move faster than any file regenerated on a schedule.
Does Shopify generate the file automatically?
Yes. Shopify serves /agents.md on every store, and /llms.txt and /llms-full.txt mirror it. Since 20 May 2026 the two llms routes redirect to /agents.md, according to the Shopify Developer Community thread. Merchants override the default with a templates/agents.md.liquid file, a capability announced on 28 May 2026. The generated default is generic, so an untouched store publishes no selection whatsoever.
What is the difference between llms.txt and llms-full.txt?
One is an index, the other a corpus. Mintlify describes llms.txt as a file that "helps LLMs index content more efficiently, similar to how a sitemap helps search engines", while llms-full.txt "combines your entire documentation site into a single file as context for AI tools". For a retail catalogue the full variant rarely earns its place, because product pages carry too little prose to be worth combining.
How often should a store regenerate the file?
Monthly, and the selection inside an llms.txt for ecommerce websites should be built so that monthly is enough. Any URL whose accuracy depends on a shorter interval belongs in a product feed instead. Regenerate immediately after a collection restructure, a locale launch or a policy change, because those three events break links that agents have already been served and cached.
Does each locale need its own file?
Each storefront domain needs its own llms.txt for ecommerce websites, and locale subdomains count as separate domains. Each file lists URLs in its own locale and names the sibling domains explicitly, so agents recognise one merchant across three roots. A single file covering three locales forces a model to guess which URL to hand a German speaking buyer, and it will guess wrong often enough to matter.
How La Boétie builds an llms.txt for ecommerce websites
La Boétie is a venture studio and technical consultancy that ships its own software, including a self-serve tool built for this exact job.
Selection. An llms.txt for ecommerce websites starts as a mapping exercise: the catalogue is scored against the six tier hierarchy above and cut to roughly 40 links, using the store's own collection structure rather than a generic template. Merchants keep the selection in their repository, under their own version control.
Generation. The llms.txt Generator runs the crawl, the selection and the description writing in a single pass, at $25 or 20 € a run. One job, done end to end, with no account and no call.
Verification. A published file is checked against what agents actually fetch, using server logs rather than assumptions, across every route a store now exposes. The scoring method is set out in testing your llms.txt implementation beyond conformance.
The studio runs on a flexible team of five to six engineers across several time zones, and clients keep ownership of everything that gets built.
Conclusion
The discipline in llms.txt for ecommerce websites is subtraction. Forty links across 4,800 characters give a model the brand, the categories, the guides that compare, the references it can quote, and the policies it checks before recommending a merchant. Four thousand links give it a sitemap in markdown at 120,000 tokens, of which it will read a fraction and stop. Adobe Analytics recorded AI referred retail traffic up 138% year over year in May 2026, converting 54% better than non-AI sources, so the forty lines a merchant chooses now carry measurable revenue.
Sources
- The /llms.txt file proposal : Jeremy Howard, Answer.AI, 2024
- Customize /llms.txt, /llms-full.txt and /agents.md : Shopify Developer Changelog, 2026
- agents.md.liquid template reference : Shopify Developer Documentation, 2026
- llms-full.txt.liquid template reference : Shopify Developer Documentation, 2026
- Llms.txt and agents.md, Agentic Commerce thread : Shopify Developer Community Forums, 2026
- llms.txt documentation : Mintlify, 2026
- Adobe: AI referred traffic to retail sites doubles in a year : Digital Commerce 360, 2026
- AI traffic to US retailers rose 393% in Q1 : TechCrunch, 2026
- LLMs.txt for Ecommerce : BigCommerce, 2026
Also read:
Questions
How many links should an llms.txt for ecommerce websites contain?
Forty links is a defensible target for an llms.txt for ecommerce websites on any catalogue between one thousand and fifty thousand SKUs. The number derives from the token budget rather than the catalogue size: forty lines at roughly 120 characters produce 4,800 characters, around 1,200 tokens, which a model holds in full while answering a question. Stores under two hundred products can list more, because the entire catalogue still fits inside a reasonable context budget.
Should individual products appear in the file at all?
Three to five products belong in an llms.txt for ecommerce websites, chosen for durability. A product earns a slot when it has been in the catalogue for years, defines the brand, and keeps its URL through restocks. Every other product reaches a model through the collection page above it, or through a structured product feed. BigCommerce recommends pointing the file at a real time feed for exactly this reason, since prices and availability move faster than any file regenerated on a schedule.
Does Shopify generate the file automatically?
Yes. Shopify serves /agents.md on every store, and /llms.txt and /llms-full.txt mirror it. Since 20 May 2026 the two llms routes redirect to /agents.md, according to the Shopify Developer Community thread. Merchants override the default with a templates/agents.md.liquid file, a capability announced on 28 May 2026. The generated default is generic, so an untouched store publishes no selection whatsoever.
What is the difference between llms.txt and llms-full.txt?
One is an index, the other a corpus. Mintlify describes llms.txt as a file that helps large language models index content more efficiently, similar to how a sitemap helps search engines, while llms-full.txt combines an entire documentation site into a single file as context for AI tools. For a retail catalogue the full variant rarely earns its place, because product pages carry too little prose to be worth combining.
How often should a store regenerate the file?
Monthly, and the selection inside an llms.txt for ecommerce websites should be built so that monthly is enough. Any URL whose accuracy depends on a shorter interval belongs in a product feed instead. Regenerate immediately after a collection restructure, a locale launch or a policy change, because those three events break links that agents have already been served and cached.
Does each locale need its own file?
Each storefront domain needs its own llms.txt for ecommerce websites, and locale subdomains count as separate domains. Each file lists URLs in its own locale and names the sibling domains explicitly, so agents recognise one merchant across three roots. A single file covering three locales forces a model to guess which URL to hand a German speaking buyer, and it will guess wrong often enough to matter.