Why your prices might be invisible to AI shopping tools
A price a shopper can see is not always a price software can read. Here is where that gap comes from on a product page, and how to close it for good.
Your product page shows the price in large, confident type. It shows the size options, the delivery estimate, and a green line saying the item is in stock. An AI shopping tool fetches that exact address and comes away without a price at all.
Nothing is broken. The page is fine, the shopper is fine, and your admin screen has nothing to report. What has happened is that your page publishes its facts in one form and not the other, and the form it skipped is the one software reads.
Two ways a price can exist on a page
The first way is visual. The number sits in the layout, styled to catch the eye, and a person finds it without thinking. This is the part every theme gets right, because it is the part anyone would notice if it broke.
The second way is written for machines. The price, the currency, the stock status, and the rest of the product's details are stated in a plain, predictable shape inside the page, so that a program can pick them out without guessing. Google's product guidance documents this approach for Search and shopping results. That distinction matters more than it sounds. A product page can easily show four numbers, and a program looking only at the surrounding text may struggle to tell the price from the shipping cost, the old crossed-out price, or the finance-per-month figure.
The two forms are meant to sit side by side. A shopper still sees your styled price. The same figure is also stated plainly underneath, where software can read it without interpreting anything.
Why the second form goes missing
A theme is built to look good and sell well, and it is usually judged on how it looks in a browser. The readable form is invisible, so a theme can skip it entirely, or publish half of it, and no one reviewing the design would ever spot the difference.
The result is a page that carries the product name and a picture in readable form, while the price, the stock status, or the product code are only present visually. To a shopper that page is complete. To a program it is a name and a photograph with no commercial facts attached.
What a complete entry answers
When a product page publishes properly, a program reading it can answer a short list of basic questions without guessing at any of them.
What is this item called. How is it described. Is there a picture. What does it cost, and in what currency. Is it in stock right now. What is its product code, meaning the number that identifies the item, such as a barcode number or your own stock code. Has anyone rated it.
That is the list our scan checks on the product page it finds. Current product guidance from Google uses many of the same details, including price, currency, stock status, product codes, images, and ratings. Other shopping tools may use different inputs, including product feeds or a rendered page, so this is a useful baseline rather than a universal rule.
One missing piece is not a small problem
It would be reasonable to assume that six answers out of seven leaves you mostly fine. It often does not work that way. A product with a name, a description, a picture, and no price cannot support a confident price claim. Some shopping displays also require an offer price before the product is eligible to appear in that format. Missing one key fact can therefore matter more than the raw count suggests.
Three of the seven carry most of that weight. A price added only after the page arrives can be missed by an automated visitor that does not run the page's own program. Google can process page scripts, but still recommends putting product details in the first page response for the most reliable shopping results. A stock status shown only as a coloured line of text leaves software with less reliable information about whether the item can be bought. Product codes can also be complete on some items and missing on others, leaving a catalogue partly complete rather than uniformly complete.
None of these are content problems. Your descriptions can be excellent and your photography can be beautiful, and the page can still hand a program nothing usable, because the specific facts it looks for are not stated in the form it reads.
Catalogue size does not predict this either. A ten-product store on a current theme may publish every detail correctly out of the box, while a catalogue built up over years, across a few themes and a handful of plugins, can be complete on some products and thin on others, simply because the pieces were assembled at different times by different tools.
Check your own store
The reliable way to know is to look at what a program actually receives from your product pages, rather than at what your browser draws. SchemaCart's free scan finds a product page on your store, reads it without running the page's own scripts, and reports plainly which of those seven details are present and which are missing. It is one of the five AI checks in the scan and carries nineteen of its hundred points, which is the second largest single weight in the score. It takes about a minute and needs only your store's web address.
Fixing it on WooCommerce
WooCommerce itself produces a baseline product entry for software to read. The theme calls the part of WooCommerce that adds it, and a custom theme or plugin can change or remove that call. If a scan shows the price or stock status missing, first confirm that WooCommerce's own output is still present and that another plugin is not replacing it. WooCommerce's current code reference documents the built-in product generator.
The good news is in how an output fix applies. If the facts already exist in your product records and the page simply fails to publish them, correcting the shared output can correct every affected product at once, including the ones you add next year. Facts that are missing from the product record, such as an item code nobody entered, still need to be added to those products.
Fixing it on Shopify
Themes accepted into Shopify's Theme Store must include Google's rich product results, and Shopify provides a built-in tool that turns a product record into the required product entry. A store using one of those themes therefore starts with a baseline version of these details. A custom theme still needs to preserve that output. Shopify's theme requirements and its built-in product output document both parts.
The gaps that remain on Shopify stores usually point somewhere specific. A heavily customised theme, or a theme built from scratch, may have replaced the default product template and dropped part of it. A currency or availability setting can also end up stating something different from what the page shows a shopper, which is worse than silence, because software then reads a confident wrong answer. If a scan shows a gap on a Shopify store, a recent theme change is the first place to look.
What to do with the result
Take the price and the stock status first. They are the two facts that decide whether anything can describe your item as available to buy, and everything else is secondary to that.
Fix them in the template rather than product by product, then run the scan again to confirm the change landed. Reading the report is not the same as seeing the fix take effect.
Then treat it as a recurring check rather than a finished task. A theme update, a new plugin, or a redesign can reopen the same gap without anyone mentioning it.
None of this changes how your page looks to a shopper. It changes whether software reading that page can tell what you sell, for how much, and whether you have it. That is the starting condition, and it is the part you actually control.
See what your own product pages hand over today. Run the free scan at SchemaCart, no card and no signup.