GMax Mart
Home Services Pricing Portfolio FAQ Reviews Blog Support Careers Change Language

E-commerce

Verified buyer reviews and product review schema

By · · 7 min read
Verified buyer reviews and product review schema

Two products, both showing 4.6 stars. One rating comes from people whose orders can be traced in the database. The other comes from anyone who found the page. Shoppers cannot tell the difference unless you show them, and search engines will not show a rating at all unless the markup is right. This article covers both halves of that problem: tying reviews to real purchases, and implementing product review schema so ratings can appear in search results without breaking anyone's rules.

It assumes you already have a review system running. The focus here is trust and technical correctness rather than how to ask for reviews in the first place.

What a verified purchase badge should actually mean

A verified badge is a claim, and a weak claim is worse than none. Define the rule before you display it, and keep it to something your database can prove.

A defensible rule is usually: the reviewer is signed in to the account that placed the order, the order contains that exact product, the order was delivered, and it was not fully refunded or cancelled. Store the order reference against the review so any dispute can be checked later.

Handling the awkward cases

  • Guest checkout: match on the order email, but require the reviewer to follow a signed link sent to that address rather than typing the email themselves
  • Bought offline or elsewhere: allow the review if you want it, but leave it unbadged and say so
  • Returned orders: keep the review, remove the badge, and consider a short note that the item was returned
  • Variants: verify against the specific variant purchased, and show it, since a size complaint means nothing without the size

Explain the badge in one plain sentence near the review list, linked to a slightly longer note. Shoppers trust a badge more when they can see the rule behind it, and a vague badge invites suspicion.

Practical defences against fake reviews

You will not eliminate manipulation, but a few layers make it expensive enough that most attempts stop.

  • Allow one review per customer per product, editable rather than duplicable
  • Require a signed-in account and a completed, delivered order for badged reviews
  • Rate-limit submissions by account, device and IP address, and hold bursts for manual checking
  • Queue every review with a link, phone number or email address in the text
  • Watch for a sudden cluster of five-star reviews with similar phrasing and very short text
  • Log the submission time, account age and order date so patterns are visible afterwards
  • Never let staff or agencies post reviews on products your own business sells

Negative manipulation matters too. A competitor filing a run of one-star reviews from fresh accounts is a real risk, which is another reason to require a verified order before a rating counts towards your average.

India has a voluntary Bureau of Indian Standards specification for the collection, moderation and publication of online consumer reviews, and consumer protection rules discourage misleading practices online. Publishing your moderation policy, avoiding paid positive reviews and disclosing any incentives are sensible baselines; check your specific obligations with a qualified professional.

Marking up ratings with structured data

Structured data tells search engines what the numbers on your page mean. For an online store the relevant types are Product, with Review and AggregateRating nested inside it. JSON-LD in a script block is the format Google recommends, and it keeps the markup away from your visible HTML.

The fields that matter

On the Product itself, include the name, an image, a description, the SKU or a product identifier such as GTIN or MPN, the brand, and an Offer with price, priceCurrency and availability.

For aggregateRating, supply ratingValue, plus reviewCount or ratingCount. State bestRating and worstRating if your scale is not the usual 1 to 5. For an individual review, include the reviewRating with its ratingValue, the author as a Person with a real name, and the datePublished.

Rules that are easy to break by accident

  • Every rating you mark up must be visible to a visitor on that same page. Invisible markup is the most common cause of a manual action.
  • The numbers must match what the page shows. If the page says 4.3 from 27 reviews, the markup must say the same.
  • Do not mark up reviews collected on another website or copied from a marketplace as if they were yours.
  • Do not use an author name like "Our customers" or your own company name; the author of a review is a person.
  • Reviews written by the business about itself, or about its own services, are not eligible for review snippets.
  • Use Product markup on real product pages. Putting it on a category or collection page is a mismatch.

Generate the markup from the same data that renders the page, never by hand. Hand-written JSON-LD drifts out of sync the moment a review is deleted.

Testing and monitoring your markup

Validate every template with Google's Rich Results Test before release, and again after any theme change. Then watch Search Console: the Product snippets and Merchant listings reports show errors and warnings across your whole catalogue, which is where you will spot a missing price or an availability value that stopped updating.

Check the Manual actions report occasionally too. Structured data penalties appear there, and they are usually caused by markup that does not match visible content.

Remember that eligibility is not a guarantee. Correct markup makes a star rating possible in search results; it does not oblige any search engine to show one, and what appears can change without notice. Treat it as a chance worth taking, not a promised outcome.

Getting your review data and markup in order

Start by auditing what you have. Can every published rating be traced to an order? Does your product page markup validate cleanly? Do the numbers in the markup match the numbers on screen? Those three questions catch most of the problems in a small store.

Fix the data first and the markup second. Perfect structured data over an unverifiable rating simply advertises an unreliable number to a wider audience.

If your platform cannot link reviews to orders, or the theme's schema is hardcoded, that usually needs developer work rather than settings changes. Our team handles both when rebuilding stores as part of online store development; get in touch through support if you only need the markup reviewed.

Frequently asked questions

Will review schema make stars appear in Google results?

It makes them possible, not certain. Search engines decide when to show rich results based on quality, page type and their own thresholds, so treat correct markup as the entry requirement rather than the outcome.

Can I use ratings from Amazon or Flipkart on my own site?

You can quote them as context if the marketplace permits it, but you should not mark them up as your own site's reviews. Structured data is meant to describe reviews collected and shown on that page.

What happens if my markup does not match the page?

At best the rich result is ignored. At worst the site receives a manual action for structured data problems, which appears in Search Console and removes rich results until it is fixed and reconsidered.

Should unverified reviews count towards the average rating?

Many stores publish them but exclude them from the headline average, and label them clearly. That keeps the visible rating defensible while still giving space to people who bought the product elsewhere.

Read next

Thinking…