Google’s 2026 Multi-Channel Product ID Rule: Audit Guide

If your website and stores sell the same SKU, a single Google product ID may feel like the cleanest setup. It stops being the right setup when the offer facts sent to Google disagree across those channels.

March 2026 is the implementation point attached to Google Merchant Center’s multi-channel product ID requirement. Online product attributes become the baseline. When the in-store version has a different price, availability, condition, or another relevant product detail, you need a distinct product ID for that version and must manage it separately in your feeds.

The rule turns on channel differences, not the shared SKU

The practical question is not whether the website and store sell the same physical product. Ask whether Google receives the same product facts for both ways of buying it.

If the online and in-store details are aligned, this rule does not create a reason to split the item. If one or more relevant details differ, the in-store offer needs its own identity in the feed. That lets Google treat each channel version as a coherent set of facts instead of trying to reconcile conflicting values under one ID.

Keep two distinctions clear. First, a separate Google product ID does not mean that the merchandise has become a different manufacturer product. Do not fabricate a GTIN, manufacturer part number, or other external identifier to satisfy a feed-management requirement. Second, separating online and in-store versions should not be read as a general command to create a new product ID for every physical store. The trigger here is the difference between channel versions.

Build the audit around the online version as the baseline

A conventional duplicate-SKU report will not find this problem. The duplicated base SKU is expected. What matters is whether the attributes associated with that SKU change when the selling channel changes.

Build a comparison file with one row for each online and in-store pairing. At minimum, include the base catalog key, the current Google product ID, channel, price, availability, condition, and the system that supplied each value. Add a result column that classifies the pair as aligned or different.

1. Start with the products Google has already identified. Affected accounts began receiving notices and product-level indications before the deadline, so those items give you a concrete first queue.
2. Expand beyond the flagged queue. Compare the full set of products distributed through your online and local feeds, especially if you use Local Inventory Ads or send the same catalog into several Google surfaces.
3. Compare published channel values, not only the values in your master catalog. A price may look identical in the product information system while a later rule, promotion process, or inventory system changes the feed output.
4. Classify each mismatch by attribute. Separate price, availability, condition, and other product-detail differences instead of using a single generic error label.
5. Split only the pairs with a real channel difference. Leave aligned products alone unless another requirement gives you a reason to change them.
6. Assign an owner to every unresolved mismatch. The person or team that controls the source data must be able to correct the feed generator, not just patch a submitted file once.

Treat Google’s markings as a priority list, not a substitute for your own comparison. A product that has not been flagged can still belong in the audit if its channel attributes come from different systems or change frequently.

Design the ID split so your catalog remains traceable

The difficult part is rarely generating another string. It is preserving the relationship between the online version, the in-store version, and the underlying catalog item after the split.

Use an ID convention that your feed process can reproduce deterministically. A channel suffix can be understandable, but no particular suffix is established here as a Google-mandated format. The important operational properties are uniqueness, consistency, and a documented connection to the base item. Do not include mutable values such as the current price or availability in the ID; every routine change would otherwise create unnecessary identity churn.

Maintain a crosswalk containing:

• The base SKU or internal catalog key.
• The online product ID.
• The in-store product ID.
• The attribute or attributes that require separation.
• The source system for each channel’s values.
• The owner responsible for correcting future mismatches.
• The status of the feed change and its validation.

This crosswalk protects reporting and troubleshooting. Without it, a team can see two Google IDs and mistake them for duplicate products, or see one internal SKU and merge channel records that must remain separate.

Make the separation in the feed-generation logic whenever possible. A manual edit to an exported file may fix one submission, but the next automated run can restore the old shared ID. The durable fix is to route online facts to the online version and differing local facts to the in-store version before the files reach Merchant Center.

Before a large rollout, verify a small, representative set through your normal feed-validation and account-diagnostic process. Include at least one price mismatch, one availability mismatch, and one fully aligned product if those cases exist in your catalog. That gives you a direct check that the split logic changes only the records it should.

Avoid the changes that create more feed problems

The fastest implementation is not a catalog-wide ID rewrite. It is a controlled exception process. Watch for these common errors:

• Splitting every multi-channel item: the requirement is tied to differing product details. Rewriting IDs for aligned items adds work without addressing the stated trigger.
• Using the shared SKU as proof that one ID is correct: a shared SKU establishes the relationship between the products, but it does not resolve conflicting channel attributes.
• Changing only one exported feed: if another local inventory, catalog, or integration process still emits the shared ID, the inconsistency will return.
• Overwriting the online baseline with local values: the required model uses online attributes as the standard and separates the differing in-store version. Repeatedly replacing one channel’s facts with the other’s does not create two coherent records.
• Inventing a new manufacturer identifier: manage the separate Google product ID without falsifying GTINs or other identifiers assigned outside your organization.
• Discarding the old-to-new relationship: preserve a crosswalk so reporting, investigation, and future corrections can connect both channel versions to the original catalog item.
• Waiting only for an account warning: Google notifications help you prioritize, but your source systems are the reliable place to discover every channel difference you publish.

If your catalog is large, prioritize products with known channel-specific pricing, products whose availability changes independently between online and physical stores, and products flowing through Local Inventory Ads. Those are the places where the rule’s trigger is easiest to establish from your own data.

Key takeaways

• Use the online product record as the comparison baseline for a product sold online and in stores.
• Create a separate in-store version with a distinct product ID when relevant details such as price, availability, or condition differ by channel.
• Do not split an aligned product merely because it is available through two channels.
• Audit the attributes that are actually published, because downstream systems can introduce differences that are absent from the master catalog.
• Preserve a crosswalk between the base SKU and both channel IDs, and make the change in the feed-generation logic rather than relying on a one-time file edit.

Your next step is concrete: take the products already marked in Merchant Center, compare their published online and in-store attributes, and use that result to build a repeatable exception report for the rest of the catalog. Split confirmed mismatches, document the mapping, and leave genuinely aligned records intact.

References

• Search Engine Land – Google to require separate product IDs for multi-channel items