Inventory the claims before editing markup
Open the software page and list the product name, supported environment, described features, offer and any displayed feedback. Record where each statement came from and who can confirm it. Separate released capabilities from planned features and a real customer review from promotional copy written by the product team.
Inspect the current structured data and the settings that generate it. Search for sample rating values left by a theme or copied example. Do not assume that a syntactically valid number has an evidential basis. Save the original output and the responsible configuration before making a correction.
Understand what the missing field means
Google’s software application rich-result documentation currently requires the app name, offers.price and either aggregateRating or review. That is an eligibility requirement for the feature, not permission to invent feedback. Its general structured-data guidelines also prohibit misleading content and fake reviews.
If the product has no qualifying rating or review, record that eligibility gap honestly. Omitting an unsupported claim may leave the item ineligible for the desired rich result. Do not replace the missing evidence with a zero score, a guessed average or a review attributed to a nonexistent customer.
Build a defensible feedback record
For any proposed review, retain its genuine source, the software it concerns, the displayed wording and the basis for publishing it. Check the applicable review guidelines before marking it up. A statement praising a company’s support is not automatically a rating of the application described on this page.
For an aggregate, document which eligible records contribute, the scale used and how the displayed count and score were derived. Investigate duplicates or mismatched products before using the total. This review worksheet is a practical control; it does not make an otherwise unsuitable source acceptable to Google.
Illustrative example: a new scheduling tool
Imagine a fictional scheduling tool with a published feature list but no customer ratings. Its template contains a sample five-star score. The editor removes the unsupported score and records that the software rich-result requirements are not currently met. The product page still explains the tool’s real capabilities and limitations.
A later piece of genuine feedback is reviewed on its own merits and against the relevant guidelines before any markup change. The team does not backdate it or convert an informal compliment into a numeric score. No customer quote, rating count or commercial outcome is asserted by this hypothetical example.
Verify honesty as well as syntax
After correcting the source configuration, inspect the public page and generated markup together. Ensure the removed sample has not survived in a second block, cached output or another language edition. Use the appropriate validation tool and preserve its result without describing a warning-free test as proof that every claim is true.
Assign an owner to review feedback when the page changes. Keep unresolved eligibility separate from a broken website: useful software information can remain available without invented stars. An audit can surface a suspicious field; the product and content owners must supply the evidence needed to decide whether that field belongs.