Reviews, ratings, and the rule most business sites break

Reviews are the signal small businesses obsess over most, and the one where the rules invert depending on what you sell. If you are a plumber or a clinic, marking up your own testimonials makes your page ineligible. If you sell products, Google explicitly invites you to submit your own reviews. Almost nobody knows which side they are on.

Reviewed September 5, 2026 · 11 min read

Somewhere on most small business websites there is a testimonials section, and underneath it, added by a plugin or a well-meaning developer, a block of JSON-LD claiming a 4.9 star average from 47 reviews. It is meant to put gold stars in search results. What it actually does, per Google’s own documentation, is make that page ineligible for the star feature it was added to earn.

The rule is unambiguous and it is quoted here rather than paraphrased, because the number of sites breaking it suggests almost nobody has read it: "If the entity that's being reviewed controls the reviews about itself, their pages" are ineligible for the star review feature. Local business ratings, Google adds, must be sourced directly from users, and must not rely on human editors to create, curate, or compile ratings information.

Then, one product line over, the same company runs a program that asks merchants to submit their own product reviews directly. Both things are true at once, and which one applies to you depends entirely on whether you sell a thing or do a job. This guide covers both regimes, where your reviews actually live if you cannot mark them up yourself, and the recency clause that turns a review from an asset into a depreciating one.

The rule almost every small business site breaks#

Four constraints sit on review markup, and the first is the one that bites:

• You cannot mark up reviews about yourself that you control. This is the self-serving review policy, and it is why the testimonials block with a rating attached earns nothing. The page is not penalized into oblivion, it is simply ineligible, which is worse in a quiet way: the markup sits there looking like work that was done.
• Ratings must come from users, not editors. Google names the failure explicitly: no human editors creating, curating, or compiling ratings information. A hand-picked selection of your nicest feedback, averaged by you, is exactly what that describes.
• Undisclosed incentivized reviews are prohibited, meaning anything written in exchange for money, a discount, a voucher or a free product without clear and prominent disclosure. The disclosure requirement is the part people miss; the incentive itself is not automatically disqualifying.
• Marked-up review content has to be visible on the page it is marked up on. Schema describing reviews a visitor cannot see is not eligible, which rules out the common pattern of injecting aggregate ratings sitewide from a database.

The required properties are worth knowing too, because half-complete markup fails silently. A Review needs an author (under 100 characters), an itemReviewed, and a reviewRating carrying a ratingValue. An AggregateRating needs an itemReviewed, a ratingValue, and either a ratingCount or a reviewCount. Templates for the types you can legitimately use are in the JSON-LD guide.

Where your reviews actually live#

If you cannot publish your own ratings, the obvious question is where an agent gets them. Google documents four sources for local listings, and only one of them is your website:

Reviews sit squarely in the third row. They are user contributions, which is the entire logic behind the self-serving prohibition: a review is evidence precisely because you did not write it. The moment you can author it, it stops being worth anything to the system reading it, and the policy is just that fact written down.

Google then runs its own layer on top, analyzing reviews on a place and compiling a summary highlighting common sentiment and tips. Which means the thing a customer hears when they ask an assistant about you is not your rating. It is a paragraph synthesized from what other people said, and nobody at your business approved the wording. Where the recommendation actually comes from covers the wider sourcing picture.

The recency clause nobody reads#

Google refreshes those review summaries based on reviews from the past year. Read that as a depreciation schedule. Two hundred five-star reviews collected in 2023, with nothing since, do not produce a glowing summary in 2026; they produce a thin one, assembled from whatever trickle arrived recently, which is disproportionately the people annoyed enough to bother.

This reframes the job. A lifetime star average is a vanity number. A steady arrival rate is the actual asset, because it is what keeps the summary current, representative, and favorable. A business collecting four reviews a month indefinitely beats a business that collected two hundred once, and the second business usually thinks it is winning.

If you sell products, the rules invert#

Everything above governs businesses being reviewed as businesses. Product reviews run on a completely separate track, and on that track Google asks you to submit your own. The requirements are specific enough to plan against:

1. A minimum of 50 reviews across all of your products before ratings can show on Shopping or Ads. This is an account-level floor, not a per-product one, which is friendlier to a long tail than most people assume.
2. Two submission routes: a supported reviews aggregator that pushes them for you, or direct submission through Merchant Center if you do not use one.
3. Unique product identifiers on every review, GTIN preferred, or brand plus MPN. This is the step that fails most often, and it fails silently.
4. Monthly uploads with updated reviews to stay eligible. Same recency logic as the local side, expressed as a cadence requirement rather than a summary window.
5. The domain on your review data must match your registered Merchant Center account, and expect two to four weeks before anything appears.

The reason for the inversion is worth understanding rather than memorizing. A product is a thing that exists independently of you, sold by many parties, and identified by a GTIN, so a review attaches to the product rather than to the seller and can be pooled across merchants. A service is inseparable from the business performing it, so a review of the service is a review of you, and letting you author it would be circular. Product feeds for AI agents covers the surrounding catalog work.

What to actually do#

1. Audit what you are currently publishing. Search your own source for aggregateRating and check whether the thing being rated is you. If it is, remove it.
2. Fix your Business Profile first, since it is the row in that table where user contributions land and the only one you can meaningfully influence without doing someone else’s work.
3. Build a review arrival habit rather than a review campaign. Ask at the point the job is finished and the customer is pleased, every time, without an incentive attached. The disclosure rules make incentives more trouble than they are worth at small scale.
4. If you sell products, count your reviews against the 50 floor and check whether your identifiers are actually on them. If you are under the floor, that is the whole project; nothing else in the program matters yet.
5. Leave your testimonials up, unmarked. They are read as prose, they persuade humans, and they cost nothing.

What reviews cannot do for you#

Reviews decide whether you make the shortlist. They do not decide what happens next, and the gap between those two things is where most of the loss actually occurs. An agent that has been convinced you are the right plumber still has to find out whether you can come on Tuesday, and if the answer to that lives nowhere it can reach, a perfect rating buys you a place on a list you then fall off.

That second step is a different problem with a different fix, covered in when Google’s AI calls your business. Worth holding both in mind, because the review work is slow and compounding while the availability work is fast and structural, and teams routinely spend a year on the first while the second stays broken.