TL;DR
- A supplier CSV rarely fits WooCommerce on the first try. The supplier exports their internal headers. WooCommerce reads its own 37-column structure with strict product-type enum, hierarchical category delimiter, and SKU uniqueness. Capitalization creates duplicate taxonomy terms (Blue and blue become two separate attributes).
- AI WooCommerce field mapping feeds an AI chat three artifacts — the supplier CSV headers, two realistic sample rows, and the WooCommerce structure reference. The chat returns a column-by-column mapping plus cleanup transforms (SKU normalization, category taxonomy with consistent casing, attribute normalization) plus a manual-review flag on any row the chat cannot map confidently.
- The five-step workflow runs ninety minutes per supplier catalog. Open in Google Sheets or LibreOffice Calc (never Excel). Capture headers and two sample rows. Feed the chat for a transform plan. Apply transforms in the spreadsheet with SKU and capitalization validation. Import on staging and smoke-test five random products.
- Three traps. Trusting the chat’s category match without verifying capitalization (WP All Import names the disconfirming voice — the system lacks built-in validation for capitalization conflicts before import). Excel-saved CSVs corrupt SKUs starting with zero, scientific-notation long numbers, and UTF-8 special characters. Treating the import as the end — variations, attribute scope, and inventory sync still need configuring.
- A supplier import is not a one-time event. A supplier import is a recurring translation. The chat’s mapping plan from this quarter is the starting point for next quarter, not the final answer.
You have a supplier CSV. Twelve hundred rows. Forty columns of fields you did not name. The supplier ships the catalog quarterly and the column headers change every time.
WooCommerce expects its own structure. Thirty-seven defined columns. SKU as the primary key.
Hierarchical categories with a specific delimiter. A strict product-type enum. The supplier CSV does not match any of that on the first try.
You do not need a developer to bridge the gap. You need a translator — a workflow that reads both sides and produces a transform plan you apply before the import.
This piece is about how an AI chat does that translation in about ninety minutes. The walkthrough includes the staging smoke test that catches what the chat missed.
Why does a supplier CSV rarely fit WooCommerce on the first try?
A supplier CSV rarely fits WooCommerce because the two systems were not designed to talk.
Your supplier maintains an internal product catalog organized for their warehouse and accounting workflows. Their column headers reflect SKU formats they invented in 2014. Their category names match their physical aisle layout. Their attribute values were entered without a controlled vocabulary.
The export is faithful to their system. The export was never written for yours.
WooCommerce’s CSV importer reads a defined structure. The official documentation lists thirty-seven defined columns with fixed names. SKU, Name, Type, Categories, Tags, Images, Stock, Regular price, Attribute 1 name, Attribute 1 value, and so on.
The Type column accepts a strict enum — simple, variable, grouped, external, variation, virtual, downloadable. The Categories column requires hierarchical paths separated by a > character. SKU uniqueness is enforced.
The headers do not match. Your supplier sends Item Number. WooCommerce expects SKU.
Your supplier sends Section. WooCommerce expects Categories. Your supplier sends Color or COLOR or color depending on the data-entry operator that day. WooCommerce treats those as three different taxonomy terms.
The case-sensitivity gotcha is the most expensive failure mode. Capitalization creates separate taxonomy terms. "Blue" becomes one attribute term. "blue" becomes another.
"BLUE" becomes a third. Filter widgets see three terms. Customers see fragmented results. The cleanup is manual once the imports settle.
The Excel gotcha is the second most expensive. Microsoft Excel corrupts CSVs in three specific ways. Excel strips leading zeros from SKUs.
Excel converts long numbers to scientific notation. Excel mangles UTF-8 special characters in product names. Use Google Sheets or LibreOffice Calc with UTF-8 encoding instead.
The match is rarely automatic because the two systems are speaking dialects of CSV. Translation is the work.
What does AI WooCommerce field mapping actually do?
Think of an AI WooCommerce field mapping as the bilingual intern translating the shipping manifest. The intern speaks both the supplier’s internal vocabulary and WooCommerce’s structure. The intern produces a transform plan that converts one to the other. The intern flags rows the translation cannot complete confidently.
You feed an AI chat three artifacts. The supplier CSV headers (just the first row, no data). Two sample rows from the supplier CSV with realistic data, not the test SKU at the top of the file. The WooCommerce product-import CSV structure reference (the column list with notes about the Type enum, the category delimiter, and the attribute layout).
You ask for one specific output. A mapping table from supplier columns to WooCommerce columns. Cleanup transforms required per column — SKU normalization, price-currency conversion if applicable, category taxonomy mapping with consistent casing, attribute normalization. A manual-review flag on any row the chat cannot map confidently.
The output is a transform plan, not the import itself. You apply the transforms in your spreadsheet. You validate the result. Then you import.
The chat does the matching. You verify in staging.
How do you run the import in one sitting?
The work splits into five steps. None of them needs a developer.
Step 1 — open the supplier CSV in Google Sheets or LibreOffice Calc. Never Excel. Excel corrupts CSVs in three specific ways. Excel strips leading zeros from SKUs.
Excel converts long numbers to scientific notation. Excel mangles UTF-8 special characters. Save the file with UTF-8 encoding. Three minutes.
Step 2 — capture headers and two sample rows. Copy the header row to a text file. Copy two realistic sample rows — not the test SKU at the top of the file. Pick two rows that represent the actual product variety in the catalog. Open the WooCommerce CSV structure reference and copy the column list to the same text file.
Step 3 — feed the chat with one specific prompt. Paste the supplier headers, the sample rows, and the WooCommerce structure. Ask for a mapping table from supplier columns to WooCommerce columns. Ask for cleanup transforms required per column, plus a manual-review flag on any row the chat cannot map confidently. State your priorities — preserve supplier SKUs, map categories case-insensitively, set product type as simple unless variations exist.
Step 4 — apply transforms in the spreadsheet. Add columns to your sheet for each WooCommerce target field. Apply the chat’s transform plan column by column.
Validate SKU uniqueness with a duplicate-detection formula. Validate category casing matches existing WooCommerce taxonomy terms exactly. Save the result as a new CSV with UTF-8 encoding.
Step 5 — import on staging WooCommerce and smoke-test five random products. Open Products, Import in wp-admin. Upload the transformed CSV. Map columns when prompted — most should auto-match because the headers are now WooCommerce-native.
Run the import on staging first. Pick five random products from the result and check each one — correct category, correct attributes, correct price, correct image. If five random products are clean, the import scales.
What can go wrong with this approach?
Three traps catch operators on a deadline.
Trap 1 — trusting the chat’s category taxonomy match without verifying capitalization. WP All Import’s documentation names this disconfirming voice plainly. The system lacks built-in validation for attribute name capitalization or pre-existing term conflicts before import execution.
The chat’s mapping may suggest "Blue" while your existing taxonomy has "blue". The import creates a duplicate term. Filter widgets break. The cleanup is manual after the fact.
Run a manual case-insensitive comparison between the chat’s category list and your existing WooCommerce taxonomy before importing. Two minutes of cross-reference saves an hour of post-import deduplication.
Trap 2 — using Excel-saved CSVs. Excel corrupts SKUs starting with zero. A supplier SKU of 0042-RED becomes 42-RED in the saved file.
Excel converts long product numbers to scientific notation. A SKU of 123456789012345 becomes 1.23457E+14. Excel also mangles UTF-8 special characters in product names if the file was opened without explicit encoding selection.
Use Google Sheets or LibreOffice Calc with UTF-8 encoding throughout. Both handle the encoding correctly without prompting.
Trap 3 — treating the import as the end of the project. The CSV import ships products. Variations need their parent IDs linked correctly. The global-vs-local attribute decision is hard to reverse post-import — global attributes get filter widgets, local attributes do not.
Inventory sync still needs configuring if the supplier ships fresh stock weekly. The chat handles the mapping. The operational layer is still yours.
How do you spread the ninety-minute import across an afternoon and a morning?
A defensible WooCommerce import costs about ninety minutes of your time per supplier catalog.
Half a Tuesday afternoon opens the supplier CSV in LibreOffice Calc and captures headers and sample rows. The same afternoon runs the chat for a transform plan, applies the transforms, and runs the staging import. The next morning checks the five-random-product smoke test and catches whatever the chat missed.
If the smoke test passes, the import promotes to production. If it does not, the chat misread the supplier headers and the second pass refines the mapping. Two rounds of import-plus-smoke-test usually surface every translation gap. Once the import shape stabilizes, the WP-CLI scripts for repeat tasks workflow turns the quarterly run into one repeatable command.
A supplier import is not a one-time event. A supplier import is a recurring translation. The supplier ships a fresh catalog every quarter. The headers may change.
The category structure may shift. The chat’s mapping plan from this quarter is the starting point for next quarter, not the final answer. A defensible WooCommerce site treats supplier imports as a recurring practice. The transform plan saves alongside the spreadsheet for the next round.
Other questions worth answering
What happens when product images sit behind a login-walled vendor portal?
WooCommerce’s early 2025 Product CSV Importer documentation confirms the system pulls image URLs into the Media Library only when those URLs respond publicly. Login-walled vendor portals fail silently. Pre-download each image and re-host on your own server before the upload. List the public URL in the Images value.
How should variations link to their parent product on a fresh upload?
WooCommerce links each variation row to its parent product through the Parent column. Two formats work, the id:NNN syntax pointing at an existing product ID or the parent SKU on its own. LitExtension’s October 2025 guide flags unlinked variations as one of six common troubleshooting categories. Always populate Parent before running the upload.
Should color and size live as global taxonomies or per-product values?
Make it global. Global attributes earn a row in Products and Attributes, generate filter widgets, and apply across the catalog. Local attributes stay locked to a single product with no filtering.
WP All Import’s documentation lists four attribute-import settings and names the global-vs-local choice hard to reverse after the upload.
Can the loader reuse existing post IDs declared inside the source file?
No. WooCommerce’s early 2025 Product CSV Importer documentation is plain on this point. Products always get the next available post ID regardless of any ID value in the source file. The ID column matches existing products on later updates, not for assigning a chosen ID on creation.
Which column should you map first?
SKU. Always SKU. WooCommerce uses SKU together with ID to match and update products on subsequent imports.
Get the SKU column right first. The rest of the mapping follows.
The next post in this series is the custom-post-type field design that turns supplier catalogs into queryable WordPress data. That architecture decision compounds across every import after the first. The designing custom-post-type ACF fields walkthrough lays out the field shapes that make those imports queryable from the start.
If you want a calm second opinion on your transform plan before you run the staging import, you can contact me here. I read your supplier headers, look at your WooCommerce structure, and tell you which mapping to verify by hand first. There is no pitch, no upsell, and the conversation is free.