What are the llms.txt best practices for a WooCommerce store, and which ones are just guesses?

Last updated: November 4, 2026

Say you have 180 products in 12 categories, a blog with 40 posts, and a generator just offered to turn all of that into an llms.txt file. Accept the defaults and you get a 232-line file that lists your cart page, your privacy policy and a product you discontinued in March. The llms.txt best practices that circulate online are mostly sensible, but they come from documentation sites, not stores, and almost none of them separates what the proposal requires from what people have guessed. This guide does both: the format rules from the proposal itself, the practices that follow from how the file would be read if anyone read it, a structure built for a product catalog, and a plain statement of what is still unknown.

What does the llms.txt proposal actually require?

Only an H1 containing the site's name. The proposal at llmstxt.org lists the sections in order: an optional byte-order mark, the H1, a blockquote with a short summary, optional non-heading sections, zero or more H2 lists of links, and an Optional section for secondary material. It says the file can live at the site root or at any path, covering the pages under that path.

The proposal was published by Jeremy Howard in September 2024 and last modified in August 2026. It describes a Markdown file, not JSON or XML, and suggests publishing Markdown copies of important pages at the same URL with .md appended. Everything beyond that structure is advice from people who have written files, not rules from the proposal.

What is known about whether anyone reads it?

Little, and none of it encouraging. Search Engine Land tracked ten sites for 90 days before and after adding the file and found AI crawlers rarely requested it. Google's John Mueller has said that none of the AI services have stated they use it. Chrome's Lighthouse audits for the file and calls it an emerging convention. So the practices below are written for a reader that may not exist yet.

Why follow practices for a reader that may not exist? Because the cost of following them is the same ten minutes as the cost of ignoring them, and a file that is wrong can embarrass you if a reader does arrive: a staging link in a public file, a product that no longer exists quoted with last year's price. The practices here are chosen to make the file harmless and accurate first and useful second.

That changes how to spend time on the file. Ten minutes with a generator is proportionate. Ten hours of hand-curation is not. The llm.txt for SEO guide sets out the evidence with sources. The rest of this page assumes you have read it and decided to make a file anyway, which is a reasonable decision as long as it stays cheap.

Best practice 1: start with the H1 and a two-sentence blockquote

The H1 is your store's name, exactly as it appears on the site. The blockquote says what you sell, for whom, and where you ship, in two sentences. If a reader stopped there, they should be able to describe the store correctly. Most generated files bury this under a boilerplate paragraph or skip the blockquote entirely.

# Northwind Kitchen

> Northwind Kitchen sells cast iron and carbon steel cookware for home cooks, made in small batches and shipped from Oregon to the US and Canada. Prices are in USD and include a 10-year warranty.

Best practice 2: one H2 per category, products as links with one-line descriptions

Mirror your catalog's top level. Each H2 is a category, each line under it is a product link followed by a colon and one sentence with the detail a shopper would ask about: size, material, price range, what it is for. Do not paste the product description. Do not list every variation.

## Skillets

