Prepare a WooCommerce product CSV by exporting a representative product from the shop, matching the incoming data to that structure and testing a small sample on staging. Keep a backup and reconcile the results before importing the full catalogue. A supplier spreadsheet is a starting point, not an instruction to overwrite your store.
Use this workflow for a modest catalogue or a controlled price/stock update with the built-in WooCommerce importer. It does not cover an ongoing supplier feed, order migration or a specialist import extension. Those need their own matching rules and failure handling.
Separate new products from changes to existing ones
Write down the purpose of this import before touching the file: create new listings, correct descriptions, update prices or change stock. Limit the mapped columns to that purpose. A stock update should not casually replace edited product descriptions or product URLs.
The built-in importer can match existing products by ID or SKU. Product IDs belong to an installation; copying them from a different shop can target the wrong records. Stable SKUs need their own duplicate check. Use the variation and SKU plan to settle identities before preparing parent and child rows.
WooCommerce’s built-in CSV documentation gives the current schema, mapping process and update behaviour. Do not mix its columns with instructions for the paid Product CSV Import Suite: similarly named tools use different formats. Record the importer and WooCommerce version used in your test.
Keep the original and make a working copy
Retain the supplier file unchanged with its date and source. Create a separate working copy and a short change log. If a later price looks wrong, you need to know whether the supplier changed it, the spreadsheet converted it or the mapping selected the wrong column.
Inspect identifier columns as text. A spreadsheet can strip leading zeroes or turn a long number into scientific notation. A value that looks close on screen may no longer match the SKU. Open the exported CSV as plain text for a sample check as well as inspecting the spreadsheet.
Use consistent spelling for attribute values. “M”, “Medium” and “medium ” should not become three unplanned choices. Keep the customer-facing vocabulary readable and use the same values on parent and variation records. Strip unwanted whitespace; do not strip meaningful punctuation from identifiers.
| Incoming problem | Resolve before import |
|---|---|
| SKU 00127 becomes 127 | Preserve the intended identifier as text and check the saved CSV |
| Prices include £ symbols or formulas | Prepare plain values in the format required by the importer |
| Duplicate rows for one SKU | Choose the authoritative record; do not rely on row order to settle the conflict |
| Several spellings of a colour or size | Map them to the agreed attribute vocabulary |
| Supplier-only columns | Leave them unmapped unless you have a documented supported destination |
| Unexpected publication status | Keep new products in the intended review state until accepted |
Use a sample that includes the difficult records
A ten-row sample chosen solely from simple products proves little about a variable range. Include one simple product, one parent with several real variations, an out-of-stock option, an image, punctuation in a description and a record being updated.
Use a fresh staging copy with controlled notifications and integrations. Keep it private and keep customer data out of your working product sheet. Prepare a recoverable backup before testing. Our backup restore guide covers the recovery check; product export alone is not a full site backup.
Record expected results before running the sample. For example: one new parent with three variations, two existing simple products with changed prices, and no changes to their descriptions. Distinguish rows from products: a variable product’s child rows should not be counted as unrelated listings.
Map deliberately, then read the result report
Open Products, choose Import and review the mapping screen. Known headers may map automatically, but automatic recognition is not sign-off. Inspect each destination, especially identifiers, parent relationships, stock, prices, images and product status.
Save the cleaned file as UTF-8 CSV. Use the current official schema and an export from your installation as references for quoting and multi-value fields. A comma inside a description must not become an extra column; one malformed row can move values into the wrong destinations.
For new records, choose the creation workflow. For updates, select the appropriate update option and confirm matching IDs/SKUs. Parent-and-variation handling differs by WooCommerce version and operation, so prove the chosen workflow with one parent first. Do not assume a recipe for another version or importer will behave identically.
Run the import without refreshing or navigating away. Retain the success, failed and skipped-row information. Investigate skipped rows before retrying the entire file; repeated full imports can multiply confusion and make it harder to identify what changed.
Reconcile what changed, not just what was reported
Inspect the sample in the product editor and the logged-out storefront. Check names, selected options, SKU, price, availability, categories, descriptions, assigned images and the basket. Export the result and compare the fields you intended to change.
Here is an illustrative reconciliation: 8 expected new sellable records, 7 created, 1 skipped; 12 expected updates, 12 updated. That is not a pass. Find the skipped record, confirm that the 12 updates matched the right items, and verify that fields outside the update scope stayed intact.
Keep a compact log with file version, time, environment, operator, expected counts, reported counts, exceptions and sample product links. For a variable range, check both the number of parent listings and the number of sellable combinations.
Image URLs deserve a separate check. Confirm that the source is accessible and you have permission to use it; then verify the imported main and variation images. A row can appear successful while the storefront shows the wrong colour or no useful product photograph.
Plan the live update around trading
For a new shop, hold the imported catalogue for review before launch. For an existing shop, agree a controlled change window and a method for protecting new orders and stock changes. A staging database may contain yesterday’s stock; copying it wholesale onto a trading shop can overwrite today’s activity.
Transfer the validated catalogue changes through an agreed product-data process. Repeat the small live sample and inspect its result before the remaining batch. The developer should define the recovery route for the actual operation; restoring the whole database is not automatically a safe undo once new orders exist.
If an import goes wrong, stop additional imports, retain the file and result report, and identify which records changed. Correct the mapping or source first. Do not delete the entire range or reimport an old file until you understand what that would remove or replace.
Leave the next update easier to audit
Keep the master identifiers, attribute vocabulary and approved column mapping with the catalogue record. Separate one-off bulk work from routine stock updates, with a named owner for each. A regular manual supplier feed that needs hours of repair may justify a supported integration; it still needs sample checks and an exception queue.
After a meaningful import, use the checkout and order rehearsal with a changed product. The final check is that the right item can be ordered and fulfilled, not simply that rows reached WordPress. Return to the shop launch plan for the acceptance steps around the catalogue.
