When a row in your file matches something already in your store, the plugin needs to know what to do with it. That decision is the duplicate rule, and it is the single setting people most often get wrong.
You will find it on the filters step of an Advanced import, labelled to match the data type: If product ID already exists, If category ID already exists, If coupon already exists, and so on.
The three options #
Skip #
The row is ignored and the existing record is left exactly as it is. Nothing is written.
Use it when you are adding new items to a catalogue that already has data you do not want touched. A supplier sends a full catalogue every month and you only want the new lines from it.
Watch for an import that reports success and appears to have changed nothing. Check the skipped count in History. If it matches your row count, the duplicate rule was on Skip when you wanted Update.
Update #
The existing record is overwritten with the values in your file.
Use it when you are pushing price changes, stock levels, description edits, or any correction to records that already exist. This is the normal choice for a round trip: export, edit in a spreadsheet, import back.
Watch for columns you did not intend to include. Update writes every mapped column, so if your file carries a Description column that somebody emptied in Excel, the descriptions get emptied in WooCommerce. The safest habit for a price update is a narrow file: ID, SKU, and the two or three fields you are changing.
Create as new #
A new record is created with a fresh ID, and the existing one is left alone. You end up with both.
Use it when you are deliberately duplicating, such as cloning a product range to build variants of it, or merging a second store’s catalogue where ID collisions are meaningless.
Watch for the obvious. Run this by accident on a full catalogue and you have doubled it. There is no automatic cleanup, though a rollback will remove what the import created.
How records are matched #
Matching happens on the identifier, which differs by data type:
- Products: ID first, then SKU.
- Orders: Order ID.
- Customers: User ID, then email address.
- Coupons: Coupon code.
- Categories and tags: Term ID, then slug.
- Reviews: Comment ID.
If no identifier column is mapped, nothing matches, every row looks new, and the duplicate rule never comes into play. An import that produces duplicates when you expected updates is usually an unmapped identifier rather than a wrong duplicate rule.
Quick import always skips #
Quick import cannot update. Whatever it finds already in the store is skipped, by design, so a fast one-click import can never overwrite live data by accident. Updating is available only through Advanced import, where you have chosen the rule deliberately.
If you set out to update and used Quick import, the run will complete, report a large skipped count, and change nothing.
Bundles use one rule for everything #
A bundle import asks for a single duplicate rule that applies to all seven modules at once. You cannot update products while skipping orders in the same bundle run. If you need different rules per type, import them individually.
Scheduled jobs offer two #
Scheduled imports offer Skip and Update only, with matching on ID or SKU. Create as new is left out on purpose: a job that runs every night and duplicates its input each time would fill a store within a week.
Choosing correctly #
- Changing prices or stock on existing products: Update.
- Adding this season’s new lines to an existing catalogue: Skip.
- First import into an empty store: either, since nothing matches anyway.
- Nightly supplier stock feed: Update.
- Merging a second store into this one: Create as new, then clean up by hand.
If you get it wrong #
Open the run in the History tab and roll it back. Records the import created are deleted, records it updated are restored to their previous values. This works once per import, and only when the import completed cleanly. It is not a substitute for the backup you took first.
