WooCommerce 11.1 includes fixes for preserving terms and categories during product CSV reuploads. A file intended to change price or stock can still detach nested categories, duplicate terms, replace attributes, clear images, or create unexpected variations if identifiers and empty cells are misunderstood.
Use this before reuploading supplier files, merchandising exports, ERP updates, marketplace feeds, multilingual catalogs, or any CSV that updates existing WooCommerce products.
Quick answer
Export a small marked fixture with simple and variable products, nested categories, tags, global and custom attributes, images, sale prices, stock, and one intentionally blank field. Reupload a file that changes only one approved column. Compare product IDs, SKUs, term IDs, hierarchy, attributes, image IDs, variation count, prices, currency display, and public pages. Do not start with the full catalog or assume an empty cell means keep the old value.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Price only | Existing nested category | Category unchanged |
| Omitted tags | Column absent | Existing tags preserved |
| Empty images | Explicit blank | Documented behavior |
| Variable product | Existing SKU children | No duplicate variations |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Export a marked catalog fixture | Record WooCommerce version, importer mapping, update-by field, product IDs, SKUs, term IDs, category hierarchy, tags, attributes, images, variations, prices, stock, and currency. | Existing categories, hierarchy, tags, attributes, images, and variation relationships remain correct. |
| Define empty-cell behavior | Build fixtures for simple, variable, draft, translated, out-of-stock, and externally managed products with nested categories and shared terms. | Only the approved price, stock, or content field changes for each fixture. |
| Change one column | Run files with unchanged cells, omitted columns, empty cells, renamed categories, parent and child paths, new tags, reordered attributes, and duplicate SKUs. | REST, database, admin, export, and public product data agree after the import. |
| Compare objects and public pages | Compare the import report, PHP and database logs, product object, term relationships, variation children, media references, REST response, and public catalog page. | A second identical reupload is idempotent and creates no duplicate terms, media, or variations. |
What to check first
- Record WooCommerce version, importer mapping, update-by field, product IDs, SKUs, term IDs, category hierarchy, tags, attributes, images, variations, prices, stock, and currency.
- Build fixtures for simple, variable, draft, translated, out-of-stock, and externally managed products with nested categories and shared terms.
- Run files with unchanged cells, omitted columns, empty cells, renamed categories, parent and child paths, new tags, reordered attributes, and duplicate SKUs.
- Compare the import report, PHP and database logs, product object, term relationships, variation children, media references, REST response, and public catalog page.
- Export the updated fixture again and confirm a second reupload is idempotent before expanding the batch size.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
csv_fixture:
update_key: sku
sku: WAVE82-VAR-01
changed_columns: [regular_price]
expected_category_ids: [31, 47]
expected_variation_count: 3
second_import_changes: 0
Why this usually happens
- An importer treats omitted columns and present-but-empty cells as the same instruction.
- Category names are resolved without preserving the intended parent hierarchy.
- The update key matches a parent product but variation rows create new children.
- A custom import hook rewrites terms after WooCommerce completes its own mapping.
Decision rule
Scale the reupload only when one approved column changes, every catalog relationship and variation identity remains stable, and a second identical import makes no additional changes.
Production verification checklist
- Existing categories, hierarchy, tags, attributes, images, and variation relationships remain correct.
- Only the approved price, stock, or content field changes for each fixture.
- REST, database, admin, export, and public product data agree after the import.
- A second identical reupload is idempotent and creates no duplicate terms, media, or variations.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Export a marked catalog fixture
- Define empty-cell behavior
- Change one column
- Compare objects and public pages
- Repeat for idempotency
Mistakes to avoid
- Changing production before recording exact versions, UTC time, the affected fixture, current behavior, and a tested rollback point.
- Accepting one successful admin screen while the stored record, API response, queue, email, browser, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, locale, network state, catalog size, and failure path a real user reaches.
- Leaving broad credentials, debug logs, temporary filters, synthetic records, or recovery code active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with current data, extensions, cache, browser mix, and integration settings. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I rule out a cache artifact?
Record the origin response, purge only affected paths, and repeat in private and normal sessions. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version and settings it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When is the test complete?
Close it when the main path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP test a WooCommerce CSV update.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references