Google Shopping shows the wrong variant: what to check

AISEO Site · Prepared 11 September 2026 · Updated 10 October 2026

A shopper clicks a blue jacket in Google Shopping and lands on the black version. They switch the color, then discover that their size is unavailable. The product exists, but the buying journey has already broken its promise.

Start with the exact product link submitted to Merchant Center. Open it in a fresh browser session and check which color, size and image appear before you touch a selector. Then compare that selection with the individual item record, not just the parent product name. This separates a landing-page selection problem from an incorrect product record or an outdated image.

This guide is for stores selling genuinely related variations, such as one jacket in several colors and sizes. It is not a reason to group different products together or create a separate marketing page for every possible combination.

First, locate where the wrong variant appears

Before changing your catalog, save the link and a screenshot of the mismatch. Record the time, destination country and whether you were using a phone or desktop. You need a reproducible example, not a memory of what a result looked like.

Treat this table as a triage order, not a diagnosis of your store. A screenshot alone cannot identify the failing system.

Follow one SKU all the way to the cart

Use a specific combination as your test case. The following is an illustrative catalog, not a customer result or a real product offer.

Run the same link twice, without remembered choices

In this teaching catalog, both records currently point to /products/jacket, which opens Black / S. Save the actual submitted link for JACKET-BLU-M. Open that link in a fresh signed-out session before touching a selector. Record the first selection, main image, item price and availability.

If the submitted link has no variant identifier, request a supported link that opens Blue / M directly. If it already has an identifier, follow the redirects and compare the final URL. A redirect or URL cleaner that drops the selection can turn a correct feed link into a wrong landing page. If the final URL preserves the identifier but the page ignores it, investigate the selector's initialization.

Repeat with JACKET-BLK-S as a control. If both URLs select Black / S, the same default may be overriding both requests. If only Blue / M fails, compare that record's identifier, option mapping and stock state. These are checks to distinguish causes, not a claim about your store.

Verify the purchase handoff without placing an order

On desktop and a phone, add Blue / M to the cart and inspect the cart line's SKU and options. The page can select the right color while the cart submits a parent or default variant ID. Record that first disagreement and give it to the storefront owner. Remove the test item afterward.

If Blue / M is unavailable, do not silently substitute Black / S while retaining the blue offer. Check the exact item's availability and the store's intended unavailable-variant behaviour. Family-level stock cannot establish that every size and color is purchasable.

Google's product link requirements address the advertised product and selected variation. Use the value actually submitted to Merchant Center, not a share link that happens to work in your existing session.

Keep the family identity separate from the individual item

A shared family answers “which items are variations of this product?” An individual item answers “which exact combination is being sold?” Mixing those questions makes it harder to track a correction.

In Merchant Center, related variants use a shared item_group_id, while individual items have their own IDs and distinguishing attributes such as color and size. A shared group identifier does not replace those attributes. Follow the requirements for the product category and target country; do not invent a color or size simply to populate a field. Google's item group ID guidance.

For your internal handoff, request a small export containing the affected item and one correctly behaving sibling. Put their submitted IDs, options, links and image URLs next to each other. Comparing two concrete records is more useful than asking someone to “fix all variants.”

Do not rename every item ID as your first troubleshooting step. First identify which relationship is wrong and which system owns that field. Otherwise, you can lose your ability to compare the same item before and after the change.

Check identity in the page's product data

Ask the developer to identify the Product representing JACKET-BLU-M and the Offer attached to it in the affected URL's rendered data. Compare SKU or other genuine identifiers, color, size, image, availability and offer URL with the visible selection. A family name alone is too broad to identify this purchase.

Google's variant documentation supports ProductGroup relationships and individual Product entries for single-page and multi-page implementations. Choose the model that describes the real storefront. Do not create thin independent articles for every option or invent identifiers to satisfy a test.

A parser pass establishes a syntax check, not a successful selector or cart. Keep the markup check and shopper check together. Also keep Merchant Center item grouping separate from the site's canonical strategy: one group ID does not settle which page should be canonical.

Repair the first broken handoff and prove it persists

Choose the owner from the evidence. A wrong submitted identifier belongs with the data-source owner; a stripped parameter belongs with URL routing; a correct URL ignored on first load belongs with selector initialization; a correct page with the wrong cart item belongs with the add-to-cart handler. A wrong image may have its own variant assignment. Do not send every symptom to the feed team by default.

Keep the original item and a working sibling, plus the relevant template or rule version. Change the proven handoff, then repeat the two fresh-session tests and cart checks. Confirm the processed destination values if the submitted record changed. Wait through the next normal import before calling a recurring override resolved.

If all current records and shopping checks pass but one external listing remains stale, record that remaining display and its time. Source repair, processed record and public display refresh are three different acceptance states. Expand the repair to other families only when the same defect is established there.

A handoff your team can actually use

Send this checklist with the issue. Leave unknown values marked as unknown rather than guessing.

• Affected individual item ID and shared family ID.
• Expected color, size, image and availability.
• Exact link in the submitted product record.
• Screenshot immediately after opening that link in a fresh session.
• Selected SKU after adding the item to the cart.
• Product data source, relevant transformation and last processed update.
• One sibling variant that behaves correctly.
• Proposed owner, rollback copy and retest time.

Keep customer names, addresses and order details out of the ticket unless they are necessary and your team is authorized to handle them. A catalog problem can usually be demonstrated with a test selection rather than a customer's purchase.

Common fixes that miss the problem

Changing the title without testing the link. A more specific title cannot repair a page that opens with the wrong selection.

Replacing every image. First establish whether the wrong image belongs to the item record, the storefront selector or the particular result you saw. Keep a copy before replacing anything.

Testing only while logged in. Your browser may remember an earlier choice. Reproduce the first visit as well as a returning session.

Treating all sizes as available because one is in stock. Check the actual combination the shopper can add to the cart, not just a family-level label.

Calling a successful upload a finished repair. Verify the processed record, the destination and the cart separately. If the public result has not changed, record that as pending observation rather than declaring success.

Questions before you change the catalog

Do I need a separate page for every color and size?

Not automatically. Begin with your actual storefront design and whether a customer can open the intended selection directly. Decide URL and canonical behavior with your developer; do not duplicate pages solely to add more URLs.

Will adding ProductGroup make Google show every variant?

No. It helps describe the relationship between variants; it does not promise that Google will display every option, select your preferred photo or update a result immediately. It also does not repair an incorrect shopping link.

What if the page and product record already match?

Preserve that evidence. Note which result is still wrong, when the corrected record was processed and whether the problem can be reproduced. Investigate that remaining surface instead of repeatedly changing data that now agrees.

What if the variant is right but the price is wrong?

That is a different starting point. Use our guide to outdated product prices to compare the store, product details and Merchant Center price record.

Make the next catalog update easier to verify

Your goal is not simply to remove a warning. It is to preserve the same purchasable item from the listing to the cart, and to know who will notice if that stops working.

Keep the before/after item record, exact links, desktop/mobile selection and cart SKU in the issue. AISEO Site's subscription provides Search Console analysis and a daily email; catalog, feed and cart repairs require your authorized store team.