Update existing WooCommerce products by CSV without changing unrelated fields

Build a before-and-after record

Export the target products from staging and retain that export alongside a restorable backup. Capture product IDs, exact SKUs and current values for the fields you will change. If a SKU is missing or ambiguous, resolve it before including that row in the update.

The downloadable update sample targets SKU 00041, sets Regular price to 14.75 and Stock to 12. It assumes the sample mug already exists. Do not import it into a live store just because the same SKU happens to be present; that could update a completely different business product.

Make field handling explicit

Remove columns outside the intended scope, and review every mapping. An omitted field, an unmapped field and a mapped empty cell are different inputs. Do not assume every importer or every field treats blanks as ‘leave unchanged.’ Test the exact field behavior on a staging copy when clearing a value is part of the task.

Choose the existing-product update option and verify the identity match. Core behavior changes between versions, particularly around new variations in WooCommerce 11.1. A mixed file that creates some products and updates others deserves a separate plan rather than a guessed checkbox setting.

Verify identity as well as values

Check that the original product ID now has the intended values. Compare a fresh export with the before-record and inspect an unrelated field such as the name. Unexpected created records, skipped targets or modified fields require investigation before a larger batch.

Our local integration test created the sample catalog first, then applied the update fixture and checked the mug’s saved price and stock. This proves that narrow synthetic path on WooCommerce 11.1.0. It does not establish empty-cell semantics for all fields or compatibility with pricing and inventory extensions.

Check the result

• The planned product IDs were updated and no unintended records were created.
• Changed values match the approved file; unrelated fields remain correct.
• Every skipped or failed target is explained before the next run.