PRODUCT VARIANTS IN THE FEED: AVOIDING GOOGLE DISAPPROVALS

Managing product variants in the Google Merchant Center feed is one of the most technical and most underestimated tasks in Shopping campaign management. An e-commerce with products available in different size, color, material, or other variant dimensions must communicate to Google not only the existence of the variants, but also their relationship to the base product, following precise rules that, if broken even partially, produce silent disapprovals.

The word "silent" is not incidental: Google Shopping disapprovals for variants often appear in the Merchant Center Diagnostics section without generating any alert in Google Ads campaigns. The budget keeps running, campaigns show as active, but the disapproved products have vanished from the carousel without anyone noticing until the next feed audit.

In this article I analyze the mechanism by which Google handles variants in product feeds, the required attributes, the most frequent errors, and the preventive practices that work on real accounts. The distinction between what official Google documentation prescribes and what hands-on experience reveals is systematic and, for this topic, particularly significant.

Why variants get disapproved: Google's logic

Google Merchant Center draws a clear line between a single product and a product with variants. When the system receives multiple items in the feed representing the same base product across different product options (color, size, material), it expects these variants to be declared as such through a specific set of attributes. If the declaration is missing or inconsistent, Google cannot build the correct product model and disapproves.

According to the official Google documentation on attributes for products with variants, the three main causes of disapproval for variants are: missing item_group_id, missing differentiating attributes, and non-unique IDs across different variants of the same product.

Formal disapproval vs silent data quality degradation

A distinction that official documentation does not describe clearly enough, but that emerges consistently from hands-on experience, is the one between formal disapproval and silent data quality degradation.

A formal disapproval removes the product from the carousel and search results, and marks it as "Not approved" in the Products section of Merchant Center. Silent degradation, on the other hand, leaves the product technically approved but reduces its visibility in auctions without any explicit signal. It shows up as a gradual impression decline on specific products, often wrongly attributed to bid or competitiveness factors, while the real cause is a variant data quality issue that Google penalizes without formally disapproving.

From hands-on experience on real accounts: silent degradation linked to variants is hard to identify without a structured feed analysis. The typical signal is an asymmetric impression drop across variants of the same product, some perform normally, others generate no impressions despite being "approved". The only way to diagnose it is to cross-reference the Merchant Center Diagnostics report with campaign performance data, checking whether products with falling impressions have incomplete variant attributes.

item_group_id: the core of variant management

The item_group_id attribute is the mechanism by which Google understands that multiple feed entries represent variants of the same product. Without it, the system treats them as distinct, independent products, with consequences both for disapprovals and for auction quality and the product listing in Google Shopping.

According to the official Google documentation on the item_group_id attribute, all variants of the same product must share the same item_group_id value, which must differ from the unique id of each individual variant.

Practical rules for item_group_id

Documentation defines the minimum requirements. Working with feeds containing thousands of SKUs reveals additional operational rules that documentation does not make explicit:

• Stability over time: the item_group_id value must not change between feed updates. If it does, Google loses the link between variants and starts treating them as new products, triggering a new verification cycle and often temporary disapprovals.
• Uniqueness per base product: the value must uniquely identify the base product. Using generic codes such as the color code instead of the base SKU can group variants from different products into the same group, creating inconsistencies Google cannot resolve.
• Separation from the variant id: item_group_id and id must be different values. The most robust structure is to build the id as a combination of the group plus the variant suffix: BASE-PRODUCT-RED-M, with item_group_id equal to BASE-PRODUCT.

Operational note: on a fashion e-commerce with 12,000 SKUs, the item_group_id had been built using the color code as a prefix instead of the ERP base SKU. The result: t-shirts, trousers, and jackets sharing the same color code were grouped as variants of the same product. Disapprovals for attribute inconsistency within the group, different gender values across items in the same "group", had hit 38% of the catalog. The fix required a full feed reimport with item_group_id based on the ERP base SKU.

Mandatory attributes for variants: official source vs practice

The official Google Merchant Center feed specification defines which attributes are mandatory for products with variants based on the product category.

What official documentation requires

For apparel and footwear, the attributes color, size, gender, and age_group are mandatory regardless of whether the variant is based on that differentiator. For all other verticals, color, size, and material become mandatory only when variants differ along that dimension. In all cases with variants, item_group_id is mandatory.

