AggregateRating: What It Is and How It Affects SEO

What is AggregateRating?

AggregateRating is a schema.org structured data type that describes the average of many user ratings for a product, service or piece of content. It tells search engines the average score, the number of ratings and the scale in a machine-readable way. Google may then show it as a star rating snippet.

In short, AggregateRating is the data layer behind the stars you see in search results. Also, a visitor reads "4.7 out of 5" on your page. The search engine reads the same numbers as fields in JSON-LD.

Our team mostly sees this markup on product, course, software and local business pages. However, the markup alone does not guarantee stars. Google first checks the page type, then the source of the reviews.

AggregateRating is not a standalone label. In practice, it lives inside a parent type such as Product, Course or SoftwareApplication. Without that parent, it is unclear which item the rating describes.

In this guide we cover the schema, Google's review policies, correct setup and common mistakes. For the bigger picture, read our schema markup guide.

Does AggregateRating affect SEO?

There is no official promise of a direct ranking boost. Google's documentation describes review snippets as a rich result feature. So the markup does not push your page higher; it can make your result more visible.

Still, the indirect effect is real. A result with stars stands out next to results without them. Therefore your click-through rate may improve, and that can support the page over time.

We stay careful here. From field experience we can expect some lift, but we never promise a fixed percentage. Additionally, the outcome depends on your industry, your average rating and your competitors.

Schema alone will not fix a weak click rate. Your title and description matter just as much. For that part, see our guide on improving organic CTR.

Stars also shape trust. Also, a visitor sees the rating before the click and arrives with expectations. If the page fails to meet them, bounces rise. So treat the stars as a promise, not as decoration.

Which properties does AggregateRating need?

According to Google's review snippet documentation, ratingValue is required for AggregateRating. You also need at least one of ratingCount or reviewCount. Also, the item being rated, itemReviewed, is required too, unless the markup is nested inside another type.

The properties bestRating and worstRating are recommended. If you skip them, Google assumes a 5 point scale with 1 as the lowest value. In practice, if your scale differs, you must state both values.

The order of properties does not matter, but the structure does. Keep the average and the count in the same block. Use the same format on every page, because it makes maintenance easier.

Which rating scale should you use?

Google allows the rating value to be a number, a fraction or a percentage. If your scale is not 5 based, you must write bestRating and worstRating explicitly. Otherwise Google reads the value on a 5 point scale and may misjudge it.

For example, imagine your site rates on a 10 point scale and the code says only 8.4. Google then assumes 8.4 out of 5. Additionally, the value falls outside the scale, and validation returns an error.

For that reason we recommend a 5 point scale when possible. Visitors understand it instantly. However, if you use 10 or 100 points, adding both limits to the code is enough.

When you change the scale, convert old ratings too. Otherwise the average no longer reflects reality, and the visible value no longer matches the code.

How do you calculate the average rating?

The average is the sum of all ratings divided by the number of ratings. Generating it automatically from your database is the safest route. Also, a number updated by hand soon drifts away from reality.

Example calculation: a product gets 6 ratings of 5 stars, 3 ratings of 4 stars and 1 rating of 2 stars. The total is 30 + 12 + 2 = 44. With 10 ratings, the average is 4.4. Also, these figures are only an example.

In the code you then write "ratingValue": "4.4" and "ratingCount": "10". On the page, you must show the same 4.4 and 10.

Be consistent with rounding. Showing 4.4 on the page and 4.44 in the code is not a serious violation. Still, keeping both equal makes validation and user trust easier.

Which page types support AggregateRating?

Google lists the types that support review snippets. They include book, course, event, local business, movie, product, recipe and software application. Some other schema.org types are accepted as well.

On an online store, the product page is the natural example. A software site uses the app page for the same job, and a training site uses the course page. In other words, the rating must belong to the single item the page is about.

• Product page: the average rating of one product.
• Course page: student ratings for one course.
• Software application page: user ratings for the app.
• Recipe page: ratings given to the recipe.
• Local business page: be careful, this type can run into the self-serving policy.

The last item carries a special warning. We cover your own business reviews in the sections below.

