Structured data should describe the product and offer that actually exist on the page. Build the visible explanation first, then map its verified facts into the appropriate markup. A markup generator cannot resolve an unapproved price, invent customer reviews, or decide what a product includes.
Use a claim ledger to connect each field with its visible source and owner. That makes the work reviewable when pricing, availability, or product names change. It also reveals a common problem: the markup and page can each look plausible while disagreeing with one another.
Google's structured-data policies, checked September 9, 2026, require a faithful representation of page content and prohibit misleading or hidden claims. Correct markup does not guarantee a rich result. The Product snippet documentation separately defines the relevant properties and eligibility requirements.
Use a small fictional example
Imagine a real product page being prepared for a fictional hardcover notebook named Field Notes Workbook. Its visible copy says that the notebook costs USD 24 and can currently be purchased. The following is illustrative JSON-LD data for that hypothetical product, not a live StackM offer or a complete commerce implementation.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Field Notes Workbook",
"offers": {
"@type": "Offer",
"url": "https://example.com/workbook",
"price": "24.00",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock"
}
}An implementation would place the verified data in an application/ld+json script element on the actual product page. The example.com address is a placeholder. Replace the fictional values with approved product records; do not publish this example as your own offer.
For Product snippets, Google's documentation requires a product name and at least one of offers, review, or aggregateRating. The example uses an offer, so it does not manufacture a rating to fill an optional-looking gap. Additional requirements differ across search features, including merchant listing experiences.
Review every field against the page
The product owner should be able to point to the evidence for each claim. If the page says “pricing coming soon,” an active USD 24 offer would contradict it. If the item cannot be purchased, an available offer is not an accurate description simply because someone hopes to sell it later.
| Markup field | Visible or operational evidence | Change owner |
|---|---|---|
| name | Current product heading and approved catalog record | Product editor |
| price and currency | Displayed amount and matching purchase configuration | Commercial owner |
| availability | The actual purchase state described to customers | Operations owner |
| url | The correct product destination | Site maintainer |
Put proposed information in the internal ledger with a proposed status. Do not silently promote it into customer-facing structured data. This is especially relevant when a marketing team is preparing a launch before the payment configuration or fulfillment process is ready.
Separate three different checks
First, check syntax: can the JSON be parsed and are the values structurally valid? This finds malformed commas, brackets, and data types. It does not determine whether the notebook exists or whether the price is approved.
Second, check the selected feature's documented requirements. A general schema vocabulary permits more descriptions than a particular Google search feature supports. Name the feature you are evaluating instead of treating all structured data as one interchangeable SEO setting.
Third, check truthfulness and consistency. Compare the visible page, product record, purchase destination, and markup. This review is necessary even when an automated validator reports no errors. Keep its evidence in the release record so a later price change can update every affected surface.
Avoid the tempting shortcuts
Do not generate five-star aggregate ratings for a product with no real review collection. Do not reuse another product's image or reviews because the template expects them. An empty evidence field should start a question or remove an unsupported claim, not trigger invented content.
Do not force a service, article, or unfinished product preview into this notebook example without checking the appropriate type and feature guidance. A schema example is a teaching aid, not a universal preset. The first question remains what the page actually represents.
If a product has multiple plans or variants, expand the model deliberately and review the applicable documentation. Copying the lowest proposed price into every page can produce a misleading picture even if the JSON itself remains valid.
Keep the markup in the content workflow
Whenever a product claim changes, update the ledger, visible page, purchase configuration where applicable, and structured data together. Record who checked the agreement between them and when. Review any remaining discrepancy before the release is called complete.
Use standalone product explanations to strengthen the visible source of truth. The outcome is a product page whose human-readable and machine-readable descriptions agree, with clear evidence for both. Search appearance remains an observed result, not a promise attached to passing a validator.