Variant prices in Merchant Center: matching every option

Every option with its own price needs its own item in Merchant Center, carrying the price the page shows once that option is picked. One price for the whole range stops being true the moment a shopper picks the XL. Send each priced option as its own row, give it its own link, and test a sample in a real browser.

Major4 min read

By Edvinas Ivanauskas How the guides are reviewed

You run this check yourself

Our scanner can’t see inside your Google accounts, so this one’s on you. Work through the checklist below without running a scan.

Why this matters

Google's [item_group_id] page spells out the structure: “Submit each variant as a separate product”, and “Use the same value for the item group ID [item_group_id] attribute for all variants of the same product.” The [price] page expects prices to differ where they really do: “If your product comes in multiple colors or sizes, you might also have different prices for each of these variants.”

The page then has to agree with each row. The item group page asks you to “Make sure that the product details displayed on your landing page match the variant-identifying values you provide for the variant”, and to “Make sure to have different landing page URLs submitted for each variant”. The [price] page adds “Display variants and their prices in a straightforward way on your landing page.” Google's landing page requirements close the last gap: “Do not change displayed product information after initial loading. This includes and is not limited to availability, pricing and the selected variant.” So a variant link should open with that option already selected and its price already showing, not settle on it a second later.

This is a manual check: compare each variant row in your product data with the page it links to. StoreVerifier does not open your feed or click through every option. What the free scan does is add a product to the basket and report a cart price higher than the product page as a failure, and flag structured-data prices that disagree with the price on the page. Feed-against-page prices in general are in product price: feed vs live page, and every pricing check is on the misrepresentation checker.

Typical evidence

Select the variant, read the real price

Check the selected variant in a normal browser and record the price shown. If you use a feed, compare that public price with the submitted variant price yourself; StoreVerifier does not access the feed.

Hoodie — product pageXL selected

SMLXL

page shows

£34.99

≠

feed submitted

£29.99

A single product-level price can be wrong for a variant. Test the selections a shopper can make, then correct the public copy and any submitted product data together.

The public signals this check looks for:

One price is sent for the whole product while S, M, L and XL cost different amounts on the…
One price is sent for the whole product while S, M, L and XL cost different amounts on the page.
Variant prices changed in the store and the feed still carries last month's numbers
Variant prices changed in the store and the feed still carries last month's numbers.
Every variant row links to the same product URL, so the page opens on the default option, …
Every variant row links to the same product URL, so the page opens on the default option, not the one advertised.
The page loads the default price and swaps in the chosen option's price a moment later by …
The page loads the default price and swaps in the chosen option's price a moment later by script.
A rounded or converted variant price on the page (£30…
A rounded or converted variant price on the page (£30.00) differs from the submitted value (£29.99).
A “build your own” or bundle product where the feed sends one component's price and the pa…
A “build your own” or bundle product where the feed sends one component's price and the page shows the total.

What it looks like once it is right

Four items, S to XL, share the item group ID HOOD-01. Each has its own price and a link such as /hoodie?variant=XL that opens with the XL selected and £34.99 showing. The basket says £34.99 too.

Common mistakes

Common mistake

A hoodie goes out as one item at £29.99. On the page the XL costs £34.99, and the link in the feed opens on the S. A shopper who clicks the ad for the XL sees one price, picks their size, and meets another.

Self-check steps

Download your product list from Merchant Center and sort it by [item_group_id]. Any product whose options differ in price but which has only one row is the first thing to fix.
Send each separately priced option as its own item, with its own [price] and the same [item_group_id] across the group, as Google's item group page asks.
Give each variant a landing page URL that opens with that option selected, for example through a ?variant= parameter if your platform offers one, and submit it in [link].
Open a sample of variant URLs in a private browser window and note the price the page shows on load, before you click anything. It should match that row's [price].
Add the same variant to the cart and check the cart price matches the page and the row.
Start with the products whose options differ most in price, since they carry the biggest gap when something drifts.
Keep variant prices in one place: generate the feed from the store through a channel app or scheduled export instead of retyping prices, and re-send it after every price change.
Write the check down: the date, the products sampled and any mismatch fixed, so the next pass starts where this one ended.

Each variant its own row, one shared group

An item_group_id ties the variants together while every row carries its own real price — so the price on the page always matches the price in the feed, variant for variant.

item_group_id = “hoodie-black”

hoodie-blk-S£29.99page matches

hoodie-blk-L£29.99page matches

hoodie-blk-XL£34.99page matches

Questions merchants ask

Do product variants need separate items in Merchant Center?

Yes. Google's [item_group_id] page asks you to submit each variant as a separate product and to give all variants of the same product the same item group ID. Each variant then carries its own price, availability and image.

Why is there a price mismatch when only one size costs more?

Usually the product was sent with one price for every size, or the link opens a different option from the one in the row. Google's landing page requirements ask for the page price to match your product data, so each priced option needs its own row and a URL that opens with that option selected.

Can a variant page change its price after it loads?

Google's landing page requirements say not to change displayed product information after initial loading, including pricing and the selected variant. The variant URL should open with the right option and its price already on screen.

Remediation

Risk signal

Variant pricing breaks quietly. A new size goes in at a new price, the feed keeps the old one, and nobody notices until a shopper does. One row per priced option, one URL per option, and a sampled check after every price change keep the page, the basket and Merchant Center telling the same story.

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 23 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.