Review snippet schema audit work needs one clear answer to a simple question: what exactly is being reviewed? On 12 November 2026, Google clarified its review snippet documentation to discourage site owners from indicating the reviewed entity in multiple ways. The aim is to reduce ambiguity when Google interprets Review and AggregateRating structured data.
The practical rule is straightforward. If a review or aggregate rating is nested under a parent item through its review or aggregateRating property, omit itemReviewed inside the nested object. If the review stands alone, use itemReviewed to identify the supported entity. Do not use both approaches for the same relationship.
What Google clarified
Google’s Search documentation update log says the review snippet guidance was clarified to prevent multiple ways of indicating what is being reviewed. The change is a documentation clarification, not a promise that previously ambiguous markup will immediately lose or gain stars.
The current review snippet documentation describes two valid patterns. A standalone Review or AggregateRating can carry itemReviewed. Alternatively, a parent entity such as a Product, Recipe or SoftwareApplication can contain the review or rating through a nested property.
In the nested pattern, Google assumes the parent is the reviewed item. Repeating that entity inside itemReviewed creates a second path that can be inconsistent, duplicated or harder to interpret. The parent still needs a clear name.
Markup pattern
How to identify the reviewed item
Common audit finding
Standalone Review
Use a supported type in itemReviewed, including its name.
The reviewed entity is missing or uses an unsupported type.
Review nested under a parent
Use the parent’s review property and omit nested itemReviewed.
The same product is declared again inside the review.
Standalone AggregateRating
Use itemReviewed plus rating value and count fields.
The count is missing or does not match visible content.
Rating nested under a parent
Use the parent’s aggregateRating property and omit itemReviewed.
A plugin outputs two competing reviewed-item paths.
Why ambiguous nesting happens
Most conflicts are created by templates, plugins or tag-management layers rather than by someone writing JSON-LD manually. An ecommerce theme may output a Product with nested ratings while a review application adds a second standalone graph. A custom script may then copy itemReviewed into every review object.
Multiple scripts are not automatically wrong. Google can understand several items on a page when their relationships and content are accurate. The problem is conflicting identification: different names, URLs, identifiers, rating values or counts for what appears to be the same item.
Structured data must also match the visible page. Kayaar’s Google content-quality guidance review explains why accurate metadata and schema matter alongside body content. Markup cannot create review evidence that users cannot see.
A practical review snippet schema audit
1. Choose representative pages. Sample each template that displays ratings: product, recipe, software, course or editorial review pages. Include pages with no reviews, one review and several reviews. Do not test only the homepage or one ideal product.
2. Inspect rendered markup. View the final DOM and collect every JSON-LD, Microdata and RDFa item. Server output, client-side scripts and third-party widgets can all contribute. Kayaar’s 60-minute website SEO audit provides a useful broader sequence for technical checks.
3. Draw the entity relationship. Identify the primary item and trace how each Review and AggregateRating connects to it. Decide whether the implementation uses a standalone or nested pattern. A quick diagram is often clearer than reading a large graph line by line.
4. Remove the duplicate path. When a review sits under a parent’s review property, remove its itemReviewed. When an aggregate rating sits under aggregateRating, remove its itemReviewed. Keep the parent type, name and required properties complete.
5. Reconcile values. Compare item names, canonical URLs, product identifiers, rating values, best and worst scales, ratingCount and reviewCount. At least one relevant count is required for an aggregate rating. Use a dot for decimal values in structured data.
6. Check visible evidence. Users should be able to see the review text and rating represented by the markup. Ratings must relate to a specific item, not a category or list. Do not aggregate ratings copied from other websites or hide negative reviews from the marked-up total.
7. Validate and monitor. Test the live URL in Google’s Rich Results Test, inspect Search Console enhancement reports and recheck after template releases. A valid result confirms syntax and supported fields; it does not guarantee a rich result.
Make the correction safely
Fix the source that owns the markup instead of deleting output from the browser after it renders. That source may be a theme template, ecommerce platform, review plugin or tag-manager container. Record which component controls each property so a later update does not restore the conflict.
Deploy the change to staging first and test pages with different review states. Compare the visible rating, raw HTML, rendered DOM and validation result before and after the release. Keep a rollback path, then monitor production URLs for unexpected missing fields, duplicated graphs or changed counts. If a vendor owns the integration, give it a reproducible example rather than applying a fragile site-wide override.
Important policy checks beyond nesting
For LocalBusiness and Organization, self-serving reviews are ineligible for the star review feature when the reviewed entity controls the reviews about itself. Embedding third-party reviews on the business’s own pages does not bypass that rule.
Review authors need valid names, and incentivised reviews must be clearly disclosed. The rating scale should be explicit when it is not the default one-to-five range. If several individual reviews appear, include an aggregate that represents them accurately.
Schema also needs to coexist cleanly with other page entities. Kayaar’s VideoObject audit guide and preferred-image SEO audit show how to validate related structured signals without treating markup as a ranking shortcut.
Deployment checklist
Use one reviewed-item relationship for each review or aggregate rating.
Keep the parent type and name complete when nesting.
Match rating values and counts to visible content.
Test every template and third-party review widget.
Document plugin ownership and regression tests.
Monitor Search Console without assuming stars are guaranteed.
For help auditing templates or resolving conflicting schema output, contact Kayaar with example URLs and the platform used. Never share administrator credentials through an unsecured form.
FAQs
What did Google clarify about review snippet nesting?
Google clarified that site owners should avoid multiple ways of identifying the reviewed item because conflicting relationships can create ambiguity.
Should a nested review include itemReviewed?
No. When a review is nested under a parent’s review property, omit itemReviewed because the parent is assumed to be the reviewed item.
When is itemReviewed required?
Use itemReviewed for a standalone Review or AggregateRating that is not already nested under the entity being reviewed.
Does valid review schema guarantee stars in Google?
No. Valid structured data can establish eligibility, but Google does not guarantee that a review rich result will appear.
Can a business mark up reviews about itself?
Self-serving LocalBusiness and Organization reviews are ineligible for Google’s star review feature when the reviewed entity controls them.
