The core challenge is that Google’s review-snippet and general structured data guidelines require the aggregateRating value in your markup to be substantiated by genuine review content Google can verify, either directly visible on the page or through a documented, verifiable relationship with a legitimate third-party review source. When a product’s aggregate rating is compiled from multiple platforms (your own site’s reviews plus third-party marketplaces, review aggregators, or syndicated feedback) and the number marked up in your schema diverges from what Google can actually confirm by reading the page itself, the typical documented consequence is that Google suppresses the rich result display rather than showing the mismatched figure. The rating doesn’t get “corrected” or averaged by Google, it simply tends not to display.
Why this happens mechanically
Google’s structured data guidelines establish a content-match requirement that applies across all schema types: markup has to accurately represent what’s actually present and verifiable on the page. For aggregateRating specifically, this means the numeric rating and review count in your JSON-LD need to correspond to reviews Google can actually find and verify, typically by seeing individual review content rendered on the page itself, or through Google’s own established, documented aggregation relationships with certain third-party review platforms it explicitly recognizes.
When a business calculates its displayed aggregate rating by blending its own on-site reviews with ratings pulled from other platforms (a marketplace listing’s separate review pool, a syndicated third-party review widget, an aggregator service), the blended number is a real, honestly-computed figure from the business’s own perspective, but it may not correspond to what Google’s crawler can independently verify by reading that specific page. If Google’s parser sees, say, 40 individual reviews rendered on the page averaging to one number, but the aggregateRating property states a different number reflecting the broader multi-platform blend, that’s exactly the kind of divergence between marked-up data and page-verifiable content the guidelines are built to catch, and Google’s documented response pattern to this kind of mismatch is non-display rather than displaying the higher-level, less-verifiable figure.
Why suppression, not display of an inaccurate figure, is the expected outcome
This matters as a distinct point from simple validation failure: syntactically valid, well-formed aggregateRating markup that simply doesn’t match what’s verifiable on the page isn’t a case of “broken schema” in the technical sense, the JSON-LD may pass the Rich Results Test with no structural errors at all. The failure is at the content-match layer, not the syntax layer, and Google’s documented handling of content-match violations for review data specifically tends toward not displaying the rich result rather than displaying a rating Google can’t independently substantiate. This is consistent with the general principle across Google’s structured data guidelines that markup accuracy, not just markup validity, determines whether a rich result actually shows.
A hypothetical illustration of the divergence
Consider a hypothetical kitchen-appliance brand, “Copperfield Kitchenware,” whose product page displays 40 on-site reviews averaging 4.2 stars, but whose aggregateRating markup reports 4.6 stars, a figure calculated by blending those on-site reviews with review data pulled from a marketplace listing and a syndicated aggregator feed. Google’s crawler, reading only what’s verifiable on that specific page, sees 40 reviews averaging 4.2, a number that doesn’t match the 4.6 asserted in the schema. In this scenario the rich result would plausibly simply stop displaying rather than showing either number, since the mismatch itself, not which figure is “more right,” is what triggers suppression. Rebuilding the aggregateRating generation logic to pull directly from the same 40 on-site reviews rendered on the page, rather than the broader cross-platform blend, would likely restore eligibility without requiring the business to stop calculating or displaying its broader blended rating elsewhere for its own purposes.
Reconciliation guidance for multi-platform aggregation
Mark up only the rating that corresponds to what’s actually verifiable on that specific page. If the page displays a specific set of reviews, the aggregateRating should reflect those specific reviews, not a broader cross-platform blend that isn’t independently visible or verifiable at that URL. If you want to represent a broader, multi-platform aggregate somewhere, that’s a legitimate business decision for how you display information to users, but it shouldn’t be the number in the structured data unless it’s the number actually substantiated by content Google can see on that page.
Where third-party review platforms are involved, understand Google’s actual documented relationships with those platforms rather than assuming any third-party aggregation automatically qualifies. Google’s review snippet guidelines describe specific conditions for legitimately sourcing aggregate data from third-party providers; not every third-party review widget or aggregator automatically satisfies these conditions, and assuming it does without checking is a common source of exactly this divergence problem.
Keep the on-page display and the structured data in sync as a matter of ongoing process, not a one-time setup. Multi-platform aggregation is often dynamic (new reviews arriving continuously across different sources), and a reconciliation approach that was accurate at implementation time can drift out of sync as review counts and averages shift independently across platforms. Building the aggregateRating generation directly from the same data source and calculation logic that produces the on-page display, rather than as a separately maintained figure, is the most reliable way to prevent this drift from recurring.
When in doubt, mark up conservatively. If there’s genuine uncertainty about whether a given multi-platform aggregate can be substantiated by what’s verifiable on a specific page, understating (or omitting the aggregateRating rather than asserting a number that might not hold up) is the safer path, since the downside of a suppressed rich result is smaller than the downside of a schema implementation Google’s systems repeatedly flag as inconsistent with page content across many product pages site-wide.
