← Back to blog

WooCommerce Variations Explained: Plan Attributes, SKUs and CSV Imports Without Creating a Mess

A practical workflow for planning WooCommerce variable products: calculate attribute combinations, design stable SKUs, avoid impossible variations, and prepare safer CSV imports.

Variable products look simple when a product has one attribute. Add several colors, sizes, materials or pack sizes and the catalog can become difficult to reason about very quickly. The problem is not WooCommerce itself; it is usually the planning that happens before the variations are created.

This guide shows a practical way to plan combinations, SKUs and CSV data before you create dozens—or hundreds—of child variations. If you want to calculate the combinations while reading, use the WooCommerce Variation & SKU Generator.

Start with the combinations, not the WooCommerce editor

For each attribute that is used for variations, count the values you actually intend to sell. The maximum number of combinations is the product of those counts.

For example:

  • Color: Black, White, Navy = 3 values
  • Size: S, M, L, XL = 4 values
  • Material: Cotton, Polyester = 2 values

The full Cartesian product is 3 × 4 × 2 = 24 possible combinations. That number is useful before you build anything because it tells you how much inventory data, pricing and maintenance the product may require.

It does not mean you must create all 24. If Navy is only available in cotton, or XL is unavailable in one material, those impossible combinations should be removed from the plan rather than created and disabled later without a reason.

Understand what a WooCommerce variation actually stores

WooCommerce treats a variable product as the parent and its variations as child records. Official WooCommerce documentation notes that individual variations can have their own SKU, price, stock information, image and other product data. That is why a variation plan needs more than a list of labels.

A useful planning sheet normally needs at least:

  • the parent product identifier;
  • the selected value for every variation attribute;
  • a stable variation SKU where your workflow uses SKUs;
  • regular and sale price where relevant;
  • stock or stock status;
  • any variation-specific image, weight or dimensions your catalog requires.

If most of those fields are identical across every child, WooCommerce bulk editing can save time after creation. But the combination list still needs to be correct first.

Design a SKU system that remains understandable

A variation SKU is most useful when it is stable, unique and predictable. A common pattern is:

PARENT-COLOR-SIZE

For a T-shirt, that might become TSHIRT-BLK-M. The exact abbreviation is less important than consistency. Decide whether Black becomes BLK or BLACK once, document the rule, and keep using it.

Avoid putting data into a SKU that is likely to change, such as the current price. A SKU is an identifier, not a description of every property. Changing identifiers unnecessarily makes inventory feeds, marketplace mappings and future CSV updates harder to reconcile.

Should every variation have an SKU?

WooCommerce can work without an SKU on every variation, but stable unique identifiers are valuable for inventory, integrations and imports. The WooCommerce REST API describes the variation SKU as a unique identifier, and WooCommerce’s CSV guidance relies heavily on IDs and SKUs when matching existing products during updates.

There is an important limitation to any offline SKU generator: it cannot know what already exists in your store. A generated SKU can be internally unique within the new list and still collide with an existing product. Check the live catalog before importing.

Parent and variation attributes must agree

One of the easiest CSV mistakes is to generate child combinations that the parent product does not actually declare.

Suppose the parent has a Size attribute with S, M, L. A child row that selects XL does not become valid simply because its SKU looks correct. The parent needs to offer the value used by the variation.

WooCommerce’s current core CSV documentation is explicit about this relationship. For a variable product, the parent row lists the available attribute values; each variation row selects the appropriate value and references the parent.

This is why I recommend generating the combination matrix first, removing impossible combinations, and only then preparing the WooCommerce import rows.

Do not confuse a planning CSV with an import-ready CSV

The WPToolix generator intentionally exports a compact planning file containing variation type, generated SKU and attribute selections. That is useful for reviewing the catalog, but a production WooCommerce import often needs more context.

A core WooCommerce variation import can require fields such as:

  • Type set to variation;
  • a unique SKU or another supported identifier;
  • Parent referencing the parent SKU or an ID in the expected format;
  • matching attribute name/value columns;
  • price, stock and other product data appropriate to the store.

Use the generator to solve the combinatorial and naming problem. Then adapt the output to your actual import schema rather than assuming a generic CSV can know every store’s requirements.

WooCommerce 11.1 changed an important update-import case

Current WooCommerce documentation describes a useful behavior introduced in WooCommerce 11.1. During an Update existing products import, an unmatched variation can be created instead of skipped when specific conditions are met: its parent matches an existing variable product, it has a supported stable identifier, and its attributes and values already belong to that parent.

WooCommerce 11.1 also allows a simple product to be converted to variable and new variations to be created in one update import when the parent row appears before its variation rows and the required conditions are satisfied. On older versions—or when row order cannot be guaranteed—the documented workflow uses separate passes.

This is a good example of why an import workflow should be based on the WooCommerce version actually running on the destination store rather than a CSV tutorial written years ago.

Why variation order and identifiers matter in migrations

When moving a catalog between stores, it is tempting to treat each row as independent. Variations make that assumption unsafe because parent relationships must survive the migration.

Before a migration, I would verify:

  1. Every parent variable product has a stable identifier.
  2. Every variation references the intended parent.
  3. Variation SKUs are unique where SKUs are used.
  4. Attribute names and values match the parent.
  5. The parent rows are available before child rows when the chosen WooCommerce import workflow requires that order.
  6. A small representative variable product imports correctly before the full catalog is attempted.

After building the final WooCommerce CSV, run it through the WooCommerce CSV Import Doctor to catch common duplicate-SKU, parent and data-quality problems before the production import.

A practical workflow for a product with many options

Here is the sequence I recommend when planning a new variable product or rebuilding supplier data:

  1. Normalize the attribute names. Decide whether the catalog uses Color or Colour, Size or Product Size, and keep it consistent.
  2. Normalize values. Avoid accidental duplicates such as Dark Blue, dark blue and Dark Blue .
  3. Calculate all possible combinations. This exposes the true size of the product before data entry begins.
  4. Remove combinations that cannot be sold. Do not create inventory records simply because mathematics produced them.
  5. Generate stable SKUs. Use a documented pattern that will still make sense next year.
  6. Add commercial data. Price, stock, image, dimensions and other fields belong after the combination list is stable.
  7. Build the WooCommerce import structure. Add parent references and the exact columns required by your workflow.
  8. Preflight the CSV. Check identifiers and relationships before import.
  9. Test a small sample. Confirm the resulting product in WooCommerce, including frontend selection and stock behavior.

What to check when a variation exists but does not appear to customers

Not every missing option is an import problem. WooCommerce’s current troubleshooting guidance calls out several common causes: a variation without a price, out-of-stock visibility settings, an incorrect parent product type, attributes not configured for variations, caching/theme issues, or a combination that was never generated in the first place.

So verification should include the frontend product, not just the Products list in wp-admin. Select several combinations, check the price and stock response, and confirm that intentionally excluded combinations are unavailable.

Use tools to reduce repetitive work, not to guess business rules

Combination generation is deterministic, which makes it a good job for a browser tool. Deciding whether a red XL product should exist, what it costs, which warehouse owns its stock, or whether it needs a unique image is business data. A generator should not invent those answers.

That boundary is intentional in the WPToolix Variation & SKU Generator: it generates and filters combinations and produces predictable identifiers, while leaving prices, stock and store-specific relationships under your control.

Frequently asked questions

How do I calculate the number of WooCommerce variations?

Multiply the number of values in each attribute used for variations. Three colors and four sizes create up to 12 combinations. Add two materials and the maximum becomes 24.

Does WooCommerce automatically create every attribute combination?

No. Attribute values and actual variation records are separate concepts. Variations must be generated, created manually or created through an import/API workflow.

Can two WooCommerce variations use the same SKU?

Plan for unique SKUs. WooCommerce uses SKUs as product identifiers in important workflows, including CSV updates, so duplicates create avoidable ambiguity and import problems.

What should the Parent field contain in a WooCommerce CSV?

For the core importer, WooCommerce documents the parent product SKU or an ID prefixed in the expected form, such as id:123.

Should I create every mathematically possible variation?

No. Generate the possible set, then remove combinations that are not genuinely sold. Fewer meaningful variations are easier to price, stock, photograph and maintain than a large matrix filled with unavailable children.