A testimonial is evidence before it is markup
Before generating review schema, establish who provided the statement, what it reviews, whether you can publish it, and whether the page is eligible for the intended search feature. Structured data should describe supported visible content. It should not turn a vague compliment into a numerical rating or an independently verified result.
Google's 24 July update added review guidance concerning fake and undisclosed incentivised reviews. The practical implication for a content workflow is straightforward: record provenance and relevant disclosures before a language model formats the material.
Keep the original beside the publishable version
A review record should include the original text, date, author identity as permitted for publication, reviewed service or item, source, publication permission, and any incentive. Keep private contact details out of the public page. Give the record an identifier so the website entry can be traced back without exposing the underlying correspondence.
If a client approves a shortened quotation, retain the approved version and the decision. Do not ask AI to make the customer “sound more enthusiastic.” If a sentence is your summary of feedback, label it as a summary rather than placing it inside quotation marks.
Check the reviewed entity and feature eligibility
Google's review-snippet documentation restricts self-serving reviews for LocalBusiness and Organisation, including situations where the reviewed entity controls reviews about itself. A third-party widget on that entity's own page does not automatically solve the problem.
A genuine testimonial can remain useful to readers without qualifying for review stars. Do not label a consultancy as a product simply to pursue another markup path. Choose types that accurately describe the real item, and check the requirements for that type.
Put decisions before generation
| Gate | If it fails |
|---|---|
| Original statement and source recorded | Return to collection; do not fabricate evidence |
| Publication permission and disclosures resolved | Keep the record out of the publishing queue |
| Reviewed item and eligibility confirmed | Use appropriate visible content without unsupported review markup |
| Rating supplied rather than inferred | Do not manufacture a score from positive language |
| Markup matches visible content | Correct the discrepancy before release |
This is a proposed workflow. It lets AI help with classification and formatting while keeping evidence and approval in ordinary records. A reviewer should resolve ambiguous entity types or permissions before the publishing step.
Validate the page, not just the JSON
Check the rendered page, structured data, and source record together. Syntax validation can find a malformed field; it cannot prove that a customer made the statement or that the page meets every quality guideline. A valid result is also not a guarantee of search appearance.
Plan for corrections and withdrawn permission. Locate every page using a review identifier, update the visible text and markup together, and retain an internal change record. If your content pipeline currently moves testimonials straight from a document into schema, a workflow review can establish these checks before output scales.
Link Map
Sources and editorial review
Sources reviewed on 14 September 2026. The practical workflows and illustrative examples are JQ AI SYSTEMS analysis unless explicitly attributed.
- Google Search Central: Review snippet structured data (Current documentation, reviewed 14 September 2026).
- Google Search Central: Documentation updates (Relevant entries: 24 July, 28 August and 8 September 2026).