Variant Landing Page URLs in a Shopping Feed: link Rules

When you submit a catalog that contains product variants, every item in your feed needs a link attribute that points to the correct landing page. Getting this wrong is one of the quieter causes of Merchant Center disapprovals: the product data looks complete, but the URL either lands on the wrong variant or ignores the shopper's selection entirely. This article covers what Google requires, what it recommends, and how to apply both to your feed configuration.

What Google Requires for Variant Landing Page URLs

Google does not publish a separate link-specific attribute page for variants, but the requirement is embedded inside the item_group_id specification. The core rule is that your landing page must reflect the variant the shopper selected. Google documentation states: "Make sure that the product details displayed on your landing page match the variant-identifying values you provide for the variant like title [title], variant option [variant_option], color [color], price [price], availability [availability], and image link [image_link]."

This is a requirement, not a suggestion. If a shopper clicks an ad for a green T-shirt in size medium, the landing page must display that green medium T-shirt, not a generic product page that defaults to a different color or forces the shopper to re-select.

The same principle applies to variant_option. Google documentation confirms: "Make sure that the product details displayed on your landing page match the values you provide for the variant option [variant_option] attribute."

Both requirements mean that using a single parent product URL for every variant in a group is likely to cause a mismatch between what is advertised and what the shopper sees.

How to Structure the link Attribute for Each Variant

Google's best practice guidance is explicit about URL structure. According to Google documentation, you should "make sure to have different landing page URLs submitted for each variant, with each URL using a different path segment and/or query parameters, for example /t-shirt/green or /t-shirt?color=green&size=small or /t-shirt/preselect=8901491".

This means each row in a variant group must carry a distinct link value. The three acceptable URL patterns shown in the documentation give you flexibility depending on how your storefront is built:

• Path segment: /t-shirt/green — useful when your CMS generates a unique URL per variant.
• Query parameters: /t-shirt?color=green&size=small — common in Shopify and WooCommerce stores where variants share a base URL.
• Preselection parameter: /t-shirt/preselect=8901491 — used when the storefront accepts an internal variant ID to pre-select the right option on load.

For mobile_link, apply the same logic. If your mobile storefront uses a separate URL pattern (for example, an m. subdomain or a different path), provide the mobile-equivalent variant-specific URL for each item. There is no separate rule that allows a generic parent URL for mobile_link when a specific one is required for link.

How item_group_id and variant_option Interact with URL Grouping

The item_group_id attribute groups variants so Google can show them together rather than as unrelated products. The grouping rule and the URL rule work in opposite directions, which is a common source of confusion.

• All variants sharing the same product get the same item_group_id value.
• Each variant gets a different link URL.

Google documentation puts it this way: "Align grouping with your landing page experience: If your website allows customers to select between multiple variants on a single landing page (for example, a T-shirt available in different sizes or colors), make sure all those versions are submitted with the same item group ID [item_group_id]."

Note the qualifier: if your site uses a single landing page with a selector widget, one item_group_id still covers the group. But the URL for each submitted item must still resolve to the correct variant selection. That is why query parameters or preselection parameters matter: they let you use a shared base URL while still pointing each feed row to the correct pre-selected state.

The variant_option attribute adds structure. According to Google documentation, "Each variant with the same item group ID [item_group_id] attribute must have the same set of name [name] sub-attributes as the other variants in the product group." For example, if one row in your group carries variant_option with name: color and name: size, every other row in the group must also carry both name sub-attributes, even if the values differ.

Hypothetical Example: A Running Shoe Catalog

The following is a hypothetical example to illustrate the rules above. It does not represent a real merchant or measured outcome.

Suppose a store sells a running shoe available in two colors (Black, White) and two widths (Standard, Wide). That produces four variants submitted as four separate feed rows, all sharing item_group_id: SHOE-RX9.

Each row has a unique id, a shared item_group_id, a unique link with query parameters, and the same set of variant_option name sub-attributes (shoe_width) across all rows. The landing page for each URL must display the pre-selected color and width shown in the feed row. If the store also has a mobile URL, mobile_link would follow the same query-parameter pattern on the mobile domain.

This structure satisfies both the grouping requirement (same item_group_id) and the landing page match requirement (distinct, variant-specific URLs).

Common Mistakes to Avoid

Submitting the parent URL for all variants. If every row in a variant group points to /shoes/rx9 without parameters, the landing page will not pre-select the advertised variant. This creates a mismatch and can lead to disapprovals.

Using casing differences for item_group_id uniqueness. According to Google documentation, the values abc123 and ABC123 are treated as the same group, so do not rely on case to separate unrelated products.

Inconsistent variant_option name sub-attributes across the group. If one row omits a name that the others carry, the group fails validation. Keep the set of name sub-attributes identical across all rows in a group.

Recycling item_group_id values across product lines. Once assigned, an item_group_id should stay stable. Changing it disrupts how variants are grouped and displayed.

Getting variant URLs right is foundational to clean feed health. If you're managing a large catalog with dozens of variant groups, Magicfeedpro can help you map variant-specific URLs at scale, keep item_group_id values consistent, and catch landing-page mismatches before they reach Merchant Center diagnostics.

Related articles

feed optimization

item_group_id for Variants: Requirements, Value Rules, and Feed Impact

When item_group_id is required for color and size variants, what value rules apply, and what happens when it is missing or mismatched.

Sep 20, 2026·6 min

feed optimization

AI Search Is Reshaping Google Shopping: Feed for SGE in 2026

Google AI shopping feed optimization now hinges on 6 feed attributes that decide which products appear in AI Overviews carousels. Fix your feed in one pass.

Jun 12, 2026·11 min

feed optimization

Beyond Channable: When Rule-Based Feed Tools Hit a Ceiling

Channable alternative for Google Shopping: rule-based feed tools fail at scale in 5 predictable ways. See the real cost and what AI rewriting fixes in under a day.

Jun 7, 2026·12 min