Stall library · Evaluate
Price is not readable without running the page
A price stall happens when a product page has structured data but no price in it, so the number a shopper sees is produced by scripts at render time and does not exist in the document an AI agent reads. The agent is not comparing you badly on price. It has no price for you at all, and a product with no price loses to any product that has one.
Why the agent stops
Price is the single field an agent cannot proceed without, because almost every shopping instruction contains a budget, a comparison or a total. When the field is absent from both the markup and the delivered text, the agent has nothing to reason with.
The common cause is a currency or pricing app that rewrites the visible price in the browser while the JSON-LD is emitted with a placeholder, a zero, or no offers object. The page looks correct to every human who checks it, which is why this survives so long.
How often we see this
Not stated here. A frequency means nothing without the cohort it was counted over, and this page is about one stall rather than one category. Where a category has enough stores measured at every stage, the share of them showing this stall is published on its benchmark page, with the methodology beside it.
See it for yourself
- Fetch a product page with curl so scripts do not run.
- Search the response for the price you expect to see.
- Search for "application/ld+json" and read the offers object. Check price and priceCurrency are present and correct.
- Repeat on a product that is on sale, and on one in a second currency if you run multi currency pricing. Those are the cases that break first.
What to change
- Emit offers.price and offers.priceCurrency in the server rendered markup for every product.
- If a pricing app rewrites prices client side, make it also rewrite the structured data, or render the correct price server side.
- For sale prices, put the price the shopper pays in offers.price. A struck through original belongs elsewhere.
- Check multi currency and market specific pricing separately. Each variant of the page needs its own correct value.
What Ottom looks at
Ottom counts, among the product pages that did carry structured data, how many expose no price in it, and names the count and an example URL in the finding. Your catalogue is checked as well, so a product priced in the feed but not in the page markup is not reported. Both the single offer and the price range forms of the markup are read, and so is a price stated on each variant rather than on the product. Pages we could not read at all are excluded, because an unreadable page is evidence about access rather than about pricing. A price published only in Open Graph meta tags is not read, and that gap is on our list to close.
Questions
Why is my price reported missing when it shows on the page?
Visible and readable are different tests. This finding is about the document as delivered, before scripts run. If the number arrives only after client side execution, an agent reading the response does not have it.
Does a price range count as price data for agents?
A range is better than nothing, and for a product with genuinely varied variants an AggregateOffer is correct. A single price per purchasable variant is stronger, because it lets an agent answer about the specific thing the shopper asked for.