How to fix AI readability on WooCommerce

WooCommerce hands you the whole shop, which also means it hands you every decision. Whether an AI assistant can read your products is settled by your theme, your plugins and a handful of product fields, not by WooCommerce alone. Here is what to check, in the order that matters.

1. Let the readers in before you change anything else

You can do this. This is our robots.txt rule check, worth 26 points. A passing result means we found no blocking rule for the tracked visitor names. It does not prove that your host or security service lets those visitors through.

WordPress usually does not keep a real visitor-rules file on your server. When someone asks for yourstore.com/robots.txt, WordPress writes the answer fresh. If a person did put a real file there, that file wins instead. So the rules you are about to read may come from WordPress, from a plugin you installed for something else, or from a file a developer added years ago.

Open the address in your browser and read it. Look for visitor names such as GPTBot, ClaudeBot and PerplexityBot, and for the word Disallow next to them.

Then the part that file will not tell you. A security plugin, or a rule at your host, can turn a visitor away before WordPress ever runs, and nothing in your admin records it. If your file looks clean and AI tools still cannot reach you, ask your host one question: what does your bot protection do with visitors it does not recognise?

2. Confirm your theme still prints the product facts

Developer needed. This is our Product details check, worth 19 points. You can find the problem yourself in two minutes; fixing it is a developer job.

WooCommerce writes a second copy of each product, one that states the price, the stock status and the rest in a plain, predictable form that software can read. Here is the part that matters on this platform: WooCommerce builds that copy while it draws its own standard product summary area, then prints the result right at the end of the page.

The Product details check looks for the name, description, image, price, stock status, one product code, and any real review or rating data. Never add a made-up review. Under the current rule, a product with no real reviews can reach Needs work but not Good.

In a classic theme, skipping WooCommerce’s standard product-summary hook can prevent its default product entry from being built. Old template overrides are another possible cause. A developer should inspect the rendered page, restore the required hook or update the affected overrides, then test simple, variable, and sale products. The number of files depends on the theme.

3. Sizes and colours are where WooCommerce gets thin

Developer needed. Still the Product details check, and the place WooCommerce stores lose the most ground.

A variable product is WooCommerce's way of selling one item in several sizes or colours. Each option can carry its own price, its own stock count, its own code and its own image. On the page it works beautifully. A shopper picks a size, the price updates.

On the main variable-product page, WooCommerce normally publishes one product entry with an overall price or price range, not a separate entry for every option. Current versions can publish an exact price and stock status when the address selects one complete variation, but the main page still does not list every variation separately.

One more thing. Once a product goes past thirty options, the size and colour choosers stop narrowing themselves to combinations you really sell, so a shopper can pick a pair that does not exist and be told nothing matched.

Our report says this out loud rather than grading it. On a WooCommerce store we sample one product page, tell you whether it was a variable product, and count how many of its listed options carried their own price and stock. That count is information, not a mark against you.

Ask a developer to review what each variation publishes. Do not split products only to change this information finding. The finding is not scored.

4. Fill in the fields only you can fill in

You can do this. Product details again, and this part costs nothing but attention.

The Product details check accepts a GTIN, MPN, or SKU. If the product has a retail barcode, enter it in the GTIN, UPC, EAN, or ISBN field. If it does not, give it a useful SKU. WooCommerce’s default product entry uses the short description when one exists and falls back to the long description.

Manual check. This does not affect the scored Product details check. Review Catalog visibility separately so published products are not accidentally hidden from both the shop and store search.

5. Put the answers in words, on the page

You can do this. Our Answers on the page check passes when the homepage or sampled product page publishes a question-and-answer entry in a form software can read. Without that, it can only spot two or more question-style headings on the homepage, which earns Needs work. Ordinary product tabs do not change this check, though clear delivery, returns, materials, and sizing text still helps shoppers.

Not what this scored check measures.

A WooCommerce product page can show a Description section, an Additional information section and Reviews. An older theme lays them out as tabs; a newer block theme can show the same content as a product details block or an accordion.

Two traps. The Additional information section only appears when the product has attributes, weight or dimensions to show, and an attribute only shows when you tick the box that makes it visible on the product page. So a fabric or a size chart you carefully entered may never be published. Go and tick it.

The second trap is common everywhere. A sizing chart saved as a picture is not an answer. Software reads words. Type the measurements out underneath the image, along with what the thing is made of, how long delivery takes, and how returns work.

6. The two small files, and how fast the page arrives

You can do this. The speed result may need a developer.

Three checks here: your shop summary file, llms.txt, worth 13 points, your page list, sitemap.xml, worth 5, and page speed, worth 8.

Our check fetches yourstore.com/llms.txt. It fails if the address is missing or returns a normal HTML page. It passes only when the body contains at least one Markdown heading beginning with # and one link in [label](address) form. It does not check whether the list is complete or whether any AI tool uses it.

It is not a WooCommerce feature, and nothing in your admin creates one, though some search plugins have started to. It is a new idea and still unsettled, so treat it as a small tidy job once the first five steps are done.

WordPress normally publishes /wp-sitemap.xml on a public site. Our scored check tries /sitemap.xml and any sitemap address listed in robots.txt, then checks that it is a valid page list with at least one address. It does not confirm that products are included. Open the product section yourself for that manual check.

Our page-speed check tests the store’s main address with Google’s mobile test. It measures when the largest visible content block appears. It does not test the sampled product page.

What this does not do

None of this makes an assistant mention your shop. It makes your shop readable, and readable is the part you control. Whether anything then uses what it read depends on the assistant, on the question a shopper typed, and on a great deal neither of us can see.

There is a limit worth naming too. Our scan samples one product page, not your catalogue. A store with two thousand products can pass on the page we read and fail on the rest, so take the result as a starting point and go and look at a variable product yourself.

What we can tell you is what was true about your store on the day we looked, and what to change.

Related playbooks