WooCommerce Product CSV Import Not Working? Fix the Delimiter, Mapping, Encoding and Images

Last updated: August 2026 · By the CSVUndo team · 8 min read

A WooCommerce product CSV import that fails — or lands in the wrong fields — almost always has one of four causes: the file is semicolon-delimited while the importer is splitting on commas, the header names don’t match anything the column-mapping screen recognises so columns default to “Do not import”, the file isn’t UTF-8 — or already has mojibake baked in — so product descriptions arrive as � or é, or the Images column holds URLs your server can’t fetch. All four are fixable: type the real separator into the importer’s CSV Delimiter field under Advanced options, map unmatched headers by hand on the mapping screen, re-encode the file as UTF-8, and give every image a full public URL inside one quoted field. This guide walks through each fix in the order the importer hits them.

Which WooCommerce CSV import problem do you have?

Find your symptom in the first column, then jump to the matching section. WooCommerce rarely refuses a whole file outright — it works row by row and reports the tally at the end, so a bad image URL fails its row loudly while a dropped column passes without a word.

Why does WooCommerce cram every product into one column?

Because the importer split your rows on commas and your file doesn’t use commas. Excel on European regional settings saves “CSV” with semicolons — the comma is reserved as the decimal separator there — so WooCommerce sees one enormous header called SKU;Name;Regular price;Description…, matches nothing, and offers you a single unmappable column. A tab-separated export from a database or ERP produces the same one-column symptom. Our guide to why Excel saves CSV with semicolons explains the locale rule, and a CSV that opens in one column covers the same disease in Excel itself.

You have two clean fixes, and both are quick:

• Tell the importer the truth. On the first screen of Products → All Products → Import, expand Advanced options (it hides below the Update existing products checkbox) and type ; into the CSV Delimiter field. The same file now splits perfectly, no editing needed.
• Standardise the file to commas, so it works in WooCommerce and everywhere else you’ll ever send it.

One caution if you convert by hand instead: any field containing the new delimiter must be quoted afterwards, or it splits. The converter does this automatically; a text-editor replace does not.

Why does the column-mapping screen say “Do not import”?

Because WooCommerce auto-maps only the header names it already knows. Step two of the importer is the column-mapping screen: each header in your file is matched, case-insensitively, against the names WooCommerce writes when it exports products — ID, Type, SKU, Name, Published, Short description, Description, Regular price, Sale price, Categories, Tags, Images, Stock and the rest — and against the equivalent field slugs such as regular_price or short_description. A header it recognises is mapped for you; anything else defaults to Do not import and is dropped without a word of complaint.

That single rule explains most “my column vanished” reports:

• Files from other platforms. A Shopify export says Title, Variant SKU and Body (HTML); an ERP might say price_gbp or ITEM_NO. None of these auto-map. Open the dropdown beside each column and point it at the right WooCommerce field — a one-time chore, and the mapping holds for the whole import.
• Typos in headers you wrote yourself. Regular Price (£) or Regularprice is a stranger to the importer. There is no error — the prices simply never arrive.
• A decorative first row. If someone typed “Products — July” above the real headers, that becomes the header row. Delete everything above the actual column names.
• An invisible byte at the front. If an otherwise perfect file refuses to auto-map just its first column, a hidden byte-order mark glued to the first header name is the likely culprit — see what the UTF-8 BOM is and when it helps or hurts.

Two mapping habits worth keeping: when updating existing products, always map ID or SKU, because that’s the key WooCommerce matches on with Update existing products ticked; and glance down the mapped list before clicking Run the importer — the screen is the last moment a dropped column is visible.

Why are product descriptions garbled after the import?

Because the bytes were wrong before WooCommerce ever saw them. WordPress stores text as UTF-8 and WooCommerce’s docs ask for UTF-8 files. The importer’s Advanced options do carry a Character encoding of the file dropdown, but it is set to Autodetect by default — and if your host lacks the mbstring PHP extension the importer warns that the file “will be treated as UTF-8” and characters in other encodings may be removed. Two different failures produce “garbage in the descriptions”, and they look slightly different:

