WooCommerce Product Variations Without the Mess

Three concepts that get conflated, and keeping them distinct solves most of the problem.

• An attribute is a characteristic: size, colour, material. It has values — small, medium, large.
• A variation is a purchasable combination of attribute values, with its own price, SKU, stock and image. Blue, medium, cotton.
• A product is the thing a customer thinks of as one item, containing its variations.
• Attributes can also exist without being used for variations, purely as specifications shown on the product page. That distinction — 'used for variations' or not — is the setting people miss.

Global attributes are taxonomies, defined once under Products → Attributes and reused across the catalogue. Custom attributes are defined per product and exist only on that product.

Use global attributes for anything a customer might filter or browse by, and for anything appearing on more than a handful of products. They're indexed as taxonomies, which makes filtering fast, and they give you consistent values — one 'Blue', not fourteen spellings of it.

Use custom product attributes for genuinely one-off specifications: this particular item's warranty length, or a dimension that applies to nothing else.

The common mistake is custom attributes for colour and size across a whole catalogue, which makes filtering slow or impossible and leaves you with inconsistent values that can never be tidied.

Every attribute multiplies the variation count. Three colours and four sizes is twelve variations — manageable. Add five materials and you have sixty. Add a length and you're in the hundreds.

WooCommerce's variation admin loads and saves these in batches, and it becomes genuinely painful somewhere in the low hundreds. The product edit screen slows, bulk edits time out, and imports start failing.

• Don't generate every possible combination if you don't sell them all. Create only the variations that exist.
• If an attribute doesn't affect price, stock or image, it probably shouldn't be a variation attribute at all — make it a specification.
• Consider whether one attribute should be a separate product instead. A customer choosing between 'blue' and 'red' is choosing a variation; a customer choosing between 'standard' and 'pro' is often choosing a product.
• Watch for attributes that are really the same thing expressed twice, which doubles the count for nothing.

The test is how a customer thinks about it, not how your inventory system does.

• Would someone search for one and not the other? Separate products.
• Do they need different descriptions, different images throughout, or different specifications? Separate products.
• Would you want them to rank separately in search? Separate products — variations don't get their own URLs by default.
• Are they the same item in a different size or colour? Variations.
• Is the difference purely one a customer picks at the point of buying? Variations.

• Decide early whether stock is tracked at product or variation level. Changing it later means touching every product.
• Give every variation a SKU. Without them, order management, returns and any integration with an inventory system become guesswork.
• Set prices per variation only where they genuinely differ; a variation inheriting the parent price is one fewer thing to keep in sync.
• Be careful with variation-level sale prices and scheduled sales — they're easy to set and easy to forget, and an expired sale price left in place is a common cause of confusing behaviour.
• Watch the price range shown on archives. A product ranging from a very low to a very high price looks odd and sometimes signals that it should be two products.

Variation images replace the main product image when that variation is selected, which is what customers expect for colour. Set them for the attribute that visually changes the product, and don't bother for ones that don't.

The gallery doesn't switch by variation in core WooCommerce — only the featured image does. If customers need to see three angles of each colour, that's either an extension or an argument for separate products.

Keep variation images the same dimensions as the main image, or the layout shifts every time someone changes a selection.

• Variations are stored as child posts with their own meta, so a catalogue of 500 products with 20 variations each is 10,000 extra posts. That's fine, but it's why the database grows quickly.
• Make sure WooCommerce's lookup tables are populated — they exist to make attribute filtering and price queries cheaper, and they can fall out of date after a bulk import.
• Price-range filtering and sort-by-price on a variable catalogue are among the heaviest queries a store runs. Test them with real data volumes.
• Reduce products per archive page. Each variable product on an archive costs more than a simple one.
• Use persistent object caching. On a variable catalogue it matters more than anywhere else.

A variable catalogue is built by import, not by hand, past a certain size. Get the CSV structure right before importing thousands of rows: parent products and variations are separate rows related by SKU, and the attribute columns have a specific format.

Import a handful of products first and check them thoroughly — attributes assigned correctly, variations generated, prices and stock in the right place. An import of 5,000 products with a structural mistake is much harder to undo than to prevent.

Keep the source data somewhere outside WordPress. When something goes wrong, re-importing from a clean source beats repairing in place.

• The product edit screen takes many seconds to load or save.
• Nobody can explain why a particular combination exists.
• Attribute values have inconsistent spellings or duplicates.
• Customers regularly contact you confused about which option to pick.
• You need an extension to make the variation selector usable.
• The price range on archives spans an implausibly wide band.