Review platforms and the schema that makes them count

Start by separating three effects that get bundled together in every review app’s pitch.

Appearance in the result. Valid rating markup on a product page can put a star rating and a count into the search result. That is a click-through effect. The same position, with stars, gets more clicks than the same position without — which is worth having and is not a ranking improvement. Nothing about the star changes where you sit.

Content on the page. This one is underrated. Reviews add the words customers use, including the fit complaints, the comparisons and the use cases nobody on the marketing team would think to write. That is real content, it is unique to your page, and it is the sort of specific, attributable language answer engines quote. It is also the reason a product page with forty reviews behaves differently in search from the identical page with none — the page is genuinely different.

Ranking, directly. No. There is no review count input you can turn up. If the third-party comparisons you read imply otherwise, look at what is actually being compared: pages with many reviews tend to be pages for popular products on well-linked sites, which is the variable doing the work.

The honest version of the business case is therefore conversion first, click-through second, content third, and ranking not at all. Which is fine — conversion is the better prize anyway.

Almost every brand, on discovering review markup, wants the stars next to their homepage. Google’s review snippet documentation closes that off in one sentence: "If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature." Organization reviews are acceptable when you are reviewing *other* organisations — a directory, a comparison site — not yourself. The guidance goes further on curation: "Don’t rely on human editors to create, curate, or compile ratings information for local businesses."

It is worth understanding why, because it stops this reading as an arbitrary restriction. Self-collected, self-published, self-selected ratings are not evidence. Marking them up as if they were invites a manual action that can remove every rich result on the domain — not just the stars you were reaching for. The downside is asymmetric and the upside was a decoration.

So put the company-level number on the page as visible text instead. "Over a hundred five-star reviews", stated plainly and attributably, does the persuasion job for the human reading it and carries no markup risk at all. We follow that rule on this site: no aggregateRating for the organisation, review counts as copy.

Product-level ratings are a different matter and are the sanctioned route — a product review is a review of a thing you sell, not of you, and Google supports Product in the review snippet types. That is where the markup effort should go.

Here is the bug we find on most stores that have a review app installed, and it is invisible unless you look at the rendered source.

Shopify themes can emit product structured data themselves — the structured_data Liquid filter "converts an object into a schema.org structured data format", outputting a product as Product if it has no variants and as ProductGroup if it has one or more. Review apps also emit product structured data, because emitting it is one of their selling points. Install one on the other and the page ships two Product nodes: one with the rating, one without, or worse, two with different ratings because one is cached.

What a crawler does with that is unpredictable and none of the outcomes are the one you wanted. The fix is a decision, not a plugin: one component owns product markup on this store. Usually it should be the theme, because the theme knows about variants, pricing, availability and the ProductGroup distinction, and can read the rating from a metafield the app writes. Then turn the app’s markup off — most have a setting, and the ones that do not are telling you something.

While you are in there, check the smaller requirements, because they are the ones that silently disqualify a result. AggregateRating needs a ratingValue and at least one of ratingCount or reviewCount. A Review needs an author, the item reviewed with a name, and a reviewRating.ratingValue. And the author has to be a plausible name for a person or team — Google’s product documentation explicitly rejects things like "50% off on Black Friday" in the reviewer name field, which exists as guidance because somebody kept doing it.

Collection and markup are the technical half. The half that changes revenue is placement, and it is mostly free.

The rating summary belongs near the title, above the fold, as a jump link — that is the element shoppers scan for. The reviews themselves belong far enough down that they do not compete with the buy button, and they need to be filterable by rating, because the first thing a careful shopper does is read the two-star reviews. Hiding those is both dishonest and counter-productive: a product with nothing but five-star reviews reads as curated, and it is.

The thing worth building once is the ability to lift a specific review into a page. A single well-chosen quote, on a collection page or a landing page, next to the product it is about, does more than a widget of forty. That means blocks a merchandiser can place — which is what a [section library](/services/build/shopify-section-library) is for, and reviews are one of the better arguments for having one.

If reviews are thin, say so rather than dressing it up. Twelve honest reviews displayed plainly beat two hundred that a shopper suspects. And if you are running an incentive to collect them, take advice on how it must be disclosed — incentivised and fabricated reviews are a consumer-protection issue in the UK, not only a search one.

• Shopify section libraries for content-heavy brands
• The product page audit: twenty things worth checking
• What AI assistants say about your brand, and why