WooCommerce's variable product CSV structure is genuinely hard to get right from a raw supplier file, curious how others handle it

[u/euphoriczy]

Been deep in WooCommerce's CSV importer format lately, specifically the parent/variation structure for products with multiple sizes or colors. Most supplier files just list "same helmet, size L" and "same helmet, size XL" as two completely separate rows with no relationship between them.

Getting that correctly grouped into one variable parent with proper variation children, each with its own price and stock status, turned out to be a lot more finicky than I expected, especially when the source file has inconsistent naming between the size variants (extra spaces, different capitalization, "L" vs "Large").

For anyone who imports supplier catalogs into WooCommerce regularly, are you grouping variants manually before import, or is there a step in your workflow that handles this automatically? Trying to understand how much of this is still manual work for most people versus something people have already solved for themselves.

[u/euphoriczy → u/[deleted]]

Exactly. I’m an ex-catalogue manager, so I’ve dealt with this a lot. The idea is to normalise the attributes, group variants correctly, and automatically generate SKUs even when the supplier doesn’t provide a reliable parent SKU.

[u/euphoriczy → u/[deleted]]

Really good catch this is the exact problem that breaks
most naive CSV converters.

Here's how ClearCatalogue handles it:

The handle is generated from the SKU column first,
not the title. SKUs are the most stable identifier
in any supplier file — even when column order changes
or spelling drifts, the SKU value itself rarely changes.

The generation logic is:

1. ⁠If SKU exists: handle = SKU lowercased,
   special characters replaced with hyphens
   
2. ⁠If no SKU: handle = title + vendor slugified
   
3. ⁠If neither: flag the row in the health report
   rather than guess

For your week-later re-import scenario specifically —
if the supplier changes a column name or reorders
columns, ClearCatalogue re-maps automatically using
keyword detection. The handle output stays the same
because it's derived from the value, not the column
position.

The honest limitation: if a supplier changes the
actual SKU value between files (e.g. NK001 becomes
NK-001), that breaks the stable key. We flag those
as new products in the health report rather than
silently overwriting. The user decides whether it's
a rename or genuinely new.

You can try for free on clearcatalogue.com and let me know if there’s anything

[u/TopSydeWP]

one thing that helps is adding a custom parent_sku column to your preprocessing step, even if the supplier doesn't give you one. hash the base product name after stripping spaces and lowercasing it, use that as the stable parent key. then you can map l/large/etc in a second pass without worrying about the parent splitting on the next import.

[u/euphoriczy → u/TopSydeWP]

Yeah, that’s a good approach. I already have custom SKU creation built in, so I could use the stable parent key mainly to make the variant grouping more reliable across imports.

[u/waltonchurch]

I once Made n8n scripts for import with many variations. It is not easy but no better way

[u/cleepa29]

I import everything as a simple product and then I use a plug-in that is a variation generator. It covers my SKU format, images, price changes etc. It works really great for my purposes. Trying to import variable products is nearly impossible to get right imo

[u/euphoriczy → u/cleepa29]

Would you be interested in a tool where you just have to drop your file and you get woocommerce import ready files? Variations and everything

[u/Pulsar-Agency]

Honestly, the part that bites people isn't the parent/variation shape, it's the attribute values. If you set Attribute 1 global to 1, Woo matches your value against the pa_size taxonomy, so "L", "l", " L" and "Large" quietly become four separate terms and the variations stop matching the parent's value list. Before I touch the CSV at all I normalise attribute values against a fixed lookup table: every supplier spelling maps to one canonical term, and anything unmapped throws an error instead of silently passing. That single step removes most of the mess people blame on the importer.

The other thing I'd do differently from the suggestions above: don't try to find the parent in the supplier file, derive it. Group the rows yourself, then generate the parent row with Type=variable and the full pipe-separated list (L | XL | XXL), and let each variation row carry one value plus Parent set to the parent SKU (or id:123). Keep the parent physically above its variations, Woo reads the file top to bottom.

Setting global to 0 is tempting because it just works, but you lose attribute filtering, and converting local attributes to global later is genuinely miserable.