• The file is ANSI / Windows-1252. An accented byte like é saved by old-style Excel isn’t valid UTF-8, so if autodetection guesses wrong it arrives as � or the character is dropped. Either pick Windows-1252 in the importer’s Character encoding of the file dropdown, or re-encode the file to UTF-8 — our walkthrough on changing a CSV’s encoding to UTF-8 shows three free ways, and the encoding checker tells you in seconds what you actually have.
• Mojibake was already baked in. If an earlier Excel round-trip turned Café into Café inside the file, the import “succeeds” — and Café is now live on your storefront. Re-encoding won’t help; the characters themselves need repairing with the broken-characters fixer before you re-import with Update existing products ticked.

The same trip through Excel that mangles accents usually mangles identifiers too: barcodes in the GTIN field collapse to 8.85909E+11 and SKUs like 0071589 lose their zeros — the mechanics are in why Excel converts numbers to scientific notation and why leading zeros disappear. Our repair tools fix both, with one deliberate limit: they never flag a value as Excel damage on shape alone, because 2E5 can be a genuine part number, so you confirm which columns get repaired.

Excel keeps at most 15 significant digits, so every digit from the 16th onward in a barcode or serial number is replaced with a zero the moment the file is opened and saved. Digits truncated that way are no longer in the file, and no tool can regenerate them — those rows need a fresh export from your source system. The full story is in why Excel changes 16-digit numbers to zeros.

Why don’t product images import from the CSV?

Because the Images column is a list of URLs your server must fetch, live, during the import. WooCommerce takes each address in the Images field, downloads it into the Media Library, and attaches it — the first URL becomes the featured image, the rest become the gallery. If the server (not your laptop) can’t retrieve even one of those addresses, WooCommerce abandons that whole row: the product is never created, and it is listed on the final screen under “Failed to import” with a Reason for failure in the import log. The usual culprits:

• Local paths. C:\photos\mug.jpg means nothing to your web host. The image must already be online — on your own site, a CDN, or any public server.
• URLs behind a login, on a staging site that blocks outside requests, or blocked by a firewall. The fetch fails and WooCommerce rejects the whole row rather than importing the product without pictures.
• Unencoded spaces and accents in filenames. blue mug.jpg should be blue%20mug.jpg. Encoding damage from the previous section hits here too: an é inside a URL breaks the fetch.
• A split URL list. Multiple images are separated by commas inside one field — so in a comma-delimited file that field must be quoted. A hand-done delimiter conversion that loses the quotes sprays your gallery URLs across neighbouring columns, which then ruins the mapping as well. (The converter above re-quotes such fields automatically.)

If the images are already in your Media Library, you can reference them by filename instead of a full URL. And on shared hosting, remember every image is a fresh download at import time — a thousand-product file with four images each can simply outlive the server’s patience, so import large catalogues in batches.

How do you prepare a WooCommerce CSV that imports first time?

Six habits cover essentially every failure on this page:

1. Keep an untouched copy of every export. Repairs work on what survives; the original is the only perfect backup.
2. Never double-click a CSV into Excel. Open a blank workbook and use Data → From Text/CSV with SKU and barcode columns typed as Text — or edit in Google Sheets, which stays UTF-8 throughout.
3. Save as CSV UTF-8 (Comma delimited) — that one choice prevents the delimiter problem and the encoding problem at once.
4. Test with ten rows first. Import a small slice, check the mapping screen, a description with an accent, and one product’s images — then run the full file.
5. Mind the upload cap. WooCommerce inherits your host’s PHP upload limit, often just a few megabytes on shared hosting. If your catalogue is bigger, our CSV splitter cuts it into parts with the header repeated in each; being honest about our own limits, it accepts files up to 60 MB and warns above 12 MB, because the whole split runs in a single browser tab.
6. Re-run imports with Update existing products ticked, so rows matching an existing ID or SKU are updated in place instead of raising duplicates — but rows that match nothing are skipped, not created, so bring brand-new products in on a separate pass with the box unticked.

Frequently asked questions

Sources: the importer flow, the CSV Delimiter advanced option, the column-mapping behaviour and the Images column format are documented in WooCommerce’s own product CSV importer and exporter reference; the delimiter, encoding and number-damage patterns are the same Excel behaviours covered throughout the CSVUndo guides.