Review markup gets talked about as though it were a growth tactic. Add the code, get the stars, watch the clicks arrive. That framing leads stores into two mistakes at once: adding markup that does not describe the page, and expecting a result the markup was never able to produce.
Here is the plain version. Structured data is a translation layer. It takes what a human can see on your page and states it in a form a machine can read without guessing. Review markup does that for ratings and reviews specifically.
So everything it can do follows from what is genuinely on the page, and everything it cannot do is anything that requires the page to be better than it is. It cannot invent trust, it cannot make a thin page authoritative, and it cannot make stars appear on demand.
What it can do is make sure that when your reviews are considered, they are read accurately. That is a smaller claim, and it is worth doing properly.
What the markup is actually for
Its purpose is precision. Without it, a machine reading your product page has to infer from the layout that the number four next to some shapes is an average rating out of five, based on a certain number of reviews, about this product rather than about your shipping.
With it, those facts are stated: the item being reviewed, the rating value, the scale, the count, and where relevant the individual reviews with their authors and dates.
The benefit of that precision is eligibility rather than ranking. Search results can include additional elements, and one condition of being considered for them is that the underlying information can be read unambiguously. The markup gets you into consideration. It does not decide the outcome.
There is a second benefit that gets less attention. Machines other than one search engine read the same markup, including the systems that assemble shopping surfaces and, increasingly, assistants that summarise product information. Stating your facts clearly once serves all of them, which is a good reason to do it properly rather than minimally.
Markup describes your reviews. It does not write them, and it cannot rank a page on its own.
What it does not do
It does not rank your page. Markup is a description of content, not a quality signal about it. A page with excellent markup and nothing worth reading does not beat a page with real content and no markup.
It does not produce stars on demand. Rich results are shown at the discretion of the search engine, they vary by query and device, they can appear and disappear, and no amount of correct implementation makes them certain.
It does not create credibility. A rating summarising four reviews looks like what it is. Markup makes that fact machine readable, which is honest, and honestly small.
It does not fix a product page. If the page does not answer sizing, shipping, materials and returns, adding structured data to the reviews changes nothing about why people leave.
And it does not substitute for the review programme itself. The hard part of reviews is collecting enough recent, specific ones from real customers. That is an operational job involving timing, asking well and making it easy. Markup is the last five per cent of that work, not the first.
Mark up what is on the page, nothing else
The rule that catches most stores is that structured data must describe content a visitor can actually see on that page.
So a rating shown in the markup must be shown on the page. Reviews described in the markup must be present on the page, not held in a system that renders somewhere else or is only visible after a click into a different page.
The common failure is aggregating across a whole store or a whole category and attaching the result to every product, so a product with no reviews of its own displays a store wide average in its markup. That is not a technical shortcut, it is a misstatement, and the consequences range from the markup being ignored to a manual penalty against the site.
A related failure is marking up reviews the page has removed. Review systems paginate, filter and expire, and markup generated separately from the visible list drifts out of alignment.
The safe practice is that the same source produces both, so they cannot disagree. If your review app renders the widget and the markup from the same data, this problem does not arise. If your theme writes markup by hand from a different field, it will.
Reviews of the product and reviews of the store are different
This distinction causes a lot of confused implementations.
A product review is about the item: how it fits, whether it lasted, whether it did the job. It belongs on the product page and describes that product.
A store review is about the experience of buying: delivery, packaging, support, returns. It is about the business, not the item, and it belongs where the business is described.
Mixing them means a product page carrying feedback that is mostly about shipping, which is unhelpful to a buyer deciding between two items and misleading as a description of the product.
There is also a well established principle that reviews you write about yourself, or collect and publish about your own business on your own site, are treated differently to reviews about a product. The safest reading is straightforward: use product reviews for products, keep store feedback where it belongs, and do not attach business ratings to individual items.
Separating them also improves the pages for humans. A shopper on a product page wants to know about the product. A shopper wondering whether to trust the store wants a different page, and it is worth having one.
Where the real gain from reviews sits
If the markup is a small technical job, the large job is the reviews themselves, and it is a conversion job before it is a search one.
What helps a buyer decide is specific, recent, relevant feedback. A review that says the item runs small and the reviewer sized up answers a question the description could not. A photograph from a customer answers scale. A review from someone who states their situation lets a reader recognise themselves.
So the work is in asking at the right moment, after the customer has actually used the thing rather than the day it arrived, and asking questions that produce useful answers rather than a star rating and a blank box. Prompting for fit, use case and comparison produces content worth reading.
Displaying them well matters as much. Recent first, filterable by the attributes people care about, visible without a click, and with the difficult ones left in place, because a page of unanimous praise is less persuasive than a page with a three star review answered thoughtfully.
Do that, and the markup has something worth describing. Do only the markup, and it does not.
The checks worth running before adding more
A short list, in order.
Does every rating in the markup appear on the page it is attached to. If not, fix that before anything else.
Is the review content rendered in the page itself, or only after a script fetches it. If a machine reading the page without executing everything sees nothing, the markup describes content that is effectively invisible.
Does the count in the markup match the count shown. Drift here is common and it undermines the rest.
Is the product identified consistently across the page markup, so the reviews attach to the same item as the price and availability.
Are store level ratings kept off product items.
And does the rest of the product markup tell the truth: the current price, the real availability, the actual currency. Reviews sit inside a product description, and inaccuracies elsewhere in that description reduce how much any of it is trusted.
Run those, fix what fails, then stop. Additional markup beyond what the page genuinely contains adds risk without adding anything, and the time is better spent getting more customers to write something worth marking up.