Google Shopping shows the wrong color or size? Check the product link first

AISEO Site · Prepared 11 September 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.

Now imagine both records point to /products/jacket, which always opens with Black / S selected. The catalog may correctly describe two items, but the link does not preserve the customer's choice.

Ask your developer to demonstrate a link that opens Blue / M directly. A store might use a query parameter, a variant identifier or a separate path. The spelling of that URL is less important than the result: opening it without an existing shopping session must produce the intended selection.

Google's Merchant Center guidance says the submitted link should lead to the product being advertised; for variants, the appropriate variation should be selected. Check the actual value being submitted rather than assuming your store's share button produces the same link. Google's product link requirements.

Repeat the test on a phone. Add the item to the cart without completing a purchase. Record the cart SKU and options, then remove the test item. Do not use a successful page load as proof that the correct item can be ordered.

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 what the page tells search engines

The visible selector is only one representation of the item. Ask your developer to inspect the product structured data returned for the affected link as well.

Google supports ProductGroup for describing a family and Product for its variants. Its documentation includes both single-page selectors and multi-page implementations. The appropriate model depends on how the storefront actually works; a store does not have to create a new independent content page for every size. Google's product variant structured data documentation.

Keep the implementation review focused. Ask the developer to show which entry represents the affected SKU, how its options are described, and which offer belongs to it. Then compare that explanation with the shopper test you recorded.

A structured-data test passing does not prove that a color selector, image switch or cart action works. Conversely, a selector that works in your usual browser does not prove that a fresh visitor receives the same selection. You need both checks, and neither guarantees a particular Google result.

Fix the owner of the field, not every copy

Write down where the affected value originates. It might be maintained in the store, imported from a product information system, transformed by a feed app or overridden in a downstream rule. Those are possibilities to investigate, not assumptions about your setup.

Ask one practical question: If we correct this field here, what will happen at the next scheduled import?

If nobody can answer, pause the broad edit. A change that disappears overnight is not a finished repair. Agree on the authoritative value, the transformation that must preserve it and the person responsible for verifying the next run.

For a first repair, keep the scope small: one product family, the affected item and a working sibling as a control. Save the old records and template version. Correct the proven problem, then repeat the same link-to-cart test. Expand the change only after that test succeeds.

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.

If your team keeps repairing the same records in several systems, bring one product family and its publishing path to a working session with AISEO Site. Start with the real mismatch, the systems involved and the evidence you have. Our integration overview explains the questions to resolve before connecting another tool.