What Is Review Schema?
The Review type represents one evaluation. Rating describes its numeric scale and value. AggregateRating summarizes a real collection of ratings for an item when the site can show and substantiate the count and average. The reviewed item might be a product, book, recipe, movie, software application or another currently supported entity.
Review markup is not permission to create stars for a business. It should reflect actual review evidence, visible to users, with an identifiable subject and honest methodology. Eligibility for a review snippet does not guarantee stars, rankings or clicks.
- Frame the decision raised by What Is Review Schema.
- Confirm its value type and the object it describes.
- Compare the markup with visible page information.
- Correct the source data or template without inventing values.
- Validate the rendered result and monitor future changes.
| Entity or property | Represents | Required truth |
|---|---|---|
| Review | One person or organization evaluation | Actual visible review |
| Rating | Numeric evaluation | Defined value and scale |
| AggregateRating | Summary of many ratings | Real count and average |
| itemReviewed | Subject of evaluation | Exact visible entity |
| author | Reviewer identity | Genuine attributable reviewer |
| reviewBody | Written assessment | Visible review content |
| datePublished | Original review date | Accurate publication record |
- Mark up settled review evidence only.
- Identify the exact reviewed item.
- Keep ratings and counts synchronized.
Review schema is a machine-readable account of real review evidence, not a promotional rating generator.
The decision for What Is Review Schema should rest on live, traceable evidence and a verified follow-up check.
How Does Review Schema Work?
A parser extracts the graph and identifies the subject through itemReviewed or a nested relationship from that item. It interprets the score in context of bestRating and worstRating when those are provided. An aggregate adds the average and count for the eligible review collection.
A consumer then applies its current supported-type, content and policy rules. It may compare the structured values with the visible page. Syntax validity is only the first layer. The page can still be ineligible because the reviewed type is unsupported, the content is hidden, or the rating is self-serving or unverifiable.
- Evidence for How Does Review Schema Work: the live structured-data entity and property relationship
- The expected value type and any nested object
- Visible page information that supports the structured value
- Related offer or catalog fields needed for interpretation
- A fresh validation result after the page changes
| Stage | Data action | Failure example |
|---|---|---|
| Identify item | Connect exact reviewed entity | Rating attaches to wrong variant |
| Create review | Record author and content | Anonymous fabricated quote |
| Define rating | Set value and scale | 4 interpreted without scale context |
| Aggregate | Calculate count and average | Old deleted reviews remain |
| Render | Show evidence visibly | JSON-LD contains hidden score |
| Validate | Check type and feature rules | Unsupported itemReviewed type |
| Observe | Measure live appearance | Eligibility mistaken for guaranteed stars |
- Define the reviewed entity.
- Select genuine eligible reviews.
- Calculate ratings from settled data.
- Render and validate the same evidence.
The process is identify the subject, attach real review evidence, define the scale and validate visible parity and current eligibility.
The decision for How Does Review Schema Work should rest on live, traceable evidence and a verified follow-up check.
Review vs Rating and AggregateRating
A written review can include author, date, body and a nested Rating. A Rating alone states a score but does not provide the complete assessment context. AggregateRating belongs on the reviewed item and should state values such as ratingValue plus the applicable review or rating count.
Do not mix reviewCount and ratingCount without understanding the underlying data. Some users may leave a numeric rating without text, while others write a review. The average must be calculated from the same visible eligible population and scale that the page communicates.
- Frame the decision raised by Review vs Rating and AggregateRating.
- Confirm its value type and the object it describes.
- Compare the markup with visible page information.
- Correct the source data or template without inventing values.
- Validate the rendered result and monitor future changes.
| Type | Scope | Typical fields | Common misuse |
|---|---|---|---|
| Review | One assessment | author, body, date, reviewRating | Marketing testimonial labeled review |
| Rating | One numeric evaluation | ratingValue, bestRating, worstRating | Scale omitted or changed |
| AggregateRating | Summary population | ratingValue, ratingCount or reviewCount | Count includes unrelated items |
| Product | Reviewed item | name, SKU and offers | Seller rating attached as product rating |
| Organization | Business entity | name and identity | Self-created reputation stars |
| Person | Reviewer or reviewed person where valid | name and ID | Invented reviewer identity |
- Keep score and review concepts distinct.
- Declare a consistent rating scale.
- Aggregate one clearly defined population.
Use Review for one assessment, Rating for its score and AggregateRating only for a real, consistently calculated population.
The decision for Review vs Rating and AggregateRating should rest on live, traceable evidence and a verified follow-up check.
Which Reviews Are Eligible for Markup?
Product customer reviews, editorial reviews of a product or work, recipe evaluations and other supported review contexts can be candidates. The reviewed entity should be the main subject of the page or clearly represented. A general testimonial about the company should not be relabeled as a review of every product.
Current rich-result support covers only selected entity types and can change. Schema.org may define a relationship that a particular search feature does not use. Check current eligibility when implementing, but keep the durable graph truthful even if a presentation changes.
- Evidence for Which Reviews Are Eligible for Markup: the live structured-data entity and property relationship
- The expected value type and any nested object
- Visible page information that supports the structured value
- Related offer or catalog fields needed for interpretation
- A fresh validation result after the page changes
| Review situation | Markup fit | Reason |
|---|---|---|
| Customer product review | Strong when genuine | Specific product and visible evidence |
| Editorial product review | Strong when independent assessment | Named author and reviewed item |
| Recipe rating | Possible when real | Defined recipe and review population |
| Software app review | Possible when supported | Specific application |
| Generic testimonial | Weak or inappropriate | No precise reviewed item or scale |
| Internal employee quote | Not customer review evidence | Different relationship |
| Imported third-party review | Only with rights and faithful source model | Ownership and verification risk |
| Company rating on own site | Self-serving risk | Business rates itself or controls presentation |
- Identify the exact reviewed item.
- Confirm review provenance and rights.
- Check current supported feature type.
- Display the evidence with the markup.
Mark up only reviews whose subject, source and score are real, visible and appropriate for the page and current feature.
The decision for Which Reviews Are Eligible for Markup should rest on live, traceable evidence and a verified follow-up check.
How Should Ratings and Review Counts Be Calculated?
Define which submitted reviews enter the average: published, non-spam, non-duplicate and associated with the exact item. Pending or rejected submissions should not silently count. If scores use different scales, normalize them with a documented method before aggregation or keep populations separate.
Product variants need a clear rule. Reviews may apply to one variant or the parent product family, but the page and structured data must communicate the same scope. When a review is removed or corrected, the average and count should update across the visible page, JSON-LD and any commerce feed.
- Frame the decision raised by How Should Ratings and Review Counts Be Calculated.
- Confirm its value type and the object it describes.
- Compare the markup with visible page information.
- Correct the source data or template without inventing values.
- Validate the rendered result and monitor future changes.
| Calculation issue | Required rule | Failure example |
|---|---|---|
| Population | Define included settled reviews | Pending submissions counted |
| Spam and duplicates | Exclude through consistent moderation | Repeated rating inflates average |
| Scale | Use one scale or documented normalization | Five-point and ten-point scores mixed |
| Variant scope | Assign review to variant or group | Color-specific defect averaged everywhere |
| Deletion | Recalculate after valid removal | Count stays stale |
| Rounding | Use consistent displayed precision | Markup 4.7, page 4.5 |
| Review vs rating count | Track text and numeric populations | Counts used interchangeably |
| Locale | Avoid duplicate translated review counting | Same review counted per language |
- Document the eligible population.
- Recalculate after moderation changes.
- Match visible and structured precision.
A trustworthy aggregate is reproducible from the exact visible review population and documented moderation rules.
The decision for How Should Ratings and Review Counts Be Calculated should rest on live, traceable evidence and a verified follow-up check.
How Can Review Schema Affect SEO and CTR?
A visible rating and count can attract attention or increase trust when the review population is credible. It can also filter searchers who need a higher rating or more evidence. Higher CTR is not automatically better if the clicks do not convert, while lower CTR can still produce stronger revenue per impression through better qualification.
Measure rich results, CTR, conversions, refunds and review-quality metrics together. For ecommerce, connect the review entity to accurate Product schema. The page must deliver the same item, price, availability and review context promised in search.
- Evidence for How Can Review Schema Affect SEO and CTR: the live structured-data entity and property relationship
- The expected value type and any nested object
- Visible page information that supports the structured value
- Related offer or catalog fields needed for interpretation
- A fresh validation result after the page changes
| Possible outcome | Interpretation | Follow-up metric |
|---|---|---|
| CTR rises | Stars or rating attract attention | Conversion rate |
| CTR falls, conversion rises | Low-fit clicks filtered | Revenue per impression |
| Clicks rise, returns rise | Expectation mismatch | Return and complaint reasons |
| Feature disappears | Eligibility or display changed | Validation and live SERP evidence |
| Rating changes | Review population changed | Moderation and calculation log |
| No visible effect | Feature not shown or weak query fit | Appearance and query segment |
- Record baseline appearance and outcomes.
- Implement genuine review data.
- Observe actual result changes.
- Measure qualified clicks and settled conversions.
Review schema helps when truthful social proof improves qualified selection and the landing page sustains that trust.
The decision for How Can Review Schema Affect SEO and CTR should rest on live, traceable evidence and a verified follow-up check.
What Review Schema Mistakes Are Common?
A business may display five stars in JSON-LD while showing no review evidence on the page. A product page may inherit a store-level rating. A plugin may count every testimonial as a product review. These are factual errors, not minor warnings. They can mislead a shopper before the click.
Other defects are technical: bestRating and worstRating do not match the visible scale, duplicate blocks publish different averages, author identities are missing or dates are false. Imported reviews may lack permission or lose provenance. Fix the review system and data model before changing markup.
- Frame the decision raised by What Review Schema Mistakes Are Common.
- Confirm its value type and the object it describes.
- Compare the markup with visible page information.
- Correct the source data or template without inventing values.
- Validate the rendered result and monitor future changes.
| Mistake | Risk | Control |
|---|---|---|
| Fabricated stars | False reputation claim | Only settled real reviews |
| Hidden aggregate | Users cannot verify evidence | Display rating and population |
| Store rating on product | Wrong itemReviewed | Attach exact subject |
| Self-serving organization rating | Controlled reputation enhancement | Respect current feature constraints |
| Stale count | Outdated social proof | Lifecycle synchronization |
| Copied platform score | Provenance and permission gap | Use authorized source faithfully |
| Mixed rating scales | Invalid average | Normalize or separate |
| Duplicate graphs | Conflicting averages | One canonical review source |
- Protect review truth above CTR goals.
- Preserve source and moderation evidence.
- Remove conflicts at the generator level.
The highest-risk Review schema defect is a reputation claim that the visible settled review evidence cannot prove.
The decision for What Review Schema Mistakes Are Common should rest on live, traceable evidence and a verified follow-up check.
How Do You Audit Review Schema?
Test products, works or applications with no reviews, one review, many reviews, deleted reviews and multiple variants. Parse all JSON-LD, Microdata and RDFa together. Record Review, Rating and AggregateRating nodes, IDs, authors, values, scales and counts.
Recalculate the average independently from the authoritative review store. Compare visible rating, precision, reviewCount, ratingCount, itemReviewed and reviewer data. Check moderation events, localization and cached output. Validate current feature eligibility only after the factual audit passes.
- Evidence for How Do You Audit Review Schema: the live structured-data entity and property relationship
- The expected value type and any nested object
- Visible page information that supports the structured value
- Related offer or catalog fields needed for interpretation
- A fresh validation result after the page changes
| Audit check | Evidence | Pass condition |
|---|---|---|
| Reviewed item | Page and graph identity | Exact supported subject |
| Review provenance | Settled review records | Genuine attributable source |
| Average | Independent recalculation | Matches ratingValue |
| Count | Eligible record count | Matches visible and structured value |
| Scale | Best and worst values | Consistent across reviews |
| Visible parity | Rendered page | Evidence is verifiable |
| Graph integrity | All structured-data blocks | No conflicting duplicates |
| Lifecycle | Add, moderate and remove test | Average and count update together |
- Select review states and variants.
- Extract and normalize every graph.
- Recalculate from settled records.
- Compare page, markup and source.
- Fix data logic and retest moderation events.
A Review schema audit passes when the displayed and structured rating can be reproduced exactly from genuine, settled and correctly scoped review records.
Start with a relevant free SEO check, continue the evidence workflow in Novaverb, and review pricing when comparing continuous monitoring with a one-time manual review.
The decision for How Do You Audit Review Schema should rest on live, traceable evidence and a verified follow-up check.