If your website has genuine customer reviews but no stars beside its Google result, check eligibility before changing plugins. Reviews about your business and reviews about a particular product need different treatment.
The useful question is: which page should show stars, what is being reviewed, and does that page qualify? Start there before paying for extra markup or replacing a working review widget.
First, identify where the stars are missing
Save a screenshot of the result, the search you used and the destination URL. Then separate these three situations:
- Your Business Profile: the business listing shown in Google Search or Maps.
- Your own website result: a result linking to your homepage, service page or product page.
- A third-party review page: a result linking to another website that reviews your business or products.
Google confirms that Business Profile reviews appear beside the profile in Search and Maps. Seeing a rating there does not establish that your own homepage qualifies for a review snippet.
For example, a repair business might have reviews on its profile, testimonials on its website and a listing on a review platform. Treat each destination separately. A screenshot showing stars on the review platform is not evidence that the repair business’s service page has a technical fault.
Your own business reviews do not qualify just because you embed them
Google’s current review snippet guidelines exclude self-serving reviews for LocalBusiness and Organization, including their subtypes. This covers reviews about a business displayed on that same business’s website, whether added directly or through an embedded third-party widget.
That means importing genuine Google reviews onto your homepage does not make that page eligible for those stars. The restriction concerns the relationship between the reviewed business and the website displaying the reviews; genuine feedback alone does not remove it.
Before buying a “review stars” feature, ask the supplier to identify the exact page and Google’s supported eligibility route. A demonstration from an independent review directory answers a different question.
Keep useful testimonials for visitors. However, set the brief around helping customers understand your work, rather than promising a particular search appearance. Do not commission repeated plugin changes when the underlying issue is eligibility.
Product reviews need a separate assessment
A retailer’s customer reviews of a particular product are a different case from reviews of the retailer itself. Google’s product snippet documentation supports product results containing ratings and review information. Its guidance focuses on pages for a single product, or variants of that product, rather than broad product categories.
Use a simple comparison when briefing your developer. “The shop answered quickly” describes the seller. “These headphones are comfortable during a long journey” describes the item. Those comments should not automatically feed the same rating.
For an eligible product page, ask the developer to check the product identity, the review or aggregate-rating fields and the relationship between them against Google’s requirements. Treat a valid price or offer as separate evidence: it does not prove that review information is present.
Do not relabel your business or general testimonials as a product to chase stars. Google’s general structured data guidelines require markup to represent the page’s actual content and prohibit misleading information.
If you sell several products, choose one representative page for investigation first. Establish whether the problem affects its reviews specifically or the shared product template before making a site-wide change.
Check the published page with the Rich Results Test
For a page that has a legitimate eligibility route, use Google’s Rich Results Test. Enter the complete public page URL. Testing the published page gives you more useful evidence than testing a supplier’s sample code alone.
The test reports supported structured data it finds, including detected types, errors and warnings. Expand the relevant item to inspect the detail. Distinguish these outcomes:
- No relevant item: investigate whether the expected review or product data is actually being output.
- An invalid item: give the developer the specific error and affected URL.
- A valid item with warnings: assess the recommendations separately from critical errors.
- A page-access failure: investigate access before drawing conclusions about the markup.
Save the test result before and after the repair. If your developer tests a revised code sample, also ask for a fresh URL test once that change reaches the live page.
Compare the review content with the data behind it
Next, inspect the page as a customer. Can you find the reviews and understand what the rating describes? Google’s review guidance requires marked-up review information to be available to visitors and says not to aggregate ratings from other websites.
Our recommended check is to compare the visible review section with the corresponding data, rather than reviewing each in isolation:
- Does the rating belong to this item, rather than the business generally?
- Does the displayed total agree with the data being supplied?
- Can visitors read the feedback supporting the rating?
- Does another plugin or template output a conflicting rating for the same item?
For a practical developer check, identify which integration owns each output. Your shop platform, SEO plugin and review service may each contribute data. Inspect their actual output before disabling anything; the presence of several integrations does not by itself prove a conflict.
Keep the repair focused. Ask the developer to explain which output needs changing and why, then check that the visible review section and the rest of the product page still work.
Use Search Console to check what Google has detected
A live test and Google’s stored understanding are separate pieces of evidence. In Search Console, look for the relevant review or product report and inspect the affected URL.
Google’s rich result report guidance explains that reports appear for supported types when valid markup has been found. The reports show samples, rather than every detected item, and their counts refer to structured data items rather than pages. A missing report is therefore a reason to investigate, not a complete diagnosis.
Check the reported crawl date against the date of your repair. Where an issue has been fixed across its affected pages, use the report’s validation process and monitor the result. Keep the original evidence so you can distinguish an unresolved fault from an older observation.
Aim for a clear handover: the page qualifies, its relevant data is valid, and Google has had an opportunity to detect the corrected version.
A valid result still does not guarantee visible stars
Google explicitly states in its general guidelines that correctly implemented structured data does not guarantee a rich result. Passing a test establishes technical evidence; it does not reserve space in Search.
Set a sensible stopping point. If eligibility, content, implementation and Google’s detection all check out, record that outcome. Avoid treating every search without stars as a new development incident.
For ongoing monitoring, keep a small set of representative URLs and note meaningful template or integration changes. Review search appearance alongside relevant traffic and customer actions, rather than judging the work from one screenshot.
If the page was never eligible, put the effort into clear services, useful product information and credible customer feedback. If an eligible page is broken, fix the specific implementation. Both decisions are more useful than a promise of guaranteed stars.
Give your developer a brief they can act on
Send the affected URL, a screenshot of the Google result, the live test findings and the relevant Search Console evidence. Ask for an eligibility explanation, the component responsible for the output and a before-and-after check.
BuzzBoost’s SEO service covers the technical foundations behind search visibility. If you need help separating an eligibility restriction from a website fault, tell us which page you are investigating. We can help establish the right next step.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
