What your Product structured data needs for Merchant Center

Your Product structured data has to say what the page says: the same price, currency and stock, in the HTML your server sends. Merchant Center’s own help makes that a condition, not a tidy-up. Generate the markup from the same fields as the page and it stays right. Type it into the theme by hand and it goes stale the first time a price moves.

Major5 min read

By Edvinas Ivanauskas How the guides are reviewed

Why this matters

Google's “Set up structured data for Merchant Center” page lists the conditions for matching your markup to your product data, and three of them carry most of the weight. “Structured data markup must be present in the HTML returned from the web server. The structured data markup can’t be generated with JavaScript after the page has loaded.” “Your landing page content, including pricing, must not dynamically change based on user information such as IP address or browser type.” And: “Structured data must match the values that are shown to the user. Providing incorrect data on your product landing pages is a violation of our web developer guidelines.”

The same page gets specific about the offer. “Note that the price must be specified with a period as a decimal separator, instead of a comma.” During a sale: “If a sales price is shown on the landing page and this price is what a user would actually pay at that time, make sure the sales price is provided in the structured data.” A page showing several variants needs each offer tagged with a SKU or GTIN that matches the [id] or [gtin] in your product data. Google's “Merchant listing structured data” documentation adds the required fields (name, image, and an Offer with price and priceCurrency) and a detail that catches free-sample pages out: “Unlike product snippets, merchant listing experiences require a price greater than zero.”

Why bother, when your product data already carries the price? Because Google's “About structured data markup for Merchant Center” page ties markup to automatic item updates, and says “Automatic item updates reduce the risk of account suspension and item disapproval due to price and availability mismatches.” It is a backstop, not a feed: “Automatic item updates aren't a replacement for providing regular updates to the Merchant Center product data.” Markup that disagrees with the page does not help you there; it is one more place for the price to be wrong.

The free scan reads the Product markup on your product pages. It reports a markup price, currency or stock status that contradicts the visible page as a failure, and flags markup with no price, currency or availability at all. For testing the markup yourself, see how to validate your product structured data; for the stock side, availability in Merchant Center. The full list of page checks sits on the misrepresentation checker.

Typical evidence

A price you declared, in a contract, that the page contradicts

Schema isn't decoration — it's an assertion. You're telling Google in a structured contract exactly what the product costs. When the schema says one price and the page shows another, the disagreement itself is the problem, regardless of which number is 'right'.

product page · application/ld+json

"@type": "Product",

"offers": {

  "@type": "Offer",

  "price": "24.99",

  "priceCurrency": "GBP",

  "availability": ".../InStock"

}

schema declares

£24.99

≠

page charges

£29.99

Generate schema from the same CMS field that renders the page, so a price change writes both in one go. If they share a source, they physically can't drift apart.

The public signals this check looks for:

A price change updated the product page, but the markup still carries the old price becaus…
A price change updated the product page, but the markup still carries the old price because someone typed it into the theme at launch.
The markup says “InStock” while the page says sold out, or the other way round after a res…
The markup says “InStock” while the page says sold out, or the other way round after a restock.
The page shows a sale price the shopper pays, and the markup still shows the full price
The page shows a sale price the shopper pays, and the markup still shows the full price.
The price is written “29,99” with a comma, or with a currency symbol inside the price fiel…
The price is written “29,99” with a comma, or with a currency symbol inside the price field.
An app injects the Product markup with JavaScript after the page loads, so the HTML your s…
An app injects the Product markup with JavaScript after the page loads, so the HTML your server returns has none.
Two apps each print a Product block, and the page carries two prices that disagree
Two apps each print a Product block, and the page carries two prices that disagree.
“priceCurrency” says USD on a store that sells in pounds
“priceCurrency” says USD on a store that sells in pounds.

What it looks like once it is right

The theme prints one Product block from the live product record: “price”: “24.00”, “priceCurrency”: “GBP”, “availability”: “OutOfStock”. When the item is restocked and the sale ends, page and markup both change with the same save.

Common mistakes

Common mistake

The page shows £24.00, reduced from £30.00, and “Sold out” in grey. The Product markup, typed into the theme two years ago, says “price”: “30,00”, “priceCurrency”: “USD” and “InStock”. Three fields, three contradictions, all invisible to the owner.

Fix checklist

Pick three product pages: one at full price, one on sale, one sold out. Open each with view-source (not the browser inspector, which shows the page after scripts run) and find the block that starts with “@type”: “Product”.
For each one, write down name, price, priceCurrency and availability from the markup, then what the page shows. Any difference is the fix list.
Generate the markup from the same product fields that render the page. On a hosted platform that usually means the theme’s own markup or one structured-data app, not both; switch the duplicate off so each page has one Product block.
Make sure the markup is in the HTML the server returns. If a tag manager or app adds it after load, move it into the theme template, as Google's Merchant Center setup page asks.
Use a period for decimals, the three-letter currency code (GBP, EUR, USD) and a schema.org availability value such as “InStock”, “OutOfStock”, “PreOrder” or “BackOrder”. Keep the price above zero.
When a sale is live, put the price the shopper pays in the markup's price. When it ends, the markup should change the same minute the page does.
If one page shows several variants at different prices, give each offer its SKU or GTIN, matching the [id] or [gtin] you send to Merchant Center.
Leave automatic item updates switched on in Merchant Center as a backstop, and re-test three pages after every theme update, app install or bulk price edit.

Reconcile the contract against the page, field by field

Every key value in the Product schema is an assertion the page has to honour. Line them up — price, availability, currency, condition — and the row that doesn't match is the misrepresentation signal.

schemapage

price24.9929.99

priceCurrencyGBPGBP

availabilityInStockIn stock

conditionnewnew

One stale field can create a public mismatch. Generate schema from the same source as the page, then verify the rendered result after price changes.

Copy this, and change the parts in your own words

"@type": "Product",
"offers": {
  "@type": "Offer",
  "price": "29.99",
  "priceCurrency": "GBP",
  "availability": "https://schema.org/InStock"
}

Questions merchants ask

Does Google Merchant Center require Product structured data?

Not for every setup: the product data you submit is the main source. But Google's Merchant Center help says valid markup enables automatic item updates, which reduce the risk of account suspension and item disapproval due to price and availability mismatches. If you use markup, it must match the values the shopper sees.

Can I add Product markup with JavaScript or a tag manager?

Not for Merchant Center matching. Google's “Set up structured data for Merchant Center” page says the markup must be present in the HTML returned from the web server and can’t be generated with JavaScript after the page has loaded. Put it in the theme template instead.

Which price goes in the markup during a sale?

The price the shopper actually pays at that moment. Google's setup page says that if a sales price is shown on the landing page and it is what a user would pay, the sales price belongs in the structured data. Change it back when the sale ends.

JSON-LD, Microdata or RDFa?

Google supports all three and recommends JSON-LD, and the Merchant Center setup page does too, because it sits apart from the visible code and is easier to maintain. What matters more is that it does not drift from the page.

Remediation

Risk signal

Markup is the one part of the page nobody looks at, so it is the part that goes stale first. Generate it from the live product fields, keep it in the first HTML response, and let the free scan show you which pages disagree with their own markup.

PriorityAddress and document this finding as part of the store’s remediation work.

EvidenceRecord the current state before each change, apply the fix, then capture the corrected state so every change is evidenced.

Similar cases

Sources

Last reviewed 29 Sep 2026.

That is one issue. The library documents 134.

The free scan lists what it finds on your store. The paid report adds the affected pages, captured evidence and step-by-step fixes. Start free, with no account needed.