How do you write an AggregateRating JSON-LD example?

The safest way is to nest AggregateRating inside a Product block. That way you do not need to write itemReviewed separately. Below we give a short example line by line. Additionally, the values are invented and do not describe a real product.

• Main block: start with "@context": "https://schema.org" and "@type": "Product".
• Product name: add "name": "Sample Running Shoe".
• Rating block: write "aggregateRating": {"@type": "AggregateRating", "ratingValue": "4.6", "reviewCount": "128"}.
• Scale: if needed, add "bestRating": "5" and "worstRating": "1".

The 4.6 and 128 in this example are made up. On your page, these numbers must come from the real reviews visible on the page. If you prefer not to write code by hand, try our schema generator.

Read the code once more before publishing. Check that every brace closes, that commas sit in the right place and that the values match the page. Also, a single missing comma can make the whole block unreadable. That is why a validation tool is essential.

What is the difference between Review and AggregateRating?

Review describes the opinion of a single user. AggregateRating summarizes many opinions. Also, both can appear on the same page, and they complement each other.

A Review needs an author and a rating. Google asks for an author name under 100 characters. An AggregateRating has no author; it has an average and a count. So you should not mix up the two structures.

If your page shows several reviews, Google's guidance is to include the aggregate rating as well. In practice, the best setup is a few sample reviews with the total score above them. The code then holds a Review list and the aggregateRating in the same product block.

What is Google's self-serving reviews policy?

Self-serving reviews means the reviewed entity controls the reviews about itself. According to Google's documentation, if the reviewed entity controls its own reviews, those pages are not eligible for the star review feature.

The policy applies especially to the LocalBusiness and Organization types. It also applies when the reviews sit on the entity's own website or are embedded through a widget.

The logic is simple. If a business can place any review it likes in its own shop window, that review is not a neutral signal. Therefore Google leaves such pages out of star results.

Control is the key concept here. If an independent third party collects the reviews and you cannot edit them, the situation differs. Even so, the wording focuses on who controls the reviews, so you should judge each setup on its own.

The documentation does not spell out how the policy works on product pages. For that reason we suggest following the neutrality principle for product reviews as well.

Can you mark up your own business reviews with AggregateRating?

Technically you can write the code, but you should not expect stars. Placing the average of reviews from your own site inside your own LocalBusiness or Organization markup falls under the self-serving policy.

That is why our team suggests another path for local businesses. Collect your reviews in your Google Business Profile. Additionally, the stars appear there, through Google's own system. We covered this in our Google Maps SEO guide.

On the other hand, showing reviews on your page is perfectly fine. It builds trust with visitors. Also, you just should not rely on marking them up to win a rich result.

• Show customer reviews from your own site to visitors.
• Build your star goal through your Google Business Profile.
• Send customers to your profile to grow your review count.
• Answer negative reviews openly and politely.

A pattern we see in the field: local businesses chase stars with schema, yet the real gain comes from the review count in their profile. For example, a profile that answers reviews regularly looks more trustworthy in map results. This is an observation, not a guarantee.

Must the marked up reviews be visible on the page?

Yes, they must. Google's general structured data guidelines tell you not to mark up content that visitors cannot see. The review documentation also requires the review content to be readable on the marked-up page.

For example, if the page shows no reviews but the code says 4.8, that mismatch is a violation. Showing 12 reviews while the code claims 500 creates the same problem.

Before any setup, our team asks one question: can the visitor see this number on the page? Also, if the answer is no, we do not publish the markup. Google can apply a manual action for spammy structured data.

A manual action removes your rich result eligibility. According to the documentation, it does not affect your regular search ranking. Still, you lose the star appearance. You can check your status in the Manual Actions report in Search Console.

Tabs and accordions are another detail. If reviews sit behind a tab and the visitor reaches them with one click, there is usually no problem. Even so, avoid solutions that hide reviews completely or keep them only in the code.

Why are fake or incentivized reviews risky?

Google states that reviews or ratings not written by real users may lead to a manual action. The documentation also asks you to avoid fake or undisclosed incentivized reviews.

