Green checkmarks in WordPress can feel mocking when search results stay stubbornly starless.
The plugin says active, the markup test passes, and the search result still shows a plain blue link. That gap is frustrating because missing stars can look like lost clicks, especially when competitors seem to get every visual advantage.
This usually is not proof that the schema is broken. It is a diagnosis problem. Google does not award review stars just because markup exists; it decides after crawling the page, judging eligibility, checking whether the review content matches the visible page, and weighing overall trust signals. The real question is whether Google can see, understand, and choose to use the markup.
Sort the problem into the right bucket
-
Start with eligibility, not appearance
If the Rich Results Test or Search Console reports errors, missing required fields, or an unsupported review setup, the issue is markup validity. In that case, stars are impossible until the data is fixed.
-
Compare the tested page with the indexed page
A page can validate in a browser yet fail in Google’s indexed HTML. Caching, JavaScript rendering, consent banners, and theme conditions sometimes hide the review text or schema from Googlebot.
-
Check whether Google is using that URL at all
If the page is not indexed, is canonicalized to another URL, or appears only in a different mobile/desktop variant, the problem is visibility, not schema. No indexed page means no search enhancement.
-
Confirm the page content supports the markup
The reviewed item, rating, and review text should be plainly visible on the page and tied to a specific thing. Technically valid schema can still be ignored when the page feels ambiguous, thin, or self-serving.
-
Treat the remaining cases as display decisions
When the page is indexed, the schema is valid, and the visible content matches, Google may still choose not to show stars. Rich results are optional and can vary by query, device, freshness, and competing results.
Google can fully understand review markup and still show a plain blue link. The practical diagnosis is simple:
Broken markup: errors, missing fields, or unsupported use View mismatch: Google indexed different HTML than the tested page No enhancement chosen: valid, indexed, understood — but not decoratedWhen WordPress is the real bottleneck
A frequent failure point is simple: the review markup never reaches the live canonical URL in the form Google actually sees.
Compare three versions of the page
In WordPress, start with View Source, then inspect the rendered DOM, then run the live URL in Rich Results Test. Those three outputs often differ.
- Source only: markup exists in PHP output but is removed or altered by caching, minification, or edge optimization.
- Rendered only: schema is injected by JavaScript; Google may see it, but delayed or conditional scripts are less reliable.
- Live test missing it entirely: a plugin, theme condition, or cache layer is serving different HTML to crawlers.
Find competing schema owners
Review schema commonly comes from more than one place:
- SEO plugin
- review/rich snippet plugin
- theme framework
- page builder widget
- WooCommerce add-on or affiliate plugin
When two tools describe the same page, WordPress may output duplicate, conflicting, or partially merged JSON-LD. One plugin may mark the page as a Product, another as an Article, while a builder adds a separate Review. Google often treats that as low-confidence data rather than a clean enhancement candidate.
The safest fix is usually to pick one plugin as the schema owner and disable review output everywhere else. Then purge page cache, CDN cache, server cache, and any optimization plugin cache before testing again.
Also check template logic: some plugins print schema only on archive pages, preview mode, or builder templates—not on the final canonical post URL.
If the browser source looks correct but the live test does not, suspect cache variation, mobile/desktop HTML differences, or a plugin that loads schema only for logged-in admins.
When valid review schema still gets ignored
Match the markup to the page
Search engines do not reward schema simply because it validates. The review must describe the main entity of that URL, and that entity should be obvious in the visible content.
Common mismatches include:
- Category, tag, and shop archive pages marked up as a single Product or Review.
- Homepage or “about” pages using Organization or LocalBusiness ratings from first-party testimonials.
- Roundups like “best plugins” where the page is really an Article or ItemList, not one reviewed item.
A practical rule is simple: one page, one primary item. A single product page can carry Product review markup. A comparison post should usually mark up the article or list instead, not the page as if it were one reviewed product.
When markup becomes self-serving—a business rating itself on its own site—Google may withhold stars even if the JSON-LD is flawless. Template audits matter here: archives, homepages, and comparison posts often inherit product-review code by accident.
Valid schema is not automatically eligible for rich results. Reviews are safest when tied to a specific, independently reviewable item shown clearly on the page.
Check the markup for gaps and conflicts
-
Confirm one primary item is being reviewed
The page should clearly describe a single product, software app, book, recipe, or other eligible item. If the markup points to a vague homepage, category page, or multiple targets at once, trust drops quickly.
-
Link the review to a fully described entity
Reviewshould connect cleanly to the item being reviewed, and that item should include basics such asname, page URL, and a matching visible title. Sparse plugin output often leaves only stars and a score, which looks thin rather than persuasive. -
Check rating fields for internal consistency
ratingValue,bestRating,worstRating, and any visible score format should agree. A 4.8/5 shown on-page but 96/100 in schema without proper normalization is a common contradiction. -
Look for duplicate or competing graph nodes
Many WordPress setups output review data from the SEO plugin, theme, and a blocks plugin at the same time. Multiple
Review,AggregateRating, orProductnodes describing the same page differently can make the graph unreliable. -
Match schema to visible evidence
Author, date, item name, summary, and rating should be easy to find on the page itself. Google is far more likely to trust a complete, coherent entity graph than bare-minimum markup pasted around thin content.
A page can pass testing tools and still look weak algorithmically. Rich results tend to follow pages where the reviewed thing, the reviewer, the score, and the visible content all reinforce each other.
Make the page prove the markup
Prove the review on the page
Review schema is treated as a claim. Search systems then look for the same story in the visible page: what was tested, how it was judged, and why the score was earned. A rating attached to thin commentary, copied specs, or generic pros-and-cons often looks unsubstantiated, even when the markup validates.
Affiliate links are rarely the deciding issue. Far more important is whether the article reads like a genuine evaluation and whether affiliate link handling in WordPress stays transparent and consistent with the page’s purpose.
Pages are more convincing when they show evidence such as:
- testing criteria or a scoring rubric
- first-hand observations, measurements, or comparisons
- specific pros, cons, and limitations tied to the final score
- a rating value that matches every visible mention on the page
If the schema says Review but the page looks like a buying guide, archive, or lightly edited product summary, eligibility drops quickly. The usual fix is editorial rather than technical: strengthen the review itself, then align headings, summary boxes, and schema fields.
A 4.8 in schema, 4.6 in a summary box, and no clear scoring explanation can make the page look unreliable even when validation passes.
Rule out crawl and indexing issues first
-
Confirm the URL can be indexed
Check the live page for a 200 status, no accidental noindex, and no robots.txt block on the page or required assets.
-
Verify Google chose the same canonical
If Search Console reports “Duplicate” or selected another canonical, review schema on the inspected URL will not matter. Internal links, canonicals, hreflang, and redirects should all point to one preferred version.
-
Compare raw HTML with rendered HTML
View source, then test the rendered page. If JSON-LD appears only in one version, a theme, consent layer, or JavaScript dependency may be hiding it from Google.
-
Check what optimization tools changed
Minify, combine, delay-JS, CDN edge caching, and schema plugins can strip script tags, move them late, or output stale markup after edits.
-
Request a fresh crawl after fixes
Purge caches, resubmit the exact canonical URL, and wait for recrawl. Rich result changes often lag behind successful indexing.
Passing validation on a fetched HTML snapshot does not prove Google indexed that version. Search Console’s live inspection and the chosen canonical usually reveal whether the markup is actually the one under evaluation.
Follow this order before waiting for stars
Most cases clear up once the checks happen in the right order: indexing first, then rendered markup, then eligibility. Confirm the intended URL is canonical, indexable, and actually recrawled. Next, compare page source, rendered HTML, and Rich Results Test output to catch cache, optimization, or plugin conflicts. After that, inspect whether one clean review node remains, tied to the correct entity and supported by visible rating evidence on the page.
If everything validates and still no stars appear, the issue is usually not missing schema but Google withholding the enhancement. At that point, improving page fit and waiting for recrawl is smarter than adding more markup.
About The Author
