Problem
Product rich results not showing: how to fix it
Rich results are earned, not switched on. The page has to be indexed, the markup has to be valid, the values in it have to match what a shopper sees, and even then presentation is decided by Google for each query. Work through eligibility in that order. Most stores find the problem is a mismatch between the markup and the visible page, or two conflicting blocks of markup added by different apps.
By CartKernel · Last reviewed 2026-09-07
Does this look familiar?
- Product results appear as plain blue links with no price, availability or ratings
- The enhancement report lists errors or warnings on product pages
- Validation tools report the item as detected but not eligible for the rich result
- Ratings show for some products and not for others with the same template
- Rich results appeared and then stopped after an app install or a theme change
- The markup looks correct in the page source but is missing from the rendered page
Causes, ranked
Why it happens, most common first
Check them in this order. The first two account for most cases we open.
- most common
Required properties are missing or malformed
A product needs a name, an image, and offer information with a price and a currency, with availability stated in the form the specification expects. Prices written with symbols, currencies omitted, or availability given as free text rather than a defined value all make the item ineligible.
- most common
Markup values do not match the visible page
Structured data has to describe what the shopper can see. A price in the markup that differs from the displayed price, a rating with no reviews on the page, or availability that contradicts the stock message will disqualify the page and can be treated as misleading.
- common
Several sources add conflicting markup
The theme, a review app, a feed app and a structured data plugin can each add their own product block. Multiple items on one page with different prices or different identifiers leave Google unable to decide which describes the product, so it uses none of them.
- common
The page is not indexed or not eligible
Structured data does nothing on a page excluded by a directive, canonicalised elsewhere or never crawled. Variant pages canonicalised to a parent will not show their own rich result, which surprises stores that added markup to every variant.
- occasional
Markup is added by script and not rendered in time
Structured data injected by a client side script may not be present when the page is processed. On headless builds and script heavy themes this produces markup that validates in a browser and is absent from what Google sees.
- occasional
Ratings do not qualify
Review markup needs genuine reviews visible on the page, with a rating value inside the scale declared. Aggregated ratings pulled from another site, ratings with no review count, or ratings on a page with no reviews shown will not produce stars.
The fix
In this order
Each step is something you can do today. Do them in sequence; skipping ahead is how a review fails twice.
Prevent it next time
- Generate structured data from the same fields that render the visible page, never separately
- Check the rich results test after installing any app that touches product pages
- Keep one owner for structured data so a second source cannot be added quietly
- Review the enhancement report monthly and treat new errors as a release defect
Test the rendered page, not the source
Run the product address through the rich results test and the inspection tool's live test, and read what is detected in the rendered output. If the markup is absent there, the problem is rendering rather than the markup itself.
Fix every error before looking at warnings
Errors make an item ineligible; warnings usually reduce how much detail can be shown. Clear the errors first, then work through warnings such as missing identifiers, brand, or shipping and returns details that enrich the result.
Reduce to one source of product markup
Identify every app, snippet and theme file adding product structured data, and keep exactly one. Where a review app must supply ratings, have it extend the single product item rather than emitting a second one.
Align every value with the visible page
Confirm the price, currency, availability, product name and image in the markup are generated from the same data the page displays, including when a variant is selected. Never hardcode values that can change.
Use the correct availability and price formats
Express availability using the defined values rather than free text, give the price as a plain number with a separate currency code, and include a price validity date where the price is a promotion with an end date.
Render the markup server side
Emit the structured data in the initial HTML response rather than adding it with a script after load. On headless builds, generate it during rendering so it is present in the first response for every product address.
Make ratings legitimate and visible
Show the reviews on the page they are marked up on, include the review count and the rating scale, and only mark up reviews collected for that product. Remove aggregate ratings that cannot be seen by the visitor.
Validate at scale and wait for recrawling
Crawl the site to confirm every product template emits one valid item, then monitor the enhancement report over the following weeks. Appearance is decided per query, so expect gradual and uneven improvement rather than a switch flipping.
When to get help
It is worth getting help when the store runs a headless front end, when several apps each insist on adding their own markup, or when merchant listing details such as shipping and returns need to be represented consistently across markup and the product feed. Those cases need the data model sorted out once so the page, the markup and the feed all describe the same product. Note that valid markup makes a page eligible for richer presentation and never entitles it to appear that way.
Free. We reply within one business day.
Does valid structured data mean my product will show a rich result?
No. Valid markup makes the page eligible. Whether the richer presentation appears is decided per query and per result, based on relevance, the type of search and how the results page is composed. Treat eligibility as the goal and appearance as an outcome you influence rather than control.
Should each variant page carry its own product markup?
Only where each variant has its own indexed page with its own price and availability. Where variants are selected on a single page, mark up the product once and reflect the selected variant's values, or use the structure the specification provides for describing a group of variants.
Can I mark up a rating collected on another website?
Ratings must come from reviews that are visible on the page carrying the markup. Ratings gathered elsewhere and shown only as a number will not qualify and can cause the enhancement to be disallowed for the site. Import the reviews and display them, or leave the rating out.
How long after fixing errors do rich results return?
The page has to be recrawled and reprocessed first, which takes days to weeks depending on how often the page is crawled. The enhancement report updates on its own schedule after that. If nothing changes after a month, retest the live page rather than assuming a delay.
Services that fix it for good
Related problems, answers and terms
Stop the leak.
A free Growth Analysis finds what is broken and ranks it by the revenue it costs you.