A price changed: which version does your product markup show?
After a price change, compare the selected offer in the initial HTML, the rendered page and the product markup. Record the time, variant and currency so that an apparent mismatch can be investigated.
Compare three representations of one selected offer
Imagine a fictional product whose confirmed price has changed from 80 to 72 euros. The initial HTML still contains 80, a script changes the visible page to 72, and the JSON-LD continues to describe the older amount. A screenshot shows the new price, but it does not reveal the disagreement between the representations.
Start with the exact product variant and market. Save what the server returns, inspect the page after rendering and examine the structured data attached to that selection. Do not compare a parent product in one representation with a variant in another.
| Representation | What the observation establishes | What it does not establish alone |
|---|---|---|
| Initial HTML | The content returned before client-side changes | The final rendered interface |
| Rendered page | What that browser session displays | What every crawler received |
| Structured data | The machine-readable offer declared there | Its agreement with the source catalogue |
| External search result | What was displayed in that observation | The current state of every representation |
These are separate evidence items. Their disagreement is the diagnostic clue, not a reason to choose whichever value is most convenient.
JavaScript is not a substitute for checking delivery
Google documents ways to generate structured data with JavaScript. The existence of that support does not show that a particular page's generated data is correct or that every retrieval system executes the same code.
Check the actual output and the tools appropriate to the destination. If the price depends on a market selector, record that state. If the page updates the visible amount after an asynchronous request, inspect whether the structured representation follows the same confirmed offer.
A valid JSON-LD block can still describe an obsolete price. Syntax and required-property checks address the shape of the data; they do not know which commercial value your business currently authorises. That value must come from the catalogue or another designated source.
Locate the first stale value before patching the template
If the source data is old, a presentation change will not fix it. If the data is current but one template reads an outdated field, changing the catalogue may create unnecessary work. Trace the selected offer through the data request, template and rendered output.
Keep the observation small enough to repeat. Use one affected variant, its final URL and the relevant request context. After correction, compare the same representations again. Then check a neighbouring variant to detect a fix that accidentally hard-codes the example's value.
The final report should identify which layer was stale and which observation confirms the correction. A later change in a search result can be recorded separately, with its date. It should not be treated as an automatic consequence occurring at a guaranteed time.
Look for competing sources
A theme, an application and a custom script may each contribute product information. The presence of several blocks is not enough to diagnose an error: inspect whether they describe different entities or contradictory versions of the same offer.
Trace the outdated value to its owner. If a cached response is involved, retain the response evidence. If a script reads a separate data source, compare the revision and update process of that source.
Do not remove markup simply because it is duplicated in the source. Determine its purpose and relationships first, then prepare a targeted correction.
Validate meaning as well as syntax
A structured-data test can identify supported fields and some errors. It cannot decide whether the declared price is the price the merchant intends to charge.
Use Google's product documentation for the relevant requirements, then compare the actual values with the selected offer. The Verity Score Schema.org reference is additional reading for a Shopify context, not a substitute for this comparison.
Report each result separately
Your record should distinguish a corrected template, an updated public response and a later observed search result. These are different states with different evidence.
If the public page is consistent but the external result remains stale, retain that finding without asserting a refresh deadline. Recheck with the same offer context when new evidence appears.
Keep the failing offer in a regression check for the next price or template update. The incident record should identify which source was stale, who corrected it and what the public page returned afterward.
The structured-data overview explains how product facts are represented. Here, trace the changed price through each representation.
