A buyer lands on a product page, picks a size, and the price doesn’t change. Or the picture shows black and the dropdown only says “Option 2”. Or there are two products with almost the same name and no way to tell which one is the case and which is the single. That buyer leaves. Most of the time the cause isn’t the theme or the checkout. It’s the product data underneath, and it usually starts with confusion about product variants vs attributes.
I spent years running catalogs at Universal Wholesale, where the Universal Wholesale and United Textile stores held more than 14,000 SKUs between them, and then at Wild Bill’s Tobacco on a wholesale B2B site where pack size mattered on every order. Getting the structure right was the difference between a catalog that sold itself and one that generated phone calls.
What is the difference between product variants and attributes?
An attribute is a property that describes a product. Size, color, material, flavor, pack count. A variant, which WooCommerce calls a variation, is a specific buyable version of a product created from one or more of those attributes. A crew neck tee is the product. Size and color are attributes. Black, size medium is a variant.
The test I use is simple. If the customer has to choose it before adding to cart, and choosing it changes the price, stock or the item that ships, it’s a variant. If it only describes the product and doesn’t change what ships, it’s a plain attribute that shows up in the specs and the filters.
So material on a tee is usually just an attribute. Size is a variant. Pack count on a wholesale item is almost always a variant, because a case of twelve and a single unit are different things on the shelf and on the invoice.
One SKU per thing that ships
Every variant gets its own SKU. Not the parent. Not “same as the medium”. If a picker in the warehouse can pull it as a separate item, it needs a separate code. When variants share a SKU, stock counts drift, orders get pulled wrong, and imports overwrite the wrong row.
The parent product can have a SKU too, and I give it one so it’s easy to find in exports. But nobody ever buys the parent. The parent holds the shared story: the name, the description, the main images, the category. The variants hold the things that change.
How I name SKUs
There are a lot of opinions about SKU naming conventions. Mine is short: build the code from the parent code plus the attribute values in a fixed order, with readable abbreviations, and never reuse a code.
- Parent first, so all variants sort together in a spreadsheet.
- Attributes in the same order every time. If it’s color then size on one product, it’s color then size on all of them.
- Short, readable values. BLK and WHT, not 001 and 002. A person should be able to guess the item from the code.
- No spaces, and no characters that cause trouble in CSV files or URLs.
- Don’t encode things that change, like price or supplier. Those go in their own fields.
If a supplier already has a code system, I keep their code in a separate field. Your SKU is for your store. Their code is for reordering. Mixing them means a supplier change rewrites half your catalog.
Attribute values need one spelling
This is where most catalogs quietly fall apart. Over a few years and a few people, “Black”, “black”, “Blk” and “Jet Black” all end up as separate values. On the shop page that becomes four color filters, and clicking any one of them shows a fraction of the black products.
I keep a short list of allowed values for each attribute in a spreadsheet tab and check new product files against it with a lookup before they go anywhere near the store. In WooCommerce I prefer global attributes, set up under Products, Attributes, over custom ones typed into each product. Global attributes share the same terms across the store, so filters and layered navigation actually work.
Pack size is a variant, not a footnote
On wholesale sites, the most expensive confusion I’ve seen is about pack size. The title says one thing, the image shows a display box, and the price is for a single unit. The buyer orders thinking they’re getting a case.
I make pack size an attribute with explicit values like “Single”, “Box of 12” and “Case of 6 boxes”, and I make it a variant when both options are sold. The variant name shows up in the cart and on the invoice, so there’s no question what was ordered. I also put the count in the variant description. Saying it twice costs nothing.
Fixing a messy catalog without starting over
- Export everything, including variations, into Excel.
- Pivot each attribute to see every value in use and how often it appears.
- Write a mapping of bad value to good value on its own tab.
- Apply the mapping with a lookup, then check counts before and after.
- Find variants with blank or duplicate SKUs and assign codes using your naming rule.
- Import back in small batches and check the front end after each one.
It’s not glamorous work. But when a buyer can see at a glance what they’re getting, in the size, color and pack they meant, they stop hesitating. Pick one product line this week, map its attributes, and give every variant its own SKU. You’ll see the pattern for the rest of the catalog.