How to Bulk Update WooCommerce Prices Across Languages

A price update is usually operational data work, not a translation project. The safest file is therefore small: stable product identity, the price fields you intend to change, and nothing unrelated.

In a multilingual store, the edit still needs front-end checks in every language. WooCommerce, WPML/WCML, currency, tax, and pricing extensions can all affect what a buyer eventually sees.

Start with a narrow CSV

For a regular-price change, a file can be as simple as:

sku,regular_price
BOOT-42,89.00
JACKET-L,149.00

Add sale_price only when the batch genuinely changes sale pricing. Do not include title, description, stock, categories, or images “just in case.” Every extra mapped field increases the scope of the write and the amount of QA required.

Export or prepare the source in UTF-8, retain a reviewed copy, and make sure decimal formats are consistent.

Match by a portable key

SKU is the normal cross-store product key. Matrix ID / External ID belongs to multilingual Matrix workflows. WordPress product IDs are suitable only when the file comes from the same installation and that identity is deliberately preserved.

Product rows are processed on each import. Smart Sync's skip-unchanged behavior applies to posts, pages, and custom post types with a mapped Record ID, not to WooCommerce products. Correct matching is what makes a product price re-import update instead of duplicate.

Before the real batch, include one product that already has the intended price. The preview and result help confirm how an idempotent-looking row is handled in your actual configuration.

Understand shared and translated price behavior

In many WPML/WCML stores, product prices are treated as shared operational data rather than translated text. Do not create columns such as regular_price|en by habit.

However, the displayed amount can depend on currency-conversion rules, exchange rates, tax display, customer location, or a dynamic-pricing extension. Shirely writes the mapped WooCommerce catalog field; it does not replace the configuration of those other systems.

Write down whether the task is changing a base price, a sale price, or market-specific pricing managed elsewhere.

Preview before writing

On staging, upload the file and map only the identity and intended price columns. Review the create/update/skip expectations and warnings.

Stop if rows appear as new when they should update. That is an identity problem, not a reason to proceed and clean up later.

For variable products, decide whether the parent, each variation, or both carry the price data in your catalog. Variation SKUs must remain unique and their parent relationship must already be correct.

Verify admin and storefront results

After the sample import, check:

the stored regular and sale values in WooCommerce admin;
a simple product;
several variations with different prices;
every storefront language;
tax-inclusive and tax-exclusive presentation if relevant;
configured currency output if enabled;
sale start/end behavior managed by the store;
cart and checkout totals for a representative product.

The language check is not redundant. A shared underlying value can still be rendered differently because the translated product, cache, or pricing configuration is out of alignment.

Schedule only a proven workflow

Shirely 1.3 can save supported imports as Automation slots. Use Run now and inspect Run History before assigning an hourly, twicedaily, or daily WP-Cron schedule.

WP-Cron does not promise an exact start time. For large or time-sensitive jobs, system cron with WP-CLI is more predictable. Ensure another wizard, Automation slot, or CLI job is not writing the same products or translation groups at the same time.

Keep the source file and a result record for price-sensitive changes. A rollback plan should identify the previous prices, not merely assume an older full-catalog export is easy to restore.

For a broader catalog update, read importing WooCommerce products from CSV and the Shirely documentation.