Use WooCommerce’s bulk editor when the same change applies to a selected group of products. Use a CSV when each item needs different values and you can check the file before applying it. Consider a supplier integration when updates recur often enough that preparing and checking files has become a continuing job.
The useful distinction is how the information changes. A shop with a large but stable range can need less automation than a small range whose availability changes throughout the day. Start by identifying the fields you want to update and who owns the correct value for each.
Choose the method around the change
For one product: open its product editor. This lets you inspect the surrounding information while making a correction, such as replacing a description or checking the pictures for one new colour.
For the same change across a group: filter the product list, select the intended records and consider the built-in bulk editor. Moving a set of simple products to a different shipping class is a shared change. Check the selected names before applying it.
For different values on different products: a checked CSV is usually a clearer working document. Each row can carry the intended value for that item. Follow the CSV preparation and test workflow rather than uploading the supplier’s untouched spreadsheet.
For a recurring external source: investigate an integration that can retrieve, match and validate the data. Our supplier stock-feed brief covers the decisions needed before automatic updates are enabled.
Write down which fields the update may change
A catalogue contains information with different owners. The supplier may provide an item code and availability. You may write the product title, photograph the item, choose its categories and set the customer-facing description. Importing every available column gives the supplier file influence over all of those decisions.
Make a short field list before choosing a tool. For each field, name its source, who approves it and whether the next update is allowed to replace it. A stock-only job should have a clear boundary around stock. If descriptions are edited in the shop, leave them outside that update.
For example, a homeware shop might accept supplier availability but retain its own care instructions, photographs and delivery wording. A later supplier file with empty description cells should not become an instruction to remove that work. Ask how the chosen tool treats an empty value, an omitted column and a missing product row; those can be three different operations.
Where the built-in bulk editor fits
WooCommerce’s bulk-editing documentation describes applying selected changes from the Products list and notes its limitations with complex product types. It is a useful starting point for shared changes to simple products. It is less suitable for managing a different set of options and values across many variable products.
Keep the selection small enough to recognise. If the task is to change delivery handling for a group of large items, filter and inspect that group rather than selecting the entire shop and hoping the change is harmless elsewhere. Check one affected listing and an unaffected listing after saving.
A variation range needs more thought. A product-level change may not do what you intended for each sellable size or colour. Use the existing variation and stock plan to identify the records involved before deciding how to edit them.
When a spreadsheet is easier to control
A spreadsheet suits a bounded job that someone can prepare, review and sign off: new seasonal products, a corrected set of dimensions or revised values across a known range. It provides space to compare proposed changes before they reach customers.
Keep a current shop export alongside the incoming data. Match the records deliberately and make a working file containing only the intended changes. Do not assume a product name is a stable identifier: titles change, and two similar names can refer to different packs or sizes.
Give the reviewer something concrete to approve. “Update the catalogue” is difficult to check. “Update packed dimensions for these twenty simple products while keeping titles, descriptions and images” defines the job. The sample should include awkward records as well as the easiest rows.
CSV preparation still takes attention every time. If someone repeatedly repairs the same supplier columns, document that transformation. It may become part of a supported integration, or it may reveal that the supplier data is too inconsistent to automate safely.
What to ask before buying an import extension
An extension earns its place when a required field, product type or repeatable workflow is unsupported or impractical in the existing tools. Write down that requirement before comparing plugin feature lists.
- Can it update the exact product and variation fields your shop uses?
- Can you restrict the fields that each job may change?
- How does it identify an existing item and handle an uncertain match?
- Can you preview proposed changes and inspect failed or skipped records?
- Does it retrieve a source automatically, and how are failed runs detected?
- Who maintains the integration when the supplier changes its file?
The separate Product CSV Import Suite documentation illustrates why the tool name matters: an extension has its own instructions. Do not assume that every product with “import” in its name provides scheduled stock synchronisation, or that a recipe for one importer applies to another.
Ask for a demonstration using representative records from your range. A feature described as “variation support” still needs to cope with your actual parent identifiers, options and unavailable combinations.
Two shop situations that need different answers
For an illustrative seasonal update, consider a shop adding a new range of mugs. It has its own descriptions and pictures, and staff count the stock on the shelf. A prepared CSV and a reviewed sample can handle the launch, followed by ordinary product editing. A permanent supplier feed may add work without supplying useful information about the shop’s own stock.
Now consider a shop offering items dispatched by a supplier whose availability changes regularly. A successful file import establishes only the data at that point in time. The ongoing job includes refreshing it, recognising stale data and deciding what customers see during a failure. That situation needs a feed and exception-handling plan, even if the first load uses a CSV.
Agree what a successful update looks like
Before the first live run, record the intended products, allowed fields, expected changes and checks for information that must stay intact. Include an exception such as an unknown SKU or missing image so the test shows how the workflow stops or asks for help.
Check the storefront as well as the product editor. A value saved in the intended field may still appear incorrectly in a template, selected variation or delivery calculation. If pictures fail to arrive, use the one-file image-import diagnosis before retrying the catalogue.
Keep orders and other trading activity outside the repair unless the work specifically concerns them. Restoring yesterday’s whole database to undo a product update can also replace activity that happened afterwards. Agree the recovery method for the particular change.
If you need help choosing or implementing the process for a shop in Formby, Freshfield or L37, send your shop URL and a description of the catalogue task. A few anonymised example rows, the fields that should change and the fields that must stay intact make a useful starting brief. Leave passwords and customer information out of the enquiry.
