Structured data should describe the offer a buyer can actually see

Compare one offer in one observed page state

Start with a real public page and a dated observation. Record the product and selected option, the displayed currency and any visible conditions attached to the offer. Have the person responsible for the site identify the structured claims actually published for that page state. A plugin settings screen or a proposed markup file is not evidence of what the public page currently emits.

Keep the visible counterpart beside each structured value. If the value belongs to another option, another product or an earlier offer, mark the scope difference. If the claimed value has no relevant visible counterpart, record that absence. Do not add visible copy simply to justify an unsupported machine-readable assertion. The underlying offer must be accurate first.

Read price, availability and ratings as different claims

For a price, compare the amount and currency with the exact offer it describes. Preserve visible conditions that affect its meaning, including the selected option and whether the page describes a range or a single price. A lower value attached to a different option cannot establish that the currently selected option costs that amount. This check identifies a meaning mismatch; it does not prescribe which structured-data property a particular page must use.

For availability, compare the published machine-readable state with what the page currently tells a visitor about obtaining that item. Tie the comparison to the catalog or inventory record used by the store and its observation time. If the visible page and markup both repeat an outdated stock statement, agreement between them does not establish current availability.

For ratings, identify what is being rated and which underlying reviews the summary represents. Compare any rating value and count with the visible summary for that same subject. A store-wide rating is not evidence of a rating for a particular product. A field supplied automatically by a tool still needs genuine supporting records; missing evidence is not permission to invent reviews or counts.

Separate an accurate claim from valid markup

Google’s structured data guidelines require accurate representation of visible, relevant content and current information. They do not make hidden, irrelevant or misleading assertions acceptable because the markup parses. A syntactic check can help locate a formatting problem, but the page and the evidence are what let the merchant assess whether the assertion describes the real offer.

The FTC’s truth-in-advertising guidance states the general expectation that advertising be truthful, nonmisleading and substantiated across media, including the web. Use that guidance here as a reason to retain evidence for the claims being compared. This worksheet does not decide the legal status of a particular phrase or whether a specific implementation complies with law.

Google also says valid markup does not guarantee a rich result, and type-specific rules still apply. This comparison does not establish Product-specific required properties or eligibility for a research-only catalog. Matching the visible page closes only the particular consistency finding; it does not establish search demand, ranking, traffic or provider approval.

Correct the source of the mismatch and record the published result

For each discrepancy, identify the place that supplies the structured value and the place that supplies the visible claim. Ask the responsible editor or developer to trace those values to their evidence. The needed change may be to the structured assertion, the visible content or the underlying catalog record; choose from the documented discrepancy, not from whichever output is easiest to edit.

Keep a dated record of the claim before the change, the correction and the published values afterwards. If the public page still emits the old assertion, an edited admin field has not closed the finding. If the evidence remains missing, mark the claim unresolved and have its owner decide how to correct or withdraw the unsupported assertion.

For a Prism website-review consultation, provide the public URL, the research-only product category and a concise description of the mismatch you want examined. Ask for the structured and visible surfaces to be included in the agreed scope. Prism’s published storefront-review support does not itself promise implementation or search outcomes; scope, fees and terms are discussed before work. The inquiry receives email follow-up and does not book an appointment or buy a service.

Structured-claim comparison

Use one copy for each actual page state and keep a separate entry for every claim you compare. Fill the last column with the observed values, dated evidence reference and a result of match, mismatch or unresolved. A match requires both the same meaning and supporting evidence; it is not a rich-result or legal eligibility finding.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.