What Is Aggregate Rating Schema?

Aggregate Rating Schema is structured data that states the average score and total participation behind ratings or reviews for one specific item.

The AggregateRating type summarizes many evaluations; it is not a substitute for an individual Review. A typical object contains ratingValue plus at least ratingCount or reviewCount, and it is nested under the entity being rated. The visible page must show the same average, count and scale so a visitor can understand the evidence behind the summary. When the item type and implementation are eligible, this data may support a review snippet with stars or summary information, but correct markup never guarantees that presentation. The purpose is to communicate an observed rating aggregate accurately, not to manufacture visual prominence in search. Compare the neighboring intent in Review Schema.

1. Frame the decision raised by What Is Aggregate Rating Schema.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Use a measured average.
• Publish the supporting count.
• Identify one eligible entity.

AggregateRating is credible only when the summary is visible, reproducible and attached to the correct item.

The decision for What Is Aggregate Rating Schema should rest on live, traceable evidence and a verified follow-up check.

AggregateRating Schema works by nesting a numerical summary inside the entity it evaluates or by explicitly identifying that entity with itemReviewed.

A nested structure is often clearest: a Product, SoftwareApplication, Recipe or another supported parent contains an aggregateRating property. The parent’s name establishes the item being rated, so a second itemReviewed inside the aggregate is unnecessary. A standalone aggregate needs a valid itemReviewed object with a recognizable name. Search systems can compare the declared average, count and scale with visible page content. They cannot infer whether the business calculated the number correctly, so the publisher must preserve source records, exclusion rules and recalculation logic.

• Evidence for How Does AggregateRating 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

1. Choose nested or standalone structure.
2. Identify the rated item.
3. Publish the average and count.
4. Verify visible equivalence.

The graph works when a reader can identify exactly what was rated and how much evidence supports the score.

The decision for How Does AggregateRating Schema Work should rest on live, traceable evidence and a verified follow-up check.

AggregateRating needs ratingValue and at least one participation count, while bestRating and worstRating define any non-default numerical scale.

Use ratingValue for the arithmetic average. Provide ratingCount when the count represents all submitted ratings, including score-only inputs. Use reviewCount when it represents people who supplied reviews, whether or not the source distinguishes written text. If both are available and accurately defined, both can be included; do not copy one database total into two fields with different meanings. A conventional numeric scale defaults to 1 through 5, so declare bestRating and worstRating when the system uses another range. Decimal notation in structured data should use a period.

1. Frame the decision raised by What Properties Does AggregateRating Need.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Separate ratings from reviews.
• Keep the average within range.
• Declare custom scale boundaries.

A minimal valid aggregate is better than extra fields whose counts or scale cannot be explained.

The decision for What Properties Does AggregateRating Need should rest on live, traceable evidence and a verified follow-up check.

ratingCount is the total number of rating submissions, while reviewCount is the number of reviewers represented by reviews; they should not be treated as interchangeable labels.

A store may have 2,000 star ratings but only 650 written reviews. In that case, ratingCount can be 2,000 and reviewCount can be 650 if the displayed average and page interface make that distinction clear. Some platforms call every score a review internally, but the structured fields should describe the real user action rather than mirror an ambiguous database column. At least one count is required for an aggregate. If only one trustworthy total exists, publish that one. Never inflate the count by adding ratings and reviews when the latter are already included in the former.

• Evidence for ratingCount vs reviewCount: What Is the Difference: 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

1. Define source events.
2. Deduplicate records.
3. Calculate each total separately.
4. Match visible labels.

Choose the count that matches the underlying event and disclose both only when their meanings stay distinct.

The decision for ratingCount vs reviewCount: What Is the Difference should rest on live, traceable evidence and a verified follow-up check.

Model the actual rating scale with ratingValue, bestRating and worstRating, keeping every value inside the declared boundaries.

A 4.4 average on a 1–5 scale is straightforward. An 8.8 score on a 0–10 scale needs explicit bounds so it is not interpreted as an impossible five-star value. Fractions and percentages can carry an implied scale, but a normalized numeric value with clear visible context is easier to audit. Do not convert a Net Promoter Score, editorial grade, safety score or internal quality metric into a customer rating unless the page honestly presents it as the same evaluation. When combining sources with different scales, normalize the underlying records consistently before calculating the average and document the formula.

1. Frame the decision raised by How Should Rating Scales Be Modeled.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Use the real minimum and maximum.
• Avoid mixing unrelated scoring systems.
• Document normalization formulas.
• Recalculate after source changes.

The declared scale is correct when the same score has the same meaning in markup, UI and source data.

The decision for How Should Rating Scales Be Modeled should rest on live, traceable evidence and a verified follow-up check.

Aggregate ratings should be attached only to a supported, specifically named entity whose page genuinely presents the rating summary.

Common eligible families include products, software applications, books, events, recipes, movies, courses and certain creative works. Local businesses and organizations have stricter review-snippet limits when the rated entity controls the reviews about itself. A generic web page, category archive or site-wide company score should not be forced into a product rating simply because stars could improve CTR. Use the most specific applicable entity and follow that entity’s own required properties. Product ratings should connect to Product Schema; app ratings should connect to SoftwareApplication Schema.

• Evidence for Which Entity Types Can Use Aggregate Ratings: 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

1. Identify the rated thing.
2. Select its specific schema type.
3. Check feature-specific rules.
4. Keep the page focused on that item.

Eligibility begins with the right entity, not with the desire to add stars to a search result.

The decision for Which Entity Types Can Use Aggregate Ratings should rest on live, traceable evidence and a verified follow-up check.

Self-serving review restrictions prevent organization and local-business pages from earning star review features from ratings they control about themselves.

A business cannot make its own organization or local-business page eligible for review stars merely by collecting testimonials or embedding a third-party widget. The restriction concerns who controls the reviewed entity and page, not whether the review vendor is independent. A site that reviews other organizations may be eligible when it follows the applicable rules and presents genuine review content. This does not mean all first-party product ratings are prohibited: products and software applications have different supported contexts. Avoid broad claims such as “third-party widgets fix self-serving reviews.” They do not change the relationship between publisher and rated organization.

1. Frame the decision raised by What Are Self-Serving Review Restrictions.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Identify who controls the entity.
• Separate product and organization contexts.
• Do not infer eligibility from review-source branding.

Treat entity control as the deciding factor and never use a widget as a workaround for self-serving restrictions.

The decision for What Are Self-Serving Review Restrictions should rest on live, traceable evidence and a verified follow-up check.

Common mistakes include fabricated averages, mismatched counts, hidden ratings, unsupported entities, wrong scales and ratings attached to the wrong product variant.

A CMS may cache 4.8 from last month while the visible widget now shows 4.6. A template may use review count as rating count, or combine multiple product models into one score without a legitimate group relationship. Businesses sometimes mark up testimonials that have no numerical ratings, publish stars that are visible only after interaction, or attach an organization score to a generic homepage despite self-serving limits. Variant catalogs can also assign a family-wide rating to one child without evidence that the score applies. A syntax test will not detect these data-integrity problems, so compare markup with rendered content and the rating source.

• Evidence for What Aggregate Rating Schema Mistakes Are Common: 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

1. Validate syntax.
2. Recalculate the average.
3. Reconcile counts.
4. Confirm entity and visibility.

The highest-risk error is any number that cannot be reproduced from the customer-visible rating dataset.

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 What Aggregate Rating Schema Mistakes Are Common should rest on live, traceable evidence and a verified follow-up check.