How to prevent duplicate products in Google Merchant Center

How to prevent duplicate products in Google Merchant Center

Duplicate products in Google Merchant Center can create confusion for store owners, disrupt product management and make it difficult to determine which data source is controlling a listing. A WooCommerce product may appear more than once because it has been submitted through an API, an XML feed, a platform integration, automatic website discovery or a manually uploaded file.

The visible products may look identical, but Google can treat them as separate offers when their submitted IDs, languages, countries, channels or data sources differ. In other situations, multiple data sources may attempt to manage the same product, leaving the merchant uncertain about which price, availability, title or image Google is using.

Preventing duplication is easier than cleaning up an account after several sources have been running together. The safest approach is to select one primary product submission method, use stable product IDs and understand every active data source connected to the Merchant Center account.

The central rule is:

One product catalogue should have one clearly defined primary submission system.

A store can use multiple data sources when there is a deliberate reason, but they should not independently recreate the same catalogue without a controlled identifier and ownership strategy.

What is a duplicate product in Google Merchant Center?

A duplicate product generally means that the same purchasable offer has been submitted more than once or that multiple offers contain the same product information without meaningful differences.

For example, a WooCommerce store may contain a product called “Classic Black T-Shirt.” The same product could reach Merchant Center through:

• A WooCommerce Merchant API integration
• An older XML product feed
• Google’s automatic website discovery
• A Google Sheets source
• A manually created Merchant Center product
• Another WooCommerce Google integration

If these systems use different product IDs, Google may show several product records even though they all lead to the same product page.

Google may also report a “Duplicate product” issue when multiple offers contain the same set of attribute values. These offers may use identical titles, descriptions, images, colours, sizes, materials and other product details without representing genuinely different items.

Duplicate products should not be confused with valid variations. A black T-shirt in size M and the same T-shirt in size L are legitimate variations when they have distinct variation attributes and unique IDs. Two records describing the same black T-shirt in size M, at the same price and on the same landing page, may be unnecessary duplicates.

Why do WooCommerce products appear twice in Merchant Center?

The most common cause is the simultaneous use of two product submission methods.

A merchant may initially connect WooCommerce to Google through a feed plugin. Later, the merchant may install a Merchant API integration but leave the old feed active. Both systems continue submitting products, and Merchant Center receives two versions of the catalogue.

Other common causes include:

• Two active WooCommerce feed plugins
• An XML feed and Merchant API running together
• Automatic website products combined with submitted products
• A previously connected ecommerce platform integration
• Manual products that were not removed after automation began
• A test data source left active in the production account
• A new integration generating different IDs from the old integration
• Products submitted to different languages or countries without a clear plan
• Parent products and child variations both being submitted incorrectly
• Deleted WooCommerce variations remaining in an old source
• Duplicate products already present in the WooCommerce catalogue
• Scheduled feed retrieval continuing after a migration
• An integration being reinstalled with a different identifier structure

The duplication does not always begin inside Merchant Center. It may originate from WooCommerce, a plugin database, a scheduled task, a third-party service or an old source URL that Google continues to retrieve.

Check every active product data source

Before deleting individual products, inspect the account’s product sources.

In Merchant Center, open the settings area and go to Data sources. Review all primary product sources and any additional sources associated with the account.

Look for sources such as:

• Merchant API
• Content API or an older API integration
• Website or automatically found products
• Scheduled file feeds
• Uploaded XML, CSV or TSV files
• Google Sheets
• Ecommerce platform connections
• Manually added products
• Local inventory sources
• Supplemental sources

Record the name, submission method and purpose of each source. If two sources contain the entire WooCommerce catalogue, determine whether both are genuinely needed.

Do not delete a source only because its name is unfamiliar. First confirm what created it, which products it controls and whether another system has safely replaced it.

A simple source inventory can be organised as follows:

Data source	Purpose	Current status	Keep or remove
PW Merchant API	Primary WooCommerce synchronisation	Active	Keep
Old XML feed	Previous submission method	Still scheduled	Remove after verification
Website discovery	Automatic product discovery	Enabled	Review
Manual products	Historical test products	Outdated	Remove if duplicated

This process provides a clearer view of the account than deleting products one by one.

Choose one primary submission method

