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 does not scale, and it is not the only model available.
This guide explains what configurable products are, the two architectures available for building them, when each one fits, and how to set one up. It is 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 differ entirely in how the data is stored.
The Two Models: Variations vs. Pricing Rules
Understanding the difference is the single most useful thing when planning a configurable catalog, because it determines how your store performs and how much work pricing changes take.
| 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 |
The combinatorial growth of the variation model is the root of most scaling problems; we cover exactly why in why too many variations slow your store, and the structural comparison in depth 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 do not 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 the selected values, evaluated as the customer makes selections. "Material Oak adds $25" is a rule; an Oak item is base + 25. The full runtime mechanics — base price, rule evaluation, live updates — are walked through in dynamic pricing by attributes.
Setting One Up
The 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 then 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 is only useful if the customer's choices survive the whole purchase. Selected attribute values and the calculated price carry through the cart and checkout and are recorded 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 does not conflict with full-page caching. This is the inverse of the variable-product model, whose postmeta table grows with every combination — the mechanism behind the slowdowns described 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. Many catalogs are firmly in the second case and only use variations because it is the default.
Frequently Asked Questions
Is a configurable product a WooCommerce core feature? The variable product type is core. The rule-based configurable product type is added by a plugin such as PriceBlueprint, which is 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, make price changes a single edit, and scale without the maintenance tax — and the articles linked above go deeper on each part of that decision.