Don't Add aggregateRating Until Your Reviews Are on the Page

When we shipped our ProfessionalService schema for the local SEO overhaul, we made a deliberate call: no aggregateRating. The component renders name, phone, service area, FAQ links, and sameAs references. Stars: none.

This was not an oversight.

What the rule actually says

Google's structured data guidelines are specific: review markup must reflect content that is visible on the page. If your JSON-LD claims 4.9 stars from 47 reviews and there is no reviews section anywhere on that page, you have fabricated schema. That is a policy violation. Google can issue a manual action against the site, which can tank rankings for months.

The violation is common because the mistake is tempting. You have 12 Google reviews. You feel good about them. You add aggregateRating to the JSON-LD because you want the star snippet in search results. Nobody stops you. The HTML is valid. The Schema Markup Validator passes it. Nothing breaks at build time.

But Google's guidelines say the rating must correspond to reviews a user can actually see on the page, not reviews that exist somewhere else on the internet.

What we're doing instead

Our checklist note on this is explicit: "Do NOT add aggregateRating to the schema until real reviews are displayed on-site. Add it only after a genuine on-site reviews section exists."

So the sequence is:

1. Build real review volume on Google Business Profile. GBP reviews already power star snippets in Maps Pack results without any schema markup on our end. That is where the immediate ranking value comes from.
2. Build an on-site testimonials or reviews section that displays real client feedback with visible star ratings.
3. Once that section exists, add aggregateRating to the schema with counts and averages that match what the page shows.

We are on step one right now. The on-site section will come after we have enough volume to display it honestly.

Why this matters more than the snippet

The star snippet in organic search results looks good, but it is not the primary goal. The goal is building a review signal that actually compounds.

GBP reviews feed the Maps Pack, which is where high-intent local searches surface service businesses. A complete, active GBP profile with a steady flow of real reviews moves that ranking. Fake schema stars do not.

The review pipeline we care about: request a review after every completed project, respond to every review, keep volume consistent rather than front-loaded. That is the compounding asset. The schema markup will reflect it accurately once we have something real to point to.

The schema field for reference

When we do add it, it will look like this in the ProfessionalService block:

"aggregateRating": {
  "@type": "AggregateRating",
  "ratingValue": "5.0",
  "reviewCount": "23",
  "bestRating": "5"
}

reviewCount is the count of reviews shown on-page, not your GBP count. ratingValue is the average of those on-page reviews. The numbers have to be honest.

The practical rule

If you cannot point a crawler to the review content on the page that the schema claims, do not put the schema in. Wait until the on-site reviews section exists, then add both the visible content and the markup at the same time.

The short-term incentive to fake it is real. The penalty risk is also real, and it falls on the site that ships the markup, not on whatever tool generated it.

If you want structured data implemented correctly for your service business, start with a free call.