For most WooCommerce stores, one primary system should control the main online catalogue.

The selected method may be:

• Merchant API
• A scheduled product file
• An ecommerce platform connection
• Automatic website discovery
• A manually managed source for a very small catalogue

Merchant API is suitable for stores that require frequent product updates, large catalogue management or direct synchronisation of price and availability. A scheduled file can also work well when the catalogue does not need immediate updates.

The important point is consistency. If Merchant API becomes the new primary source, the old feed should not continue resubmitting the same catalogue indefinitely.

A controlled migration usually follows this sequence:

1. Identify the current source and its product IDs.
2. Configure the new integration correctly.
3. Test a limited group of products when possible.
4. Confirm prices, availability, links and identifiers.
5. Stop the old source from submitting new updates.
6. Remove or retire obsolete products safely.
7. Monitor Merchant Center after the transition.

Running two full-catalogue systems permanently “just in case” can make troubleshooting harder. If a product becomes inaccurate, it may be unclear which integration needs to be corrected.

Understand the importance of product IDs

The submitted product ID is one of the most important elements in duplicate prevention.

Merchant Center uses an ID to recognise a specific offer across updates. The value should be:

• Unique within its intended product context
• Stable over time
• Consistent across routine updates
• Different for each genuine variation
• Generated according to a documented rule

A WooCommerce integration may build IDs from:

• WooCommerce product IDs
• Variation IDs
• Unique SKUs
• A combination of store and product identifiers
• Another stable internal reference

Suppose an old feed submits a product as:

woocommerce_1234

A new API integration may submit the same product as:

pw_1234

Even if every other attribute is identical, the different IDs can cause the records to be treated separately.

Changing the ID structure during migration should therefore be a deliberate decision. If the new system can safely preserve valid existing IDs, product continuity may be easier to maintain. If preservation is not technically reliable, obsolete records from the former system must be identified and removed correctly.

Never use temporary values, timestamps or frequently changing text in product IDs. A product should not receive a new identity whenever its price, title or stock changes.

Do not submit the parent and variations as duplicate offers

WooCommerce variable products require special handling.

The parent product normally organises the product page, while each child variation represents a purchasable option. A careless integration may submit:

• The parent product
• Every child variation
• An additional generic product generated from the same page

This can create an extra listing that does not represent a unique purchasable choice.

Each valid variation should generally have its own unique product ID. Related variations should share an appropriate item group ID and contain attributes that distinguish them, such as:

• Colour
• Size
• Material
• Pattern
• Capacity

The parent should not be submitted as an additional offer unless it genuinely represents a separately purchasable product and the integration has a valid reason for doing so.

For example, these can be valid variations:

Product ID	Item group ID	Colour	Size
shirt-100-black-s	shirt-100	Black	S
shirt-100-black-m	shirt-100	Black	M
shirt-100-white-s	shirt-100	White	S

An additional generic record called shirt-100 with no selected colour or size may become unnecessary if customers cannot purchase that exact unspecified option.

Distinguish legitimate variants from duplicate offers

Products that look similar are not always duplicates. Merchants should identify whether each listing represents a genuinely different item.

A legitimate offer may differ by:

• Size
• Colour
• Material
• Pattern
• Capacity
• Pack quantity
• Condition
• Gender
• Age group
• Flavour
• Scent
• Format

When these properties represent real customer choices, they should be submitted through the appropriate attributes.

Changing a title only to make a duplicate appear different is not a reliable solution. The product itself must have a meaningful distinction that customers can select and receive.

For example:

• “Black T-Shirt, Size M” and “Black T-Shirt, Size L” are valid variants.
• “Black T-Shirt” and “Premium Black T-Shirt” are not necessarily different when both records describe the same physical item.
• A single bottle and a six-bottle multipack can be different offers when the pack quantity is submitted accurately.
• A new product and a refurbished version can be distinct when condition and landing-page information are correct.

Google’s duplicate product guidance recommends ensuring that each genuine offer contains a unique set of applicable attribute values.

Review automatically added website products

Merchant Center can discover products from structured data on a store’s website. This feature can be useful for stores without another active submission method.

When a WooCommerce integration is already providing the full catalogue, review whether automatic website discovery is also needed.

