--- title: "Review Schema in WordPress Blocks: Ratings Without Spam" date: 2026-03-09 author: "Imtiaz Rayhan" featured_image: "https://wpblocksuite.com/wp-content/uploads/2026/08/featured-review-schema-wordpress-blocks.png" categories: - name: "Block Editor" url: "/blog/category/block-editor.md" --- # Review Schema in WordPress Blocks: Ratings Without Spam Add review schema only for genuine visible reviews about one specific eligible item. Keep authors, rating scales, counts, and review text accurate. Never import invented stars. Valid markup creates possible eligibility. It never guarantees a review snippet. ## Understand what review schema describes Review markup describes an evaluation of an item. It identifies evidence, author, and rating. AggregateRating summarises several ratings. It needs a defensible score and matching count. Both models describe existing review content. They do not create social proof. ## Start with the reviewed item Identify one specific item clearly. A category or broad list usually lacks enough precision. Name, URL, image, and identifiers can establish identity. Use relevant properties only. Do not leave consumers guessing. Ambiguous item ownership weakens the entire graph. ## Check current eligible types Google supports review snippets for a defined set of item types. The [Google review snippet documentation](https://developers.google.com/search/docs/appearance/structured-data/review-snippet) lists current eligible types and required properties. Check that list before implementation. Schema.org permits broader vocabulary than Google supports. ## Recognise commonly eligible items Google currently documents books, courses, events, movies, products, recipes, and software applications. Specified CreativeWork subtypes can also qualify. LocalBusiness has important restrictions. Use the most accurate supported subtype. Do not choose Product for unrelated content. ## Understand Review A Review represents one evaluation. It can include an author, body, and rating. The review should be visible on the page. Readers need the evidence behind its score. A star icon alone is not meaningful commentary. Add genuine evaluation where appropriate. ## Understand AggregateRating AggregateRating combines multiple individual ratings. Its score must follow a documented calculation. Use `ratingCount` for ratings and `reviewCount` for written reviews. They can differ. Do not call one editorial score an aggregate. It represents one review. ## Define the rating scale State the score through `ratingValue`. Define `bestRating` and `worstRating` when needed. Visible text should communicate the same scale. “Four” without “out of five” can confuse. Do not convert scales silently. Document every normalisation rule. ## Calculate averages accurately Use the same eligible rating set for score and count. Exclusions need consistent policy. Round only for presentation. Preserve calculation precision according to your documented method. Recalculate after additions, removals, or moderation. Cached scores can become wrong. ## Keep rating counts current The visible count should match [structured data](https://wpblocksuite.com/blog/wordpress-blocks-structured-data-schema/). Deleted ratings must reduce both. Do not include imported counts from unrelated platforms. Their verification and scale may differ. Generate counts from one authoritative store. Avoid manually typed summaries. ## Show the rating visibly Users should see the score, scale, and relevant count. Stars need accompanying text. Do not hide the rating behind inaccessible hover content. Make the value available directly. Structured values should match visible values. Cosmetic rounding must remain understandable. ## Show genuine review text Review text provides context behind a score. It should reflect an actual evaluation. Google recommends a review comment and author for individual reviews. Do not generate generic praise automatically. Repetition looks artificial and provides little evidence. ## Identify the author honestly Use a valid person or organisation name. Avoid promotional sentences inside author fields. Anonymous display policies may limit public identity. Apply them consistently and transparently. Never invent identities to fill required data. Omit unsupported markup instead. ## Use review dates truthfully Show the actual publication date where appropriate. Modification dates need meaningful review changes. Do not refresh dates automatically. Artificial freshness does not improve evidence. Moderation approval and original submission may differ. Document which date appears. ## Avoid fake reviews Fake reviews violate trust and current Google guidance. Markup cannot make them legitimate. Google added explicit fake-review guidance during July 2026. Verification now deserves renewed attention. Collect real evaluations through controlled workflows. Preserve moderation evidence and audit trails. ## Disclose incentivised reviews Undisclosed incentives can mislead readers. Free products or payments require clear disclosure. Disclosure does not convert scripted praise into genuine evaluation. Review independence still matters. Follow applicable legal requirements too. Search documentation is not legal advice. ## Avoid self-serving business reviews Google restricts self-serving reviews for LocalBusiness and Organization entities. A business cannot control reviews about itself and expect review-feature eligibility. Embedding a third-party widget does not remove control concerns. Check current rules. ## Review other businesses accurately A publisher can review another eligible business or item. The relationship must remain clear. Identify the reviewed entity rather than the publisher. Avoid connecting stars toward yourself. Disclose commercial relationships. Editorial independence and structured accuracy support each other. ## Do not aggregate other websites Google says not to aggregate ratings from other websites. Publish ratings you collect directly. Copied marketplace scores can change without synchronisation. Their moderation rules also differ. Citing an external score in prose differs from claiming it as your aggregate. ## Avoid rating an entire category A review snippet needs a specific item. “Best hosting plugins” contains several candidates. Marking the list itself as one Product misrepresents its purpose. Use ordinary article structure. Individual item reviews may carry their own graphs. Avoid ambiguous nesting. ## Handle multiple reviewed items Several reviewed items need clear separate identities. Each score must attach correctly. Google guidance discourages unclear nesting and multiple item-identification methods. Prefer focused detail pages when rich-result eligibility matters. Comparison pages need careful modelling. ## Treat editorial reviews differently An editorial review reflects the publisher’s evaluation. Its author and methodology should be visible. Original testing and evidence strengthen usefulness. Schema alone cannot demonstrate experience. Explain drawbacks alongside benefits. A review without tradeoffs often reads like advertising. ## Treat user reviews differently User reviews require collection, consent, moderation, and abuse controls. Scores depend on that system. Preserve genuine criticism. Moderation should remove abuse, not inconvenient opinions. Publish transparent policies. Readers need confidence that counts reflect actual submissions. ## Moderate spam consistently Use documented rules for duplicates, abuse, conflicts, and unverifiable experiences. Automation can flag patterns. Human review may still be necessary for context. Update aggregates after moderation. Removed spam should not remain inside structured counts. ## Handle deleted reviews A deleted rating changes the eligible set. Recalculate scores and counts immediately. Clear page, object, and edge caches. Stale markup can outlive visible corrections. Retain internal audit records where appropriate. Public data should reflect current truth. ## Handle zero ratings An unrated item has no meaningful aggregate. Do not output zero stars as evidence. Hide AggregateRating until a real rating exists. Keep the review collection interface separate. Do not prefill a perfect score. Defaults must never become fabricated reviews. ## Handle small samples honestly One rating can produce a dramatic average. Show the count prominently. Do not imply broad consensus from sparse evidence. Let readers judge sample size. A minimum publication threshold can be reasonable. Document and apply it consistently. ## Use accessible star displays Star icons need a textual score and scale. Screen readers should receive concise meaning. Do not announce each decorative star separately. That produces noisy repetition. Colour alone cannot distinguish selected ratings. Use labels and clear states. ## Make rating controls usable Input controls need keyboard access, visible focus, and meaningful labels. Users should review their choice before submission. Provide error feedback without losing input. Touch targets need sufficient size and spacing. Test zoom and narrow screens. ## Prevent duplicate review graphs A review block, commerce plugin, and SEO plugin can all emit rating data. Their values may come from different stores. Contradictions become likely. Assign one owner per reviewed item. Disable redundant outputs on staging. ## Inspect the rendered output 1. Open the public item page. 2. Find every Review entity. 3. Find every AggregateRating entity. 4. Confirm the reviewed item. 5. Compare scores and scales. 6. Compare rating and review counts. 7. Check visible authors and text. 8. Identify every generator. Inspect original source and rendered DOM. Client-side widgets may add another graph. ## Validate the public page Use Google’s Rich Results Test for supported review snippet eligibility. Use Schema.org Validator for broader syntax inspection. Neither tool guarantees display. Test the production URL after cache purges. Snippet input cannot prove delivery. ## Follow general structured-data policies Markup must remain relevant, accurate, and representative. The page must remain crawlable. The [Google structured-data policies](https://developers.google.com/search/docs/appearance/structured-data/sd-policies) apply alongside review-specific requirements. Technical validity cannot rescue misleading content. Policy compliance remains essential. ## Do not promise AI preference Review markup does not guarantee AI citations or recommendations. No reliable contract supports that claim. Clear evidence and original analysis help readers. Search systems can also interpret useful content. Use schema for accurate entity description. Do not treat it as synthetic authority. ## Plan review plugin deactivation Review data may live in comments, custom tables, post metadata, or external services. Export ratings, authors, dates, moderation states, and item relationships before migration. Test what remains after deactivation. Visible reviews and schema can disappear separately. ## Add useful pros and cons Editorial product reviews can present positive and negative notes. Both need visible supporting analysis. Do not reduce a review into isolated slogans. Explain why each point matters. Google documents specific product snippet properties. Check current requirements before adding them. ## Handle product variants carefully A rating may describe one variant or the broader product. Make that scope explicit. Do not merge incompatible models, editions, or sizes automatically. Experiences can differ materially. Use stable identifiers for each reviewed item. Keep variant relationships accurate. ## Handle paginated reviews Review archives may span several pages. Aggregate counts should cover the declared collection consistently. Do not show different aggregates across pagination accidentally. Central calculations reduce drift. Keep item identity clear on every page. Test canonical and pagination behaviour. ## Collect consent and privacy appropriately Review forms can collect names, emails, and purchase evidence. Explain their use clearly. Publish only agreed fields. Internal verification data need not become public. Follow applicable privacy requirements. Structured markup can expose public data broadly. ## Verify review eligibility consistently Purchase verification can strengthen context. It should not silence legitimate non-purchaser experiences automatically. Define which interactions qualify. Apply the same rule across positive and negative submissions. Label verified status accurately. Never imply stronger verification than performed. ## Provide moderation appeals Legitimate reviewers may dispute removal. A documented appeal route improves moderation accountability. Record reasons and decisions. Do not restore spam merely after pressure. Update public counts after final outcomes. Preserve appropriate internal audit records. ## Control automated abuse Rate limits, validation, and behavioural signals can reduce automated submissions. Challenges must remain accessible. Do not block legitimate keyboard or assistive-technology users. Automation never replaces moderation policy. False positives require review and correction. ## Localise ratings accurately Translated review text should preserve meaning. Scores and item identity must remain consistent. Decimal presentation varies by locale. Structured numeric values still need valid machine syntax. Test every language page independently. Avoid untranslated author or disclosure labels. ## Preserve calculation snapshots Store enough history to explain unexpected score changes. Counts alone may not diagnose problems. Snapshots can support moderation audits and migrations. Protect personal data appropriately. Do not publish internal evidence needlessly. Public output should remain concise and accurate. ## Monitor production values Sample important item pages regularly. Compare visible and structured scores automatically where possible. Alert on impossible counts, invalid scales, and missing item identities. Investigate every alert. Retest after commerce, review, SEO, and cache updates. Any owner can change output. ## Know when review schema adds little Weak, imported, or unverifiable ratings create more risk than value. Leave them unmarked. An honest review can still help readers without stars. Evidence matters more than decoration. This is the honest weak case. No rating beats manufactured consensus. ## Use the review schema checklist 1. Identify one specific reviewed item. 2. Check current type eligibility. 3. Choose Review or AggregateRating. 4. Define the rating scale. 5. Calculate scores consistently. 6. Keep counts current. 7. Show ratings visibly. 8. Publish genuine review evidence. 9. Identify authors truthfully. 10. Disclose incentives clearly. 11. Avoid self-serving markup. 12. Never aggregate other websites. 13. Moderate spam consistently. 14. Remove duplicate generators. 15. Validate the production URL. 16. Plan data portability. ## Frequently asked questions What is the difference between Review and AggregateRating? Review describes one evaluation, while AggregateRating summarises several ratings. Can a business mark up reviews about itself? Self-serving LocalBusiness and Organization reviews are ineligible under Google’s rules. Can I aggregate ratings from another website? No. Google says sites should not aggregate ratings from other websites. Does valid review schema guarantee stars in Google? No. Valid compliant markup creates eligibility, while Google controls displayed results. Should a new item start with five stars? No. Publish only ratings based on genuine received evaluations. ## The verdict Verdict **Start with evidence:** genuine visible reviews must support every marked rating. **Protect trust:** identify one eligible item, maintain accurate counts, and reject manufactured consensus. Core blocks can present editorial reviews. Try free review tools for basic collection. Then [compare the $299 lifetime suite](https://wpblocksuite.com/#pricing) when several Pro blocks fit maintained sites.