Documentation also specifies that the color value must be consumer-readable in the language of the target country, not technical codes like #C0392B or PMS 485.

Where practice diverges from documentation

Documentation describes the per-category requirements. In practice on real feeds, Google exhibits behaviors that documentation does not explicitly describe:

• A missing field in one variant can disapprove the entire group. If 9 variants of a product have color and the tenth is missing that specific attribute, Google can disapprove the entire group for inconsistency, not just the incomplete variant. This behavior is not documented as an explicit rule but occurs consistently.
• The product category declared in the feed determines which attributes get checked. A product categorized as apparel is verified against apparel vertical requirements even if the site treats it differently. Miscategorization in the google_product_category field is a frequent source of disapprovals for attributes that are formally correct for the wrong vertical.
• The "Data quality issues" tab shows problems that do not appear as formal disapprovals. Monitoring only the count of non-approved products is not enough: the Merchant Center Diagnostics section also shows issues that reduce visibility without formally disapproving, including many variant-related problems.

Common errors that cause cascade disapprovals

1. item_group_id changed between feed updates

This is the most frequent and most silent error. The feed uploads without visible errors, but Google loses the link between variants and starts treating them as separate products. Products that "were" variants but Google no longer recognizes as such get disapproved gradually. The signal is a slow decline in the number of approved products that is often confused with an inventory issue.

2. Identical title across all variants of the same group

If the title of each variant is identical (e.g. "Classic T-Shirt" for all sizes and colors), Google may interpret it as duplicate content. The official best practice is to include the differentiating value in the title: "Classic T-Shirt – Red – Size M". An identical title does not always cause a formal disapproval, but it reduces relevance for queries that include color or size, lowering the Quality Score and position in the carousel.

3. Same image for variants of different colors

Google discourages using the same image for variants of different colors. It is not always a direct cause of disapproval, but it significantly reduces the Quality Score and can trigger manual reviews. The image_link attribute should point to a color-specific image. Size variants of the same color can share the same image without issues.

4. Price or availability mismatch between feed and variant landing page

If the feed declares a size as available but the product page shows "out of stock" for that size, the user experience breaks down and Google disapproves the variant for landing page inconsistency. This is especially critical for e-commerce with real-time inventory and daily feed updates: in the gap between one update and the next, sizes that are out of stock on the site continue to show as available in the feed, a small, medium, or large size sold out hours ago may still appear buyable in Shopping. The most effective solution is the Content API for Shoppingfor incremental updates. Alternatively, increase the batch feed frequency to 6–12 hours.

5. Color value not in local language or in technical format

The color attribute value must be descriptive and consumer-readable in the language of the target country. For an English feed, "Burgundy Red" is valid; "PMS 485" or "#8B0000" are not, Google rejects or ignores them, effectively leaving the field empty, with all the consequences already described for missing attributes.

Prevention and monitoring: what actually works

Feed validation before upload

The most effective check is a pre-upload validation that verifies attribute consistency per group: all records with the same item_group_id must have the same mandatory fields filled in, the same gender and age_group values, and titles that differ by the differentiating value. A Python script or a data quality tool can run this check in seconds on feeds with tens of thousands of rows.

From experience: making this check a mandatory step in the feed update process, before the upload, not after, reduces variant disapprovals to near zero on accounts that previously logged them regularly. The time invested in pre-upload validation is consistently lower than the time spent diagnosing and fixing post-upload disapprovals. Beyond disapprovals, incomplete variant data also suppresses conversion rates: shoppers who find their size or color unavailable abandon the page without buying.

Weekly monitoring of the Diagnostics tab

The Diagnostics section of Google Merchant Center (Products → Diagnostics) shows both formal disapprovals and data quality issues that reduce visibility without disapproving. Check it at least once a week on active accounts. The "Data quality issues" tab is where variant-related problems that do not generate a formal disapproval appear, and those are the ones that silently hurt performance.

ID structure: the choice that matters most

ID structure is the technical choice with the greatest long-term impact on feed stability. The operational recommendation, regardless of the e-commerce platform, is to build item_group_id from the base SKU of the ERP or WMS system and the variant id as a combination of the base SKU plus the variant suffix. This structure survives site redesigns, CMS migrations, and ERP updates without requiring feed reimports. It also makes it easier for search engines to consistently associate variant listings with the correct base product over time.