Inflating ratings is tempting in the short term and expensive in the long term. The stars disappear, trust suffers and the rich results of your entire site come into question.

If you want more reviews, take the honest route. Send customers a short request a few days after the order. Additionally, do not pick only happy customers; invite everyone in the same way.

• If you offer a discount or gift for a review, disclose it openly.
• Do not count reviews from your own team or relatives.
• Never delete negative reviews; answer them and resolve the issue.
• Do not write reviews in a competitor's name.

An incentive is not always forbidden; the problem is hiding it. A business that lets customers try a product for free and asks for an honest opinion should say so. Transparency protects both the user and the platform.

If you meet an unfair or fake review, you can report it through the platform's proper channels. Our Google review removal service can support you in that process.

Should you choose ratingCount or reviewCount?

Both serve the same purpose, but their meanings differ. ratingCount is the number of users who gave a rating. reviewCount is the number of written reviews. Google wants at least one of them.

For example, if a hundred people gave stars and thirty also wrote text, ratingCount is 100 and reviewCount is 30. Also, if your page has only a star vote, choose ratingCount.

If the page lists written reviews, reviewCount is the right choice. What matters is that the code matches the page exactly. Do not copy numbers from an earlier period; reflect current data.

When the values change, the markup must change too. So we recommend a dynamic setup that generates the markup from your database instead of static code. Our team usually solves this at the template level.

Which AggregateRating mistakes do we see most?

The mistakes we meet most in the field are small, but their consequences are large. Also, some trigger a warning in the validation tool. Others silently block the stars.

• Writing the rating with a comma: use "4.6", never "4,6".
• Marking up reviews that are not visible on the page.
• Copying one sitewide total rating to every page.
• Writing the rating of a single product on a category page.
• Using your own business reviews inside LocalBusiness markup.
• Leaving ratingValue outside the scale, for example 7 out of 5.
• Leaving the review count at zero or empty.

Most of these mistakes come from templates. That is, one error spreads to hundreds of pages at once. Therefore test several page types before you publish.

Old data is another frequent mistake. Leaving an average collected years ago without updating becomes misleading when the product changes. For example, if a new version has shipped, carrying the old version's rating is not right.

Where should you not use AggregateRating?

Do not use it on pages where the rating does not belong to a single item. In practice, the home page, category pages and blog lists fall into this group. These pages hold several products or topics, so one average means nothing.

Also, do not write a zero rating on pages that have no reviews. If there are no reviews, skip the markup. Additionally, an empty or artificial value means a validation error and a policy risk.

• Home page: do not reduce the whole site to one score.
• Category and tag pages: do not sum up product ratings and reflect them.
• Products without reviews: add the markup only after the first review.
• Ratings copied from other sites: do not use them on your own page.

As a general rule, tie the rating to what the visitor actually sees and judges on that page. This approach fits both the policy and user expectations.

How do you test AggregateRating markup?

The first step is Google's Rich Results Test. Also, you paste the page address or the code, and the tool shows errors and warnings separately. If there is an error, you fix it first.

The second step is the rich result reports in Search Console. There you see valid, warning and error items across your site. So you catch template-wide problems quickly.

1. Give the page you want to test to the Rich Results Test.
2. Read every error and warning one by one.
3. Compare the visible rating on the page with the value in the code.
4. Publish the fix and request re-validation in Search Console.
5. Check the rich result report again after a few days.

For a general technical health view, you can also try our SEO checker. Keep in mind that results can take time to appear after publishing.

What should you do if stars do not appear in search results?

Even with valid markup, stars may not appear right away. Google does not guarantee rich results. First make sure the page is crawled and indexed.

Then rule out the likely causes one by one. Your page type may be unsupported. Also, the reviews may fall under the self-serving policy. The code may not match the visible content. The review count may also be very low.

• Confirm in URL Inspection that the page is indexed on Google.
• Check that the Rich Results Test shows no errors.
• Confirm the page type is on the supported list.
• Make sure your business does not control the reviews.
• Look for entries in the Manual Actions report.

If every check is clean, be patient. Recrawling and evaluation take time. We do not promise a fixed number of days.

