Does the schema markup for reviews really need to be limited to product pages?

Why does Google impose this restriction on category pages?

Google's logic relies on the consistency between displayed content and declared markup. When a user sees stars in the SERPs for "best smartphones 2023," they expect to read a review of a specific product, not a comparison of 15 models.

If the aggregate rating schema markup appears on a category page, Google cannot determine which product is being rated. The search engine then considers the markup misleading or irrelevant. The result: deindexing of the rich snippet, or even manual action if the abuse is systematic.

What exactly is an application error?

A classic error: marking up an e-commerce category page with a global AggregateRating calculated based on all products in the category. Google detects the inconsistency between the markup (which claims a single rated product) and the actual content (which lists 50 items).

Another problematic case: comparative pages like "iPhone 15 vs Samsung Galaxy S23". Even if two distinct reviews are present, the schema.org Product markup cannot declare two entities on the same URL without creating structural confusion.

Are comparative pages completely excluded from schema markup?

Technically, you can mark up each product individually with its own Product + Review block. However, Google is unlikely to display stars in the SERPs for a URL that does not clearly represent a single identifiable item.

The distinction is subtle: the markup may be valid from a syntactic point of view, but Google deems it ineligible for rich snippets. Search Console may not signal an error, but you will never see your stars appear.

• The Review schema must point to a single identifiable entity (a product, a service, a recipe)
• Category pages do not meet this criterion, even if they aggregate reviews of individual products
• Multi-product comparisons create a structural ambiguity that Google refuses to display as rich snippets
• Technically valid ≠ eligible for enhanced display: Search Console can validate a markup that Google will ignore in the SERPs
• Google's goal: to prevent users from clicking on an enhanced result that does not exactly match their intent

Is Google's stance consistent with real-world practices?

Let’s be honest: most e-commerce sites try to circumvent this rule. Many display aggregated stars on category pages, hoping Google will overlook it. And sometimes, it works temporarily.

However, since recent updates to the rich snippets detection algorithm, Google has been massively deindexing these non-compliant rich displays. SEO audits often reveal dozens of URLs with valid markup but zero display in the SERPs. [To be verified]: Google does not publicly communicate about the rejection rate of schema markup, but field observations suggest a clear tightening.

What nuances should be added to this directive?

The first point: Google allows BreadcrumbList and Organization markup on any page, including categories. The restriction specifically concerns Review, Rating, and AggregateRating. Do not confuse the types of schema.

The second nuance: some sites manage to display stars on highly targeted "hub" pages (e.g., "Reviews of the 2023 MacBook Pro 14 inches") that are technically not product sheets. The key? The page content must be perceived by Google as a unique entity, even if it aggregates multiple sources of reviews. This is tricky.

When does this rule not apply strictly?

Editorial or niche sites can sometimes succeed with "full-test" pages that aggregate reviews but are structured like a unique editorial review. If the markup points to an Article with an embedded Review rather than a Product, Google may accept it.

Another observed exception: single-product brand pages. If your category "iPhone 15" only lists variants of the same product (128GB, 256GB, etc.), Google may interpret this as a single item with variations. But it's fragile and not guaranteed.

What practical steps should be taken to remain compliant?

Audit your current pages marked up with Review or AggregateRating. Use the "Enhancements" report in Search Console, under Product Reviews, to identify errors. If category pages appear with warnings, remove the markup.

Next, reserve the Review schema solely for individual product sheets. Even if you have 500 variants of a product, each unique URL must have its own distinct schema block. No pooling, no cross-product aggregation.

What mistakes should be absolutely avoided?

A classic mistake: marking up a category page with an AggregateRating calculated on all listed products. You thought to optimize your CTR in the SERP, but Google detects the inconsistency and neutralizes the rich display. Worse: if the abuse is repeated across hundreds of pages, you risk manual action.

Another trap: displaying stars on a comparative page without clarifying in the markup which product is rated. Even with two distinct Product blocks, Google may refuse to display the rich snippets if the main URL does not have a clear unique focus.

How do I check that my implementation is recognized correctly?

Use the Google Rich Results Test, but don’t stop there. A technically validated markup can still be ignored in production. Check in Search Console for actual impressions with rich display (using the "Search result type" filter in the Performance report).

Compare the click-through rates on marked versus unmarked product pages. If the CTR does not increase despite validated markup, it’s likely that Google is not displaying your stars. Test with incognito search using targeted queries for visual confirmation.

• Remove all Review/Rating schema from category and multi-product comparative pages
• Ensure that each product page has a unique Product markup with its own AggregateRating
• Audit Search Console to detect schema errors reported by Google
• Test the actual display of rich snippets in incognito search using targeted product queries
• Monitor the CTR of marked product pages to measure the concrete impact of schema markup
• Avoid cross-product review aggregations even if the JSON-LD is technically valid