- [10-inch cast iron skillet](https://example.com/product/10-inch-skillet/): pre-seasoned, 4.5 lb, oven safe to 500F, $48.
- [12-inch carbon steel skillet](https://example.com/product/12-inch-carbon-steel/): lighter than cast iron, 3 lb, needs seasoning, $62.

## Dutch ovens

- [5-quart enameled Dutch oven](https://example.com/product/5-qt-dutch-oven/): enameled interior, dishwasher safe, four colors, $129.

Two refinements for larger catalogs. First, if a category has more than fifteen products, list the five to ten that sell most or that you most want quoted, and link the category page itself in the first line so a reader can find the rest. Second, if you sell variations such as sizes or colors, list the parent product once and mention the range in the description rather than listing every variant, which would turn a summary back into a sitemap.

A worked example, not a customer result. A store with 180 products in 12 categories generates a file and cuts it to 12 H2s, 48 product links, 4 policy links and 6 blog links, 58 lines of links in all. The whole file is under 10 KB. Reading it top to bottom takes under two minutes, which is a fair test: if you cannot read your own file in two minutes, a machine with a limited context window is not going to do better.

The one-line description is the part worth a human minute per product, because it is the sentence an assistant would quote if it quoted anything. A generator that pulls the product's short description does a fair job. One that pulls the first sentence of the long description usually does not.

Best practice 3: give policies their own list, and the blog the Optional section

Shipping, returns, warranty and contact pages answer the questions assistants are asked most about a store, so they deserve an H2 of their own near the top. The blog goes under the Optional heading, which the proposal describes as secondary information a reader can skip. That order tells any reader what matters.

## Shipping and policies

- [Shipping](https://example.com/shipping/): free over $75 in the US, 2 to 5 business days, flat $15 to Canada.
- [Returns](https://example.com/returns/): 30 days, unused, free return label.
- [Warranty](https://example.com/warranty/): 10 years on all cast iron.

## Optional

- [Blog: how to season carbon steel](https://example.com/blog/season-carbon-steel/)
- [Blog: cast iron vs carbon steel](https://example.com/blog/cast-iron-vs-carbon-steel/)

Best practice 4: leave out everything transactional and everything private

No cart, checkout, account, login, search results, tag archives, thank-you pages, admin URLs or staging domains. The file is public and anyone can read it. A URL in the file is an invitation to fetch it, and a staging link is a leak. This is the one practice that can cause harm if ignored.

Policies deserve one more thought. Shipping and returns are the two pages a shopper, or an assistant answering a shopper, asks about most. Put the key facts in the one-line description so the answer is in the file, not only behind the link: the free-shipping threshold, the delivery window, the return period. That is the single place where a few extra words earn their keep.

Also leave out pages that duplicate others: filtered category views, paginated archives, printer versions. The file is a curated list, and curation means leaving things out. Twenty to fifty links covers most stores. A 500-product catalog does not need 500 links. It needs its categories, its best sellers and its policies.

Best practice 5: keep it generated, keep it current, keep it out of the sitemap

Regenerate the file when the catalog changes, from the live catalog, so links never point to deleted products. Do not add it to your XML sitemap, which is for pages you want indexed in search, and do not block it in robots.txt, which would defeat the purpose. Note the date you generated it in the blockquote or a comment.

Why not the sitemap? The two files have different readers and different rules. A sitemap tells search crawlers which URLs exist and when they changed, and it should be complete. An llms.txt is a curated summary, and it should be short. Listing llms.txt in the sitemap asks Google to index a text file, which does nothing useful, and copying the sitemap into llms.txt destroys the curation. Keep each file to its own job, and keep robots.txt out of it entirely except to make sure it does not block the file.

A hand-maintained file drifts within weeks on an active store. The generator on this site builds the file from the details and pages you enter, and the AI visibility feature in StorePinger writes an llms.txt for the store from inside WordPress. Either way the rule is the same: if it cannot be regenerated in a minute, it will go stale.

Best practice 6: serve it as plain text at the root

The file should be reachable at https://yourstore.com/llms.txt, returned with a text content type, not redirected and not cached as an old version by a CDN. Open the URL in a private browser window after uploading. If you see your Markdown, it works. If you see a 404, a redirect to the home page or an HTML page, it does not.

The content type matters more than it looks. Some hosts serve .txt files with an HTML content type when a WordPress rewrite catches the request first, and the result is a 404 page with your Markdown nowhere in it. A quick check from a terminal is to request the URL with curl and read the headers: you want a 200 status and a text/plain or text/markdown type. If you do not use a terminal, the private-window test is enough, as long as you look at what came back rather than assuming.

WordPress sites hit a few specific problems here, from rewrite rules that treat unknown paths as pages to caching plugins that serve a stale copy. The placement guide walks through each one.

Best practice 7: measure AI visits, not the file

The only number that tells you whether AI visibility work is paying off is visits and orders from AI assistants. Track referrals from chatgpt.com, perplexity.ai, gemini.google.com and the rest, and match them to paid orders. If that number grows after you add the file, you still cannot credit the file, but if it never grows you know the file did not help.

Referrer tracking is the honest measure because it does not depend on the file. ChatGPT, Perplexity and Gemini send a referrer or a UTM parameter when a user clicks a link in an answer, and OpenAI documents separate user agents for its search crawler and for pages fetched on a user's behalf. Count those visits, count the orders they turn into, and you have a number that exists whether or not the llms.txt file is ever read.

A worked example, not a customer result. A store adds its llms.txt on the first of the month. In the previous month it had 400 visits from AI assistants and 12 orders from them. Three months later it has 520 visits and 15 orders. Over the same period total traffic grew 25%, so AI traffic grew in line with everything else. The file did not detectably change the share. That is the expected result today, and it is why the sales by source report, which names AI tools as a source, is the thing to watch rather than the file.

Which practices are guesses?

Anything about length limits, link order, "AI-friendly" wording, keyword use or Markdown copies of every page is a guess, because no consumer has published how it parses the file. The practices above are chosen so that the file is correct, safe and cheap whether or not a reader arrives. That is the only standard that can be met right now.

How to do it in WordPress in ten minutes

Generate the file from your store URL, read it once, delete anything transactional or stale, upload it to the root, open it in a private window, and set a reminder to regenerate it when the catalog changes. Ten minutes is the budget. If it takes longer, something is being hand-built that should not be.

1. Run a generator against your store's URL, or use the AI visibility screen in StorePinger to write the file from inside WordPress. Either produces the structure above in seconds.
2. Read the output. Check the H1 and blockquote say what you sell.
3. Delete any cart, checkout, account, search or archive URLs that slipped in.
4. Check that the policy pages are listed with their key facts and that the blog is under Optional.
5. Upload to the root as llms.txt, or let the plugin serve it.
6. Open https://yourstore.com/llms.txt in a private window and confirm you see plain text, not a page.
7. Note the date. Regenerate when you add or retire products.

If you run several stores, do the same for each and keep the files identical in structure, so a reader that does arrive finds the same shape every time. Agencies on the Agency plan can write the file from the AI visibility screen on each client site.

Common mistakes

• Dumping the sitemap into it. A list of every URL is not curation and is the file most generators produce by default.
• Including the privacy policy and terms. They are not what a shopper asks about. Shipping and returns are.
• Listing staging or admin URLs. The file is public.
• Letting it drift. Dead product links are the most common fault in files older than three months.
• Writing for keywords. No reader has been confirmed, so "optimising" the wording optimises for nobody.
• Blocking it in robots.txt. Seen more often than you would think, usually from a blanket rule on .txt files.
• Spending an afternoon on it. The expected return is near zero today. Spend the afternoon on product pages, which the what is llms.txt guide and every search guideline agree matter more.

Conclusion

The llms.txt best practices that hold up are the ones the proposal states and the ones that keep the file safe and cheap: an H1 and a two-sentence summary, categories as H2s with products and one-line descriptions, policies in their own list, the blog under Optional, nothing transactional or private, generated from the live catalog and served as plain text at the root. Everything about ideal length, wording and link order is a guess until an AI provider documents how it reads the file, and as of November 2026 none has. Make the file in ten minutes, then measure what actually moves: visits and orders from AI assistants, which StorePinger's AI visibility and sales by source reports count from inside WordPress.