Also consider this: Google may not show stars for some queries or devices. In practice, if you cannot see them in your test search, they may appear for another query. So do not decide from a single search.

How should online stores set up AggregateRating?

In e-commerce, the healthiest structure produces a rating per product. Each product page collects only that product's reviews and writes them as aggregateRating inside the Product markup. Additionally, do not show single product ratings on listing pages.

Whether the review system is your own or an independent platform, the rule is the same: the number shown on the page must go into the code. Moreover, if a review platform embeds data into your site, check who writes the markup.

If you sell on a marketplace, the reviews live on an independent platform. We wrote about why that matters in our marketplace reviews article.

Watch product variants carefully. If color or size options sit on one product page, write the rating for the main product. When each variant has its own page and collects its own reviews, use each page's own rating.

If you are building the product page template from scratch, we plan schema, reviews and conversion design together within e-commerce consulting. See our e-commerce consulting page for details.

Do WordPress plugins solve AggregateRating automatically?

Many SEO and review plugins generate the markup for you. However, installing a plugin does not remove the need to validate the result. We see sites where two plugins write separate AggregateRating blocks on the same page.

Double markup triggers a warning in the Rich Results Test. Therefore you need to switch plugins off one by one to see which one produces the output. Also, a theme can be a third source.

If a plugin embeds reviews from its own server, check whether the markup belongs to your page or to the embedded frame. Google's documentation wants reviews to be readable on the marked-up page.

In short, a plugin is a starting point, and validation is your job. When we plan schema and review infrastructure at the start of a web design project, these conflicts do not appear.

Should you remove the markup if your rating is low?

No. A low rating is not a reason to remove the markup. Deleting the code to hide a bad score, or choosing only good reviews, goes against both the policy and customer trust.

Moreover, an honest 4.1 average often earns as much trust as a flawless 5.0. Also, visitors look at perfect scores with suspicion. This is a pattern we observe in customer behavior; we give no exact rate.

Instead, fix the real problem that lowers the score. Group the complaint topics, close the gap in the product or service, and then ask customers for fresh feedback.

Answering negative reviews quickly and politely also makes a difference. In practice, the person reading your reply sees that the business takes responsibility. So a single bad score becomes proof of transparency instead of a loss of trust.

Which metrics should you watch after publishing?

After you publish the markup, watch three areas. The first is the rich result report in Search Console. Second comes the click-through rate per page. Last, check how current your review count and average are.

• Number of valid, warning and error items in the rich result report.
• Click-through rate of pages with stars versus pages without.
• Match between the visible rating and the rating in the code.
• Any entries in the Manual Actions report.

When you compare click-through rates, pick the same period and similar queries. Otherwise seasonality distorts the result. To measure, you can use our CTR calculator.

To preview how your result looks, our Google SERP preview tool lets you check title and description length.

How can service businesses earn stars?

Service businesses mostly fall under LocalBusiness. That is, winning stars with reviews on their own site is hard. So the roadmap has to change.

First, move review collection to your Google Business Profile. Then reply to reviews regularly and personally. Also, add real customer feedback to your service pages, with permission and a name.

This approach does not guarantee stars, but it builds trust. Trust decides conversion after the click. After all, the purpose of a star is to convince more than to attract a click.

To tie reviews and trust signals into your content strategy, read our E-E-A-T guide. Additionally, if you want to plan your SEO process with us, visit our SEO consulting page.

Which steps should you follow for AggregateRating?

In summary, AggregateRating creates value on the right page with real, visible reviews. On the wrong page or with inflated data, it creates risk. That is, think about the policy first and the code second.

1. Confirm the page is a supported type and belongs to a single item.
2. Make sure your business does not control the reviews.
3. Show the rating and the count on the page.
4. Write the code as JSON-LD with a dot as the decimal separator.
5. Validate with the Rich Results Test.
6. Watch the report in Search Console and keep values current.

In the end, stars are an opportunity, not a right. A structure built on honest data protects you from policy problems and from lost clicks. Also, if you get stuck during setup, you can contact our team.