Google is designed to avoid adding products automatically when the same products are already included through other sources. However, merchants should still inspect source assignments during migrations, identifier changes and integration replacements.

Structured data remains valuable even when Merchant API is the primary submission method. It helps Google compare the information on the landing page with the submitted product data. The objective is not necessarily to remove structured data from the website, but to manage how automatically discovered products participate in Merchant Center.

Do not disable WooCommerce product schema merely because duplicates appear. First identify whether the issue is caused by source configuration, changed IDs or another active plugin.

Remove old integrations from WooCommerce

Deleting a data source in Merchant Center may not be sufficient if the old plugin or scheduled process is still active.

Review the WordPress installation for:

• Old product feed plugins
• Google integration plugins
• Custom synchronisation code
• Scheduled XML generation
• WP-Cron jobs
• External cron jobs
• Third-party feed services
• Cached feed URLs
• API credentials belonging to retired systems
• Duplicate staging-site connections

Deactivate obsolete integrations only after confirming that the chosen primary system is functioning correctly.

If an old XML feed is hosted at a public URL, check whether Merchant Center still retrieves it on a schedule. Removing the WordPress plugin without removing the source from Merchant Center may leave the existing file active until the scheduled relationship is changed.

Likewise, deleting a source from Merchant Center while leaving an API integration enabled may allow the application to create or repopulate data again.

Both ends of the connection should be reviewed.

Check for duplicate products inside WooCommerce

Sometimes Merchant Center accurately reflects duplication that already exists in the store.

Search WooCommerce for products that share:

• The same SKU
• The same title
• The same landing page
• The same GTIN
• The same variation combination
• The same external product reference
• Copied product data from an import

Product import tools can create a second product instead of updating the original when the matching identifier changes. Catalogue migration, staging-site restoration and ERP synchronisation can produce similar results.

Confirm that each WooCommerce product and variation represents a real sellable item. Remove test, draft or copied products from the submission scope when they are not intended for Google.

Duplicate SKUs deserve particular attention. WooCommerce may allow unusual catalogue configurations through imports or custom code, while a Merchant integration may rely on the SKU to construct product IDs. Duplicate SKUs can therefore create collisions, skipped updates or unstable product identity.

Be careful with staging and test websites

A staging site should not submit its test catalogue to the production Merchant Center account.

This can happen when:

• A live website is cloned with active API credentials
• Scheduled tasks remain enabled on staging
• A backup restores an existing Merchant connection
• The staging domain uses the same Merchant Center account
• Test products are submitted with new IDs
• Both environments run background synchronisation

After cloning a WooCommerce site, disable external product synchronisation in the test environment unless it is connected to a dedicated test account.

API credentials, scheduled tasks and production account identifiers should be handled as environment-specific configuration. A staging copy should not become a second uncontrolled source for the live catalogue.

Do not create a second record when updating a product

Price, availability, title, image and description changes should update the existing Merchant Center item. They should not create a new item.

An integration must use the same stable identifier whenever it updates an existing product. If the update process generates a different ID, the old product may remain while a new record is created.

This problem often appears after:

• Plugin reinstallation
• Domain migration
• SKU modification
• Product import
• Database restoration
• Language plugin reconfiguration
• A change in ID prefix
• A switch from parent IDs to variation IDs
• Moving from an old API to Merchant API

Before performing a major migration, document the current ID format. After the migration, compare sample product IDs in WooCommerce and Merchant Center.

If the new system deliberately uses a different ID structure, include removal of the former records in the migration plan.

Handle multilingual and multi-country products carefully

The same product can legitimately be submitted for different languages and countries. These records should not automatically be treated as accidental duplicates.

For example, a WooCommerce store may target:

• English-speaking customers in the United Kingdom
• German-speaking customers in Germany
• French-speaking customers in France

Each destination may require different product text, currency, shipping settings and landing pages.

Problems arise when the same country and language combination is submitted repeatedly without a deliberate reason or when several integrations independently create the same international catalogue.

For every market, document:

• Target country
• Content language
• Currency
• Landing-page domain or path
• Shipping configuration
• Product ID strategy
• Responsible data source

International expansion should follow a planned market structure rather than copying the same feed several times with unclear settings.

How to investigate duplicate products

When duplicate products appear, begin with evidence rather than deleting records immediately.

For each suspected pair, compare:

• Product ID
• Data source
• Landing-page URL
• Title
• Price
• Currency
• Availability
• Brand
• GTIN
• MPN
• Colour
• Size
• Item group ID
• Target country
• Language
• Sales channel

If the product IDs differ, determine why. If the data sources differ, identify which source should remain responsible. If the products have legitimate variation attributes, they may not be duplicates.

A useful investigation process is:

1. Select one duplicated product.
2. Note every visible product ID.
3. Open the details of each record.
4. Identify the source assigned to each record.
5. Compare the landing pages and product attributes.
6. Locate the corresponding WooCommerce product or variation.
7. Determine the intended primary source.
8. Correct the source configuration.
9. Remove obsolete records or allow the retired source to expire as appropriate.
10. Confirm that the duplicate does not return after the next scheduled synchronisation.

If a deleted duplicate reappears, an active integration is probably submitting it again.

Should you delete the old data source immediately?

Not always.

Immediate deletion can temporarily remove valid listings when the replacement source is incomplete or incorrectly configured. Before removing the old source, confirm that the new source has successfully submitted the intended catalogue.

Check a representative selection of products, including:

• Simple products
• Variable products
• Products on sale
• Out-of-stock products
• Products with GTIN values
• Products without manufacturer identifiers
• Products with multiple images
• Products using different shipping classes
• Products targeting different countries

Confirm that the new source has accurate prices, availability, images, links and variation data.

Once the new source is verified, retire the obsolete source in a controlled way. Continue monitoring Merchant Center because source changes and product processing may not be reflected instantly.

How to remove duplicate products safely

The correct removal method depends on the cause.

If an obsolete XML feed created the duplicates:

• Stop or remove its retrieval schedule.
• Confirm the new source is active.
• Remove the obsolete source from Merchant Center when safe.
• Check whether old products remain temporarily during processing.

If an old plugin created the duplicates:

• Disable its synchronisation.
• Remove unnecessary scheduled tasks.
• Revoke obsolete access when appropriate.
• Remove or retire the products it controlled.

If manual products duplicate automated products:

• Verify that the automated version is complete.
• Delete the unnecessary manually created records.
• Avoid recreating them outside the primary system.

If duplicate WooCommerce products exist:

• Decide which store product should remain.
• Preserve the correct SKU and product history.
• Redirect obsolete URLs when necessary.
• Remove the duplicate from synchronisation.
• Update Merchant Center through the primary integration.

If a new ID structure caused the duplication:

• Confirm the new IDs are stable.
• Map or remove old records.
• Prevent the integration from generating another ID change.
• Document the final identifier format.

The source problem must be corrected before cleaning up the visible records. Otherwise, the duplicates can return.

Why manual Merchant Center edits may not solve the problem

Merchant Center allows merchants to edit certain product information directly. This can help with a small number of manually managed products, but it is not a permanent solution for source-generated duplicates.

If a WooCommerce plugin, scheduled file or API remains active, its next synchronisation may overwrite manual changes or recreate deleted data.

Corrections should normally be made at the source of truth:

• WooCommerce product data
• The active integration
• Attribute mapping
• Product ID generation
• Feed configuration
• Country and language settings

Merchant Center should reflect the store’s controlled product data rather than becoming a separate catalogue that requires repeated manual repair.

How Merchant API helps prevent duplicates

Merchant API can provide a direct and manageable product submission process for WooCommerce stores. However, using an API does not automatically prevent duplication.

The integration must still:

• Generate stable product IDs
• Update existing products instead of recreating them
• Distinguish variations correctly
• Remove obsolete products safely
• Avoid submitting parent products unnecessarily
• Track successful and failed operations
• Prevent staging sites from using production credentials
• Maintain one consistent account connection
• Handle country and language data deliberately

PW Merchant is designed to help establish a controlled connection between WooCommerce and Google Merchant Center. For the cleanest migration, an existing feed or older integration should be reviewed before Merchant API synchronisation becomes the primary method.

A successful API response means that Google has accepted an operation for processing. It does not by itself confirm that the item is approved, visible or free from duplicate-data issues. Product status should still be reviewed in Merchant Center.

Common mistakes that cause duplicate products

Frequent mistakes include:

• Activating Merchant API without retiring the old feed
• Using two WooCommerce Google plugins simultaneously
• Changing product ID prefixes during routine updates
• Submitting parent products and every variation together
• Reusing staging-site credentials on a cloned website
• Uploading a manual file while an automated source is active
• Creating products manually to replace items that are only delayed
• Reinstalling an integration without checking its ID strategy
• Copying products in WooCommerce without changing identifying data
• Using duplicate SKUs
• Leaving scheduled feed URLs active
• Treating valid variations as duplicates
• Creating artificial variation differences that customers cannot see
• Deleting visible products without stopping the source that created them
• Maintaining separate sources with no documented purpose

Avoiding these mistakes reduces catalogue clutter and makes future troubleshooting much easier.

Frequently asked questions

Why is the same WooCommerce product listed twice in Merchant Center?

The product may be arriving through two different data sources, such as Merchant API and an older XML feed. It may also have received a new product ID after an integration change, causing Google to treat it as a separate item.

Can I use Merchant API and an XML feed at the same time?

Yes, multiple sources can be used when their responsibilities are clearly separated. They should not independently submit the same full catalogue without a controlled plan.

Should I delete my old feed after switching to Merchant API?

First verify that Merchant API is submitting the complete and accurate catalogue. After verification, the obsolete feed can be retired safely so that it no longer submits duplicate products.

Will deleting a duplicate product solve the issue permanently?

Only if the system that created it has also been corrected or disabled. An active plugin, API connection or scheduled feed may submit the product again.

Are WooCommerce product variations considered duplicates?

Not when each variation represents a genuine purchasable option and contains unique variation attributes. Every variation should have a unique ID and related variations should be grouped appropriately.

Can two products use the same landing page?

Variations may use the same parent product page when the advertised option can be identified or selected correctly. Two indistinguishable offers using the same page and attributes may create a duplicate-data problem.

Can duplicate SKUs cause Merchant Center duplication?

They can contribute to identifier conflicts when an integration uses SKUs to create or match product IDs. Unique and stable SKUs are strongly recommended.

Why did duplicates appear after reinstalling my WooCommerce integration?

The reinstalled integration may have generated a different ID format, connected through another data source or lost its previous product mapping.

Does automatic website discovery always create duplicates?

Google attempts to avoid automatically adding products that already exist through another data source. However, merchants should still review automatic products during source migrations and ID changes.

How long does it take for removed duplicates to disappear?

Changes may require processing time. Monitor the Products and Needs attention sections after correcting the source. Do not repeatedly recreate or delete records while processing is still underway.

Can I change product titles to avoid a duplicate warning?

Titles should describe genuine product differences. Changing wording solely to disguise identical offers is not a reliable solution. Products should contain meaningful and accurate distinguishing attributes.

Which product source should a WooCommerce store use?

The appropriate method depends on catalogue size, update frequency and management requirements. Merchant API is useful for frequent updates and complex catalogues, while scheduled files may suit other stores. The chosen method should become the clearly defined source of truth.

Final checklist

Before synchronising WooCommerce products with Google Merchant Center, confirm that:

• Every active data source has a documented purpose.
• Only one primary system manages the main product catalogue.
• Old XML feeds and plugins have been reviewed.
• Product IDs are unique and stable.
• Routine updates preserve existing product IDs.
• Variable products are submitted correctly.
• Parent products are not creating unnecessary extra offers.
• Every variation has meaningful distinguishing attributes.
• WooCommerce products and SKUs are not duplicated.
• Staging sites cannot synchronise with the production account.
• Automatic website products have been reviewed.
• Target countries and languages are configured deliberately.
• Obsolete products can be removed safely.
• The replacement source is verified before the former source is deleted.
• Manual Merchant Center edits are not being overwritten by automation.
• Products are checked again after the next scheduled synchronisation.

Duplicate prevention is primarily a matter of product ownership, stable identity and controlled data sources. When every catalogue has a clear submission path, WooCommerce updates become easier to follow and Merchant Center results become easier to understand.

A well-managed source structure also reduces the risk of outdated prices, conflicting availability, repeated product records and unnecessary troubleshooting. By choosing one primary submission method and maintaining stable product IDs, merchants can build a cleaner and more reliable connection between WooCommerce and Google Merchant Center.