How to Fix Review Schema Errors in Google Search Console

Where does Search Console report review schema errors?

There is no single review report. Review markup surfaces inside the enhancement report for whichever rich result it belongs to, which for a store usually means a product or merchant listing report rather than anything labelled review. Those report names have changed more than once, so find the right one by what it contains rather than by a remembered menu item: open your property, work through the enhancement reports, and open whichever one lists your product URLs.

Every one of them behaves the same way. Problems are grouped by issue rather than by URL, each issue is marked error or warning, a sample of affected URLs sits underneath, and a validation run is offered once you believe you have fixed it. The report is a crawl snapshot, not a live check. Read it as a list of things to go and test, not as the current state of your site.

• Find the report by the URLs it lists, not by a menu path you memorised.
• Note whether each issue is marked error or warning before you touch any code.
• Open two or three sample URLs and test them live, because the report lags the site.
• Note when those URLs were last crawled, because that dates everything the report says.

What is the difference between an error and a warning?

An error means the item does not qualify. A required field is missing or invalid, so Google cannot use the markup for the rich result at all, and the page will not show stars however good the reviews behind it are. A warning means an optional field is absent. The item still qualifies, and the warning is a note about completeness rather than a blocker.

That distinction sets your order of work, and it explains the case that frustrates people most: a page with zero errors that still shows no stars. Eligibility is not display. Google grants rich results at its discretion, so clearing every error moves the page into the pool that could show stars, not into the set that will. Fix errors because they disqualify. Fix warnings once you have run out of errors.

• Error: a required field is missing or invalid, and the item is ineligible.
• Warning: an optional field is missing, and the item still qualifies.
• Zero errors is the entry condition, not a promise of stars.

Which required fields go missing most often?

The repeat offenders sit in two nodes. On an aggregate rating, the required parts are the rating value and a count of the ratings behind it, and the count is what usually goes missing, because a theme that hard-codes an average rarely bothers to hard-code the number of reviews under it. On an individual review, the required parts are the rating and an author, and the author is where it breaks: the node exists, the type is right, and the name is empty because the widget displays the reviewer as Anonymous and the markup faithfully passes along nothing.

Read the property name in the message and ignore the sentence around it. Wording differs between reports, changes over time, and is often translated, so the only durable part of the message is the property it names. Take that property, find it in your JSON-LD, and look at what is actually there rather than what the theme was supposed to put there.

• Aggregate rating: a numeric rating value plus a count of ratings or reviews.
• Review: a rating and a named author, where the empty name is the usual failure.
• The reviewed item itself, with a name, so the rating has something to attach to.
• Match on the property the message names, not on the phrasing of the message.

What causes an invalid value error?

Two things, mostly: a scale that was never declared, and a number that is not a number. The scale problem shows up in stores that keep ratings internally on something other than five points. A shop scoring out of ten that publishes a rating value of 9.2 without also declaring the top of its scale has published 9.2 out of 5, which is invalid on its face. Declaring the best and worst values explicitly costs one line and removes the ambiguity, and it is worth doing even on the ordinary five-point scale.

The other case is formatting leaking into a machine-readable field. A count rendered as 1,204 with a thousands separator, or a rating rendered as "4.8 stars" with the word still attached, is a string where a number was required. This is nearly always a theme building the markup out of the same variables it uses for display. Strip those fields back to raw numbers and the error goes.

• Declare the top and bottom of your scale rather than relying on a default.
• Send raw numbers: no thousands separators, no currency symbols, no trailing words.
• A count of zero is not a valid count; a rating with nothing behind it should not ship.

The error that is not a markup error: the rating no longer matches the page

Some pages clear the validator and still lose the snippet, because the requirement is not only that the markup parses but that it describes what a visitor can see. A page whose markup claims 412 reviews while the widget renders 38, or renders nothing at all because it failed to load, is publishing a rating no reader can verify. Google's rule is that structured data reflects the main content of the page, and this is the clause it is most often measured against.

This failure arrives after a change rather than after a mistake. A theme update, an app switch, a widget that starts paginating, a variant page inheriting the parent product's count: each one moves the visible number without moving the marked-up one. Compare the two by hand on a few of your busiest products whenever either side changes, because nothing in the toolchain compares them for you.

How do I confirm the fix and clear the report?

Test the live URL first in the Rich Results Test, and read what it parses rather than what you meant to ship. Then look at the same URL through URL Inspection and check the HTML Google actually fetched, because markup injected by a script can be present in your browser and absent from the crawl. Only when both agree should you go back to the report and start a validation run.

Then wait, and expect the waiting to feel too long. Validation recrawls a sample of the affected URLs on Google's schedule, not yours, so the issue count falls as those crawls come back rather than when you deploy. A report still showing yesterday's count today is normal. A report still showing it after several weeks of clean live tests is a different problem, and usually means some URLs in that group were never actually fixed.

• Rich Results Test on the live URL, to see what parses.
• URL Inspection and the crawled HTML, to see whether the markup was there at all.
• Then start validation, and judge it in weeks rather than hours.

What this adds up to

Errors disqualify and warnings do not, so read the labels before you read the code. Most errors resolve to one of four things: a required property the theme never emitted, a number that arrived as a string, a scale that was never declared, or a count that no longer matches the page. Work in that order, verify on the live URL and in the crawled HTML, then let validation catch up on its own schedule.

What none of that buys you is the reviews being read. A page can carry clean markup and still ship its review text inside a widget the crawler never executes, which leaves the rating machine-readable and the language behind it invisible. Getting the reviews you already hold readable, valid, and quoted in search and AI answers is the gap BeyondReviews is built to close.

Frequently asked questions