WooCommerce CSV import problems become urgent when the import finishes but your catalog no longer looks right. Images disappear, products move into the wrong categories, or customers cannot choose a variation that worked yesterday. Uploading the same spreadsheet again can turn a small mistake into a larger recovery job.
Before you reimport, answer one question: which product fields was this file allowed to change? A price update should not quietly rewrite image assignments. A category cleanup should not change stock. The safest next step is to compare one affected product against a saved baseline, then test a narrowly scoped correction away from the live store.
There is a timely reason to check this now. WooCommerce’s 11.1 pre-release announcement lists CSV improvements involving categories on reuploads, image clearing, currency settings, and variation creation. As of August 28, 2026, the final release is scheduled for September 1. Those notes justify a test; they do not prove that every import problem is a WooCommerce bug or that an update will reconstruct lost data.
WooCommerce CSV import problems: what to stop first
If a batch is still running, do not launch another copy or assume that a browser delay means nothing changed. Preserve the original file and the import result. Once the run has finished or a developer has established its state, keep further bulk catalog writes paused while you investigate.
Save a working copy of the spreadsheet under a new name. Keep the supplier’s original separately. Record the import time, the tool used, the WooCommerce version, and whether you intended to create products or update existing ones. A screenshot of the column mapping can be more useful than a vague note saying “the import failed.”
Then identify the smallest affected group. Are all products wrong, only one supplier’s rows, or only variable products? Check a product that the file did not touch as well. An unchanged product gives you a control: if its images also fail, the import may not explain the whole problem.
Do not restore yesterday’s entire database just to recover a product image. Your store may have accepted orders, customer changes, or stock movements since that backup. Our backup restore testing guide explains why a backup is useful only when the recovery method protects the data you still need.
Separate a bad product record from a display problem
Open one affected product in the dashboard and compare it with the public product page. Check the assigned image, category list, regular and sale prices, stock status, and available variations. Write down the exact mismatch rather than trying several fixes at once.
If the dashboard has the expected image but the storefront does not, investigate delivery and presentation first. A stale page, an image request failure, or a template condition can make correct data look missing. Reimporting does not help you distinguish those possibilities.
If the dashboard itself contains the wrong assignment, keep the investigation on the data-writing path. Compare the saved CSV row, the mapping used, and the record that existed before the import. A cache purge cannot restore a category that the import actually changed.
Use a logged-out browser for the storefront comparison. Test a product page and its category listing, not just the homepage. For a variable product, choose each relevant option and confirm the displayed image and price. A product can look complete until the customer selects a size or color.
Give every field a clear instruction: preserve, replace, or clear
A blank cell is not a reliable way to communicate your business intention. The importer, version, mapping, and field type determine what the software does with it. Your test should establish the behavior before a blank reaches hundreds of products.
Use this change contract before preparing a correction. It is a review method, not a claim that every importer uses the same rules.
| Your intention | What to prove in the small test | Stop if |
|---|---|---|
| Preserve an existing field | The field keeps its exact previous value when you update an unrelated field. | An image, category, stock value, or variation changes outside the agreed scope. |
| Replace a value | The intended product receives the new value, and nearby fields stay unchanged. | A second product changes, a duplicate appears, or the old value survives unexpectedly. |
| Clear a value deliberately | The tested clearing method removes only the chosen value on a staging copy. | A blank behaves differently from your expectation or removes a related assignment. |
| Create a new product or variation | The new record has the right identity and relationship without altering an existing record. | The importer updates an existing item instead, skips the row, or creates the wrong relationship. |
The built-in importer matches existing products using IDs or SKUs. Its mapping screen offers Do not import for columns you want ignored. Check the official WooCommerce CSV importer guide for the exact workflow. That guide is separate from the premium Product CSV Import Suite and other import plugins; their settings are not interchangeable.
Keep the contract short enough to review. For example: “Change the regular price for these 12 SKUs. Preserve images, categories, stock, tax class, and variation relationships.” If you cannot describe the intended change that clearly, the file is not ready for another live run.
Test five product cases before a full reimport
A random handful of easy products may miss the case that broke your catalog. Choose a small batch that represents the different writes you need. Five cases are a practical starting point, not a guarantee or a performance benchmark. Add cases for subscriptions, bundles, custom fields, or another extension-specific product type you actually use.
Use a protected staging workflow with outbound customer emails, live payments, supplier writes, and external stock synchronization isolated as appropriate. Copying a store should not trigger real business activity.
| Test case | Intended change | Evidence to retain |
|---|---|---|
| Unchanged control product | No change; leave this product outside the imported batch. | Before and after product data and storefront appearance remain the same. |
| Simple product with existing images | One price change only. | Expected price changes; gallery, category, stock, and visibility remain intact. |
| Product in several categories | One deliberate category correction. | The final category set matches the written intention; no unrelated assignments disappear. |
| Product with a featured image and gallery | One deliberate image replacement or clearing test. | The intended assignment changes; remaining images keep the expected order and display. |
| Variable product family | One planned variation change or creation. | Correct parent relationship, selectable options, price, stock, and add-to-cart behavior. |
Take the baseline before the test, not after discovering a mismatch. Keep a product export plus screenshots of the fields that matter. Save the exact test file and mapping. Then compare the result against the contract, including the fields you intended to preserve.
If one case fails, stop the expansion. Repeating the failed row with more products does not increase confidence. Change one cause on staging, rerun the same small case, and retain both results so you can explain what fixed it.
When WooCommerce CSV import problems affect images
Start by deciding whether the image file is missing or the product’s image assignment is wrong. Those are different recovery tasks. Do not delete media files simply because a product stopped displaying them; another product or page may still use the same file.
WooCommerce’s built-in importer expects images that already exist in the Media Library or are directly accessible online. A cloud-sharing page is not necessarily a usable image URL. The core importer also does not update image alt text, so treat accessibility text as a separate verification step.
For a supplier image problem, compare one working URL with one failing URL. Note whether the failure affects new images only or existing assignments too. Ask the supplier for the actual image asset when the provided link opens a sign-in screen or sharing interface.
After a successful correction, inspect both the main product image and the gallery. Check the selected variation on mobile as well. Keep image compression or format changes out of the same trial; otherwise you add another variable to an already unclear result. The product-page performance guide is the next step once the correct images reliably appear.
WooCommerce CSV import problems with categories or variations
For categories, compare complete assignments rather than checking only whether the new category exists. A product moving into “Summer” while losing “Clothing” is not a successful result if both were meant to remain. Record the final set you expected before testing another file.
For variations, inspect identity and relationships before rebuilding the product. The built-in schema distinguishes the parent product from its variation rows. Each variation needs a unique identity and the intended parent and attributes. A row that describes a new variation is not the same operation as a row that updates an existing one.
Keep parent changes and variation changes separate in your review. If you combine new sizes, image replacements, stock changes, and price changes in one unexplained retry, you make the result much harder to audit.
Once the data looks correct, test the buying path. Select the repaired option, add it to the cart, and verify the product and amount there. Use your approved test-payment process if checkout testing is necessary. Our WooCommerce checkout testing checklist covers the difference between a product that displays and a purchase path that works.
Will the WooCommerce 11.1 fixes repair your catalog?
Not automatically. A software fix can change how a future import behaves without knowing what your earlier product data should have been. Keep a known-good baseline and a targeted repair plan even when a release note sounds exactly like your symptom.
At the time of this review, WooCommerce 11.1 is pre-release software. Do not put a beta on a busy store solely to find out whether it repairs a damaged catalog. A developer can compare the same test case on isolated copies and assess whether the planned fix is relevant.
When the stable version becomes available, recheck the official release status and run the same acceptance batch before the full job. If your result still differs, send the vendor a minimal reproducible example with private customer data removed. The file, mapping, versions, expected result, and actual result are much more useful than “CSV is broken.”
Recover only the data that needs repair
If you know exactly which fields changed, a targeted correction may be safer than a full restore. First establish the affected products and the trusted source for each replacement value. Preserve an audit of the repair so another scheduled import does not immediately undo it.
If you do not know the extent of the damage, stop bulk changes and ask for help. A store that has kept taking orders needs a recovery plan that accounts for new activity. Product exports are useful evidence, but they are not a replacement for a full database and file backup.
Webless can scope an import repair through our WordPress development services: reproduce the failed case, inspect the mapping or integration, compare product records, and verify the corrected buying path. Send the import tool and versions, a sanitized sample, the affected product URLs, and what should have changed. Do not send passwords or customer exports in a public message.
Resolving WooCommerce CSV import problems means more than getting a green completion message. The intended catalog change must work while the rest of the store stays intact. Once that result is repeatable on a small batch, you have a defensible basis for the next production import.