AggregateRating Was Stripped Silently for Six Years

A professional services company came in wondering why their star ratings never showed up in search. They had Review markup. They had AggregateRating markup. The Rich Results Test said the page was eligible. Google was not displaying stars on a single result.

The site had AggregateRating with a 5.0 score attached to the Organization schema on every single blog post. The markup validated. The structured data report in GSC said it was clean. The rich result never rendered. The reason was Google's self-serving review rule, which has been live since 2019. AggregateRating on an Organization or LocalBusiness needs to reflect reviews of the business as a whole, with the reviews visible on the page. A blog post is not where the business itself is being reviewed. Google sees that pattern and silently drops the rich result.

The self-serving rule is one of the quietest filters in search. Nothing tells you it is happening. The markup is valid. The data type is supported. Google simply does not surface stars.

Step one was running every page type through the Rich Results Test and cross-referencing with the live SERP. The pattern was consistent. Validation passed on every page, stars displayed on no page.

Step two was reading the schema source. The AggregateRating block was hardcoded in the theme's header.php as part of the Organization JSON-LD object. It rendered on every page including blog posts, the about page, contact page, and the homepage.

Step three was determining where AggregateRating belonged. The reviews being aggregated were for specific service offerings, not the company as a whole. The right home for that data was the Service schema on the relevant service pages, with visible reviews on each page to satisfy the visibility requirement.

Step four was the rebuild. AggregateRating was removed from the Organization schema sitewide. Per-service AggregateRating blocks were added to each service page, each tied to the reviews displayed on that page.

Within Google's normal indexing cycle, star ratings began appearing on the service pages where they belonged. The rich result that had been silently suppressed for six years was finally rendering, on the pages where it was relevant.

The blog posts no longer carried inflationary 5.0 ratings they had no claim to. The site picked up rich-result eligibility on the pages that drive revenue (services), instead of on pages that were never going to convert anyway (blog).

The Setup

A professional services company came in asking why their star ratings never showed up in search. They had Review markup. They had AggregateRating markup. The Rich Results Test confirmed the page was eligible. Google never displayed stars on a single result.

What We Found

AggregateRating with a 5.0 score was attached to the Organization schema on every blog post. The markup was technically valid. The structured data report in Google Search Console said it was clean. The rich result was being stripped silently.

The reason is Google’s self-serving review rule, in place since 2019. AggregateRating on an Organization or LocalBusiness needs to reflect reviews of the business as a whole, and the reviews being aggregated need to be visible on the page. A blog post is not where the business is being reviewed. Google sees that pattern and silently drops the rich result.

This rule is one of the quietest filters in search. Nothing tells you it is happening. The markup validates. The data type is supported. Google simply does not surface stars.

The Diagnostic

Four steps.

1. Page-type sweep through the Rich Results Test. Validation passed on every page sampled. Stars displayed on no page in the SERP. The mismatch between “valid” and “rendered” is the tell.
2. Read the schema source. The AggregateRating block was hardcoded in the theme’s header.php as part of the Organization JSON-LD object. Every page on the site carried it (blog, about, contact, homepage).
3. Determine where the rating belonged. The reviews being aggregated were for specific service offerings, not the company as a whole. The correct home was Service schema on the relevant service pages, with the underlying reviews visible on each page.
4. Plan the rebuild so the rating still survived. The 5.0 was a real average from real reviews. Moving it required mapping each review to the service it belonged to, not throwing the data away.

The Fix

• Removed AggregateRating from the Organization schema sitewide.
• Added per-service AggregateRating blocks to each service page.
• Each block was tied to the reviews rendered on that page.
• Re-validated through the Rich Results Test, then waited for Google’s normal indexing cycle.

Outcome

Within the normal indexing cycle, stars began appearing on the service pages where they belonged. The rich result that had been silently suppressed for six years was finally rendering. Inflationary 5.0 ratings were gone from blog posts they had no claim to.

Rich-result eligibility moved from low-intent pages (blog) to revenue pages (services). The pages that drive bookings now carry the trust signal Google was willing to display.

Lessons

• “Valid” is not the same as “rendered.” The Rich Results Test confirms the markup parses. It does not promise Google will display the result. A page can pass every test and still be silently stripped.
• The self-serving rule is the most common cause of missing stars. AggregateRating on Organization or LocalBusiness needs visible reviews of the business itself. Sitewide AggregateRating without visible review content fails this rule on every page that is not a review page.
• Schema audit tools flag missing markup. They do not flag inappropriate markup. A site with the wrong schema in the right format will get a clean report from most automated tools. Reading the schema in context is what catches the self-serving violation.
• Move the rating, do not delete it. A real 5.0 from real reviews is an asset. Mapping it to the right schema type (Service, Product, Recipe, Course) keeps the data alive while making it eligible.

Brent’s Take

Six years of stars never displayed. Nobody on the site team did anything wrong. The markup was technically correct. The rule that disqualified it is one Google added without changing the validator. This is the kind of silent regression a schema audit is built to find.