Key Takeaway
Incorrect splitting or merging of variants often reflects inconsistent relationships among product families, saleable variants and offers. Give each actual variant a stable SKU or item ID, legitimate GTIN or MPN where available, an accessible URL and its own price and availability. Use Google's ProductGroup/productGroupID and the OpenAI feed's group_id or compatible item_group_id field to identify the common parent group, without confusing family and variant IDs. Keep visible content, canonicals, schema, PIM and feeds consistent. These measures support reliable data processing, not guaranteed rich results, ChatGPT listings, recommendations or sales.
Facts and background
The Google product-variant guidance reviewed as of August 19, 2026 recommends ProductGroup and variesBy,hasVariantandproductGroupID for parent-and-variant relationships. The cited OpenAI feed specification represents a product or variant per row and defines item_id as a unique, stable merchant item identifier. Field names differ, but a group ID must not replace a variant ID, and variant facts should not exist only in images, selectors or an internal ERP.
Separate product families, variants and offers
| Level | Question answered | Google pages and schema | OpenAI product feed | Do not confuse |
|---|---|---|---|---|
| Parent product group | Which SKUs belong to one product family? | ProductGroup,productGroupID,variesBy | group_id; Google-compatible feeds can use item_group_id | A parent group ID with each variant's unique SKU |
| Saleable variant | Which specific color, size, material or configuration? | Product,sku,gtin,isVariantOforhasVariant | item_id,gtin/mpn,variant_dict and attributes such as color and size | Distinct variants must not share one variant ID |
| Merchant offer | Who sells it, in which market and on what terms? | Offer URL, currency, price, availability and policy fields | URL, price, availability, market and merchant fields | Changing price or seller terms must not redefine permanent product identity |
The cited OpenAI Google-compatible feed documentation maps item_group_id to group_id and treats the item as having variants. When absent, it uses id as the group ID for a single listing. Each row still needs a distinct id as its stable product or variant ID. Maintain both group and variant identity, not only one.
Single-page and multi-page variants need different URL strategies
Google supports single-page variant selectors, including query parameters that preselect a variant, and multi-page designs with separate variant pages. Each intended variant should be identifiable by an appropriate URL whose price, availability, image and attributes match the selected state.
Canonical policy must follow page architecture. Optional variant parameters on one shared page can canonicalize to the parameter-free page, while genuinely distinct indexable variant pages need stable, discoverable URLs and an appropriate canonical strategy. A variant-specific feed URL and a shared parent canonical can be legitimate; the problem is an unexplained conflict between independent-indexing goals, page content and data attribution, not that combination by itself.
Use one identity map across pages, markup and feeds
Maintain an auditable PIM or product-source-of-truth mapping for group ID, variant ID, SKU, GTIN, MPN, brand, variation dimensions and values, official URL, canonical, primary image, market, currency, price, stock and update time. Google's productGroupID and OpenAI's group_id/item_group_id need not share field names but must represent the same parent relationship. Google's sku and OpenAI's item_id likewise need not be identical strings, but must map consistently and traceably to internal master data.
GTIN and MPN support cross-source matching but must not be invented. The cited OpenAI compatibility specification states that when identifier_exists is omitted or set to yes, a valid GTIN or nonempty MPN is required; set it to no only when identifiers genuinely do not exist. Never reuse another variant's GTIN or disguise an internal group number as a global identifier. Preserve a stable SKU and accurate manufacturer identity when external identifiers are genuinely absent.
Market and language changes do not redefine the product
The same physical variant may have different languages, currencies, prices, stock and delivery or return terms across markets. Titles can be localized, but keep item ID, SKU, GTIN and MPN traceable rather than changing permanent product identity with translation or campaigns. Different packaging, plugs, capacities, certification versions or bundles may represent genuinely different variants and should not be merged merely because names resemble each other.
B2B variants may differ by voltage, power, connector, material, certification market or configuration. Google's documented variesBy support is limited; arbitrary internal fields are not automatically supported schema properties. Explain complex configurations in visible tables, comparisons and quotation checks. Use supported feed attributes or variant_dict where applicable, without replacing buyer-visible configuration boundaries.
Validate the complete variant workflow
Do more than pass Rich Results Test. Select one parent and all saleable variants, reconcile group and variant IDs, URLs, attributes, prices and stock across PIM, pages, markup and feeds, then check default, preselected and independent-page states and canonicals. Verify parseable structured data and crawlable variant links using <a href>, include only intended indexable URLs in sitemaps, and inspect feed-processing results for correct grouping.
After release, separately verify crawling, indexing, feed acceptance and actual product display. One does not prove the next. Reprocessing takes time, and neither Google nor OpenAI documentation guarantees display or recommendation for every compliant item.
Impact on enterprises
First, independent IDs generated by websites, dealers and feeds increase reconciliation costs with each market and channel. Shared parent, variant and identifier mappings reduce splitting, merging and stale records. Second, price and stock errors may arise from identity collisions, not only sync delays. Shared variant IDs can overwrite another item's facts, while frequently changing IDs can create duplicate history. Third, canonicals, variant landing URLs and analytics need an explicit mapping. A parent canonical and parameterized feed URL can be valid, but reporting must retain variant identity rather than confusing every parameter with an independent product. Fourth, B2B pages must distinguish configuration-defining properties from accessories and quotation-dependent choices. Otherwise incompatible voltages, connectors or certification versions may be interpreted as one model.
Zhihe Growth's Assessment
Zhihe Growth recommends reusable identity master data, not merely another ProductGroup block. Schema describes page facts and feeds deliver channel records; conflicting parent-and-variant relationships spread errors across both. Separate group, variant and offer IDs: the group identifies the family, the variant identifies a specific configuration, and the offer identifies merchant and market terms. Version changing prices, stock and policies without redefining product identity. Resolve duplicate IDs first, align URLs and canonicals, expose accurate variant facts and markup, then connect feeds. Syntactically valid but contradictory records cannot establish correct AI interpretation or reliable measurement.
Recommended action
- Inventory group, variant, SKU, GTIN, MPN and offer IDs; investigate missing, duplicate and inconsistent mappings.
- Assign stable variant IDs independent of titles, campaigns, languages, prices and stock; retain migration mappings for necessary ID changes.
- Document business mappings between productGroupID and group_id/item_group_id, SKU and stable item_id, and supported variesBy/hasVariant and variant_dict attributes. Do not assume lossless field equivalence.
- Verify each GTIN and MPN; never reuse another variant's code or present a parent ID as a GTIN.
- Choose single-page or multi-page architecture and align variant URLs, selected page state, offers, feed destinations and canonical policy.
- Use crawlable anchor links with href attributes for variants, not JavaScript-only navigation. Include intended indexable URLs in the sitemap.
- Align visible titles, specifications, images, prices, stock, currency and market terms with schema and feeds. Do not add unverifiable configurations only to machine-readable data.
- Distinguish market offers for the same physical variant from genuinely different specifications; retain language and market mappings without inventing new permanent identities for translations.
- Test one complete product family end to end with structured-data checks, URL Inspection, feed upload history and public-page inspection before expanding.
- Record crawling, indexing, feed acceptance, product display and conversions separately; none substitutes for another or guarantees recommendations.
Limitations
ProductGroup suits clearly defined families and variants, not a requirement to publish every possible configuration as an indexable page. Highly configurable, quote-based or restricted B2B products may need visible model limits and quotation checks instead of many thin pages. Google supports specific variesBy properties, while OpenAI feed formats have their own supported fields, including variant_dict in the cited specification. This is a business-identity mapping, not a promise of lossless conversion or support for arbitrary custom fields. Canonical decisions depend on content and intended indexing. Neither parent-canonicalizing every parameter URL nor self-canonicalizing every variant is universally correct; inspect rendering, links, sitemaps, markets and feed targets together. Stable IDs, markup and feeds guarantee neither rich results, ChatGPT listings, citations, position, clicks nor sales. Platforms apply their own eligibility, quality, intent and safety systems, and changed pages and records require reprocessing.