A configurable product in WooCommerce is one whose final price and options are assembled from the choices a customer makes — size, material, colour, finish — rather than being a single fixed item. WooCommerce ships with one way to handle this: the variable product, which stores every combination of options as a separate variation. That works for small option sets, but it doesn't scale, and it isn't the only model available.
This guide covers what configurable products are, the two architectures available for building them, when each one fits, and how to set one up. It's the hub for our deeper articles on each topic, linked throughout.
What Is a Configurable Product in WooCommerce?
The term covers any product a customer assembles from options before buying. Out of the box, WooCommerce represents this with the variable product type, where each selectable combination is a stored variation record with its own price, SKU, and stock. A second approach — used by PriceBlueprint and described below — keeps the product as a single record and calculates the price at runtime from a set of attribute rules. Both produce a product the customer configures; they just differ in how the data is stored.
The Two Models: Variations vs. Pricing Rules
This is the one distinction worth understanding before you build a configurable catalog, because it determines how your store performs and how much work every future price change takes.
| Aspect | Variable products (variations) | Configurable products (rules) |
|---|---|---|
| Data structure | One record per attribute combination | One product + a set of attribute rules |
| 4 attrs × 4 values | 256 variation records | ~16 rules |
| Change one price | Edit every affected variation | Edit one rule |
| Reuse across products | Not possible — per product | One blueprint, many products |
| Per-combination stock | Yes | No (price, not inventory) |
| Per-variation images | Yes | No |
We cover exactly why variation counts get out of hand in why too many variations slow your store, and the full structural comparison in the rule-based pricing guide.
When You Need a Configurable Product
Reach for a configurable product whenever a single item has options that change its price: furniture sold by size and material, apparel priced by size, print-on-demand goods, made-to-order manufacturing, or service packages. If the options never affect price and you don't track stock per option, a simple product with informational attributes is enough.
How Attribute-Based Configuration Works
In the rule-based model, each attribute value carries a price modifier and the product has a base price. The final price is the base plus the modifiers of whatever the customer selected. "Material Oak adds $25" is a rule; an Oak item is base + 25. The full mechanics — base price, rule evaluation, live updates — are walked through in dynamic pricing by attributes.
Setting One Up
Short version: create a Price Blueprint with one rule per attribute value, create a product set to the Configurable Product type, assign the blueprint, and set the base price. The price recalculates live on the product page. For the full step-by-step with screenshots and a worked example, follow the setup tutorial.
Cart, Checkout, Orders, and Beyond
A configurable product only works if the customer's choices survive the whole purchase. Selected attribute values and the calculated price carry through cart and checkout and land on the order — visible in WC Admin, order emails, the Thank You page, and My Account. The model is HPOS-compatible, emits Schema.org structured data for configurable products, and supports RTL layouts and translations. Sale prices work the same as on a simple product, including scheduled dates and the strikethrough display in shop listings.
Performance Considerations
Because the rule-based model writes no per-combination records, the database footprint stays flat as you add options, and the front-end price request runs over AJAX so it doesn't conflict with full-page caching. That's the inverse of the variable-product model, whose postmeta table grows with every combination — the mechanism behind the slowdowns in the variation bloat article.
Choosing the Right Model
Use variable products when you genuinely need per-combination inventory or a distinct image per variation, and your option set is small. Use rule-based configurable products when pricing logic repeats across many products, the combination count is large, or you want one place to manage prices. Most catalogs fall into the second case and only use variations because it's the default.
Neither model is the right fit when an option is a one-off extra rather than a core spec — gift wrapping, engraving text, a rush-production fee. That's a job for product add-ons, which attach to individual products instead of describing the product itself. They're simple for a handful of products but don't scale the way reusable pricing rules do once the same fee needs to stay consistent across a whole catalog. See add-ons vs. attribute pricing for how to tell which model fits a given option.
Frequently Asked Questions
Is a configurable product a WooCommerce core feature? The variable product type is core. The rule-based configurable product type comes from a plugin such as PriceBlueprint, free on WordPress.org.
Can I track stock per option with rules? No — the rule model governs price, not per-combination inventory. If you need stock per combination, variations are the right tool.
Can one set of rules cover many products? Yes. A blueprint is reusable across unlimited products, and editing one rule updates all of them.
Conclusion
Configurable products in WooCommerce come in two shapes: the combinatorial variation model that ships with core, and the rule-based model that calculates price at runtime. For small catalogs with per-combination stock, variations are fine. For stores where pricing logic repeats and combination counts grow, rule-based configurable products keep the database flat and make price changes a single edit — the articles linked above go deeper on each part of that decision.