WooCommerce Variation SKUs: a Naming Scheme That Survives 500 Products

SKUs are one of those things nobody plans and everybody eventually regrets. The scheme you invent for your first twenty products quietly becomes the scheme for your two thousandth, and by then it’s printed on labels, embedded in supplier orders and copied into your accountant’s spreadsheet.

This is about WooCommerce variation SKUs specifically: whether variations need their own, what a pattern that survives looks like, and the handful of rules that stop you having to renumber a catalogue later.

What a SKU is for

A SKU — stock keeping unit — is your internal code for one distinct sellable thing. You invent it, you own it, and its only job is to be unambiguous.

What it is not:

• Not a barcode. A GTIN / EAN / UPC / ISBN is allocated by the manufacturer and is the same in every shop in the world. WooCommerce has had a separate field for it since 9.2 — that’s where printed retail barcodes belong. Putting an EAN in the SKU field works for scanning and makes a mess of everything else.
• Not a product description. BLUE-COTTON-TSHIRT-SUMMER-2026-SALE is not a code, it’s a sentence with hyphens.
• Not a place to store data that changes. More on this below; it’s the mistake that hurts most.

Should variations have their own SKU?

Yes — every stock-managed variation, without exception.

The reason is that everything downstream of the product page operates at variation level. Picking an order means finding the Medium Blue, not the t-shirt. Counting stock means counting Mediums and Larges separately. Reordering means telling a supplier which sizes ran out. A variation with no SKU can’t be scanned, which means it can’t be counted properly either — you’ll be typing product names into a search box while holding a barcode scanner.

WooCommerce enforces SKU uniqueness across products and variations, which is helpful: it means a duplicate is a save-time error rather than a discovery you make six months later while investigating a stock discrepancy.

A scheme that survives

The pattern that works for almost every small catalogue:

[PRODUCT]-[AXIS1]-[AXIS2]

TSHIRT-RED-S · TSHIRT-RED-M · TSHIRT-BLUE-L

Three properties make it work:

• The product token is stable. It identifies the family, not the season or the price.
• The axis order is fixed. Colour always before size, on every product, forever. This is what lets you sort a list and have it group sensibly.
• The tokens are predictable. Red is always RED, never R on one product and RD on another.

If your catalogue is large or spans obviously different families, put a short family code in front: TS01-RED-S, HD02-BLK-XL. Slightly less readable, considerably easier to sort and to search by supplier or range.

Rules that save you later

1. Never encode anything that changes

Price, season, supplier, sale status, discount tier. All of these look stable when you invent the scheme and all of them move. A SKU containing -2026 becomes a lie in January; a SKU containing -1999 becomes a lie the first time you change the price. When the data changes you’ll either live with a wrong code or renumber — and renumbering is the thing this whole article exists to prevent.

2. Keep a fixed length per token where you can

S, M, L, XL is fine because it’s short and unambiguous. Where you have many values, fixed-width codes sort predictably: 001 through 120 rather than 1 through 120, which sorts as 1, 10, 100, 11.

3. Avoid ambiguous characters

Capital O and zero. Capital I, lowercase l and one. These are fine on screen and awful on a printed label read out over the phone by someone in a stockroom. Pick one of each pair and never use the other.

4. Uppercase, hyphens, nothing else

No spaces, no slashes, no ampersands, no accented characters. SKUs end up in CSV exports, URLs, barcode labels and accounting imports, and every one of those has an opinion about punctuation. A-Z, 0-9 and hyphen travel everywhere.

5. Never reuse a retired SKU

When a product is discontinued, its code retires with it. Reusing it means your sales history now blends two different things, and the day you notice is the day you’re trying to explain a margin figure.

Generate them, don’t type them

Every rule above is a rule about consistency, and consistency is exactly what humans are bad at across two hundred rows at four in the afternoon.

Generating SKUs from attribute values solves it structurally: the pattern is applied identically every time, the values come from the attributes themselves so they can’t drift, and duplicates can’t happen. In Quick Variable Products it’s one click for the whole matrix, on the same screen where you generate the variations — or you can type your own on any row where a supplier code has to win.

That last part matters. A generator should be a default, not a prison: there’s always one product where the manufacturer’s code is the code, and the scheme has to bend around it.

Changing SKUs later

Treat this as a migration, not an edit.

By the time you want to change a scheme, the old codes exist in places WooCommerce can’t reach: printed labels, supplier order histories, past invoices, accounting exports, marketplace listings, a spreadsheet someone maintains. Changing the SKU in WooCommerce doesn’t change any of them — it just makes them disagree.

If you genuinely have to:

1. Export first. Old SKU against new SKU, one row per variation. This mapping is the entire safety net.
2. Change the new products first. Adopt the new scheme for everything you add from today, and leave the back catalogue alone until you’ve lived with it for a month.
3. Migrate by family, not all at once, and re-print labels for a family as you go.
4. Keep the mapping permanently. Someone will find a 2024 invoice and need to know what TS-4471 was.

Which is a long way of saying: spend twenty minutes on the scheme now.

A checklist before your next hundred products

• Product token decided, stable, and short enough to read aloud.
• Axis order fixed and written down.
• Value codes fixed — RED not R, and the same on every product.
• Nothing in the code that can change.
• Uppercase, hyphens, no ambiguous characters.
• Barcodes going in the GTIN field, not the SKU field.
• Generation turned on so the above happens without anyone remembering it.

Seven decisions, once. They’re the difference between a catalogue you can search and a catalogue you have to interpret.

Variation SKU FAQ

Should each variation have its own SKU?

Yes, for every stock-managed variation. Picking, counting, reordering and supplier communication all happen at variation level. A variation with no SKU cannot be scanned, so stock counts fall back to typing product names into a search box.

What is the difference between a SKU and a barcode?

A SKU is your own internal code, invented by you and unique within your shop. A barcode — GTIN, EAN, UPC or ISBN — is allocated by the manufacturer and is the same in every shop in the world. WooCommerce has had a separate field for it since version 9.2, and that is where printed retail barcodes belong.

What is a good SKU format for variations?

Product token, then each axis in a fixed order: TSHIRT-RED-S. Keep the product token stable, keep the axis order the same on every product, and use the same code for the same value everywhere. Uppercase letters, digits and hyphens only.

What should I never put in a SKU?

Anything that can change: price, season, supplier, sale status. A code containing the year becomes a lie in January and a code containing the price becomes a lie the first time you reprice. Also avoid characters that are ambiguous on a printed label, like capital O against zero.

Should I generate SKUs automatically or type them?

Generate them. Every rule about SKU schemes is a rule about consistency, and consistency across two hundred rows is exactly what people are bad at. Generation applies the pattern identically every time and cannot produce duplicates — but it should still let you override a row where a supplier’s code has to win.

Can I change my SKU scheme later?

You can, but treat it as a migration rather than an edit. Old codes live on printed labels, past invoices, supplier order histories and accounting exports that WooCommerce cannot reach. Export an old-to-new mapping first, adopt the new scheme for new products, and migrate the back catalogue family by family.