Product Combinations and Variants: When Your Store Needs Them

Updated June 2026 — combinations, attribute groups and the CSV import entity described here apply to PrestaShop 1.7, 8 and 9.

A t-shirt comes in three sizes and four colours. A phone case fits five phone models. A wall paint is available in 200 shades. The question every PrestaShop merchant eventually hits is not how to add these variations — it's which mechanism to use. PrestaShop gives you four different tools that all look like they solve "the same product, but slightly different," and picking the wrong one means duplicated listings, broken stock counts, or a product page customers can't navigate. This guide is about that decision: when your store genuinely needs combinations, when it needs something else entirely, and exactly how each one behaves in the PrestaShop back office.

Four tools that all look like "variants"

Before any back-office clicking, get the model straight. PrestaShop has four distinct features that merchants routinely confuse, and each leaves a different footprint on your catalogue, your stock, and your URLs:

So what? Choosing combinations when you should have used features bloats your back office with stock rows you'll never count. Choosing combinations when a customer is really uploading a logo means orders arrive with nothing attached. Getting this first call right is half the job.

Combinations vs separate products — the real decision

For the two tools that genuinely compete — combinations vs separate products — the deciding factor is whether the variants are the same thing in a different flavour or different things that happen to be related. The honest test is what the variant changes:

Use combinations when

• The item is fundamentally the same in different sizes, colours, or materials.
• The price difference between variants is small or zero.
• Customers expect to choose the variant on one product page (picking a size).
• You want one URL, one set of reviews, and one listing in search results.
• The description applies equally to every variant.

Use separate products when

• Variants differ significantly in price, features, or description.
• Each variant has its own images that tell a different story.
• A colour or model has enough independent search demand to deserve its own page.
• Variants are sold or marketed independently.

A worked example clears most of the fog. A t-shirt in S/M/L/XL at one price → combinations. A laptop in different CPU/RAM/storage configurations at very different prices and with different spec sheets → separate products. A phone case in four colours at the same price → combinations. "The same" case for an iPhone versus a Samsung → separate products, because the images, the description, and the search terms ("iphone 15 case" vs "galaxy s24 case") all diverge. When the variant gives a buyer a different reason to land on the page from Google, it usually wants to be its own page. The flip side — using two near-identical product pages where one would do — risks Google treating them as duplicates; if you're choosing between one rich page and several thin ones, that's a content-architecture call covered in product page design best practices.

How combinations actually work in PrestaShop

PrestaShop builds combinations from two ingredients, defined under Catalog → Attributes & Features before you ever touch a product:

• Attribute groups — the dimension of variation: Size, Colour, Capacity, Material. Each group has an Attribute type setting (drop-down list, radio buttons, or colour/texture swatch) that decides how it renders on the product page.
• Attributes — the specific options inside a group: Small / Medium / Large within Size; Red / Blue / Green within Colour. A Colour attribute can carry an actual colour value or a texture image so the front office shows a swatch instead of plain text.

On the product itself, you assemble these into combinations on the Combinations tab. In PrestaShop 1.7+ the Generate combinations button produces the Cartesian product of whatever attributes you tick — pick Small/Medium/Large and Red/Blue and you get six rows in one click. Each combination row is a real database record (in ps_product_attribute and its _combination link table) and each can carry its own:

• Stock quantity — tracked independently for each combination through PrestaShop stock management.
• Price impact — a fixed +/− amount applied to the base price (percentage-based variation belongs to Specific prices, not the combination row).
• Reference, EAN-13/UPC and supplier reference — so each variant scans and reconciles correctly.
• Specific weight — added to the base weight for carrier price rules.
• Its own image(s), chosen from the product gallery.
• A minimum order quantity, and an availability date for pre-orders.

One row per product is flagged the default combination — that's what the page shows on first load and what feeds your listing's "from" price. Get that default right: it sets the first impression of price and availability.

[SCREENSHOT: the Combinations tab of a product in the PrestaShop back office after clicking "Generate combinations" — show the generated grid with per-row stock, impact-on-price and the default-combination radio, so the reader recognises the screen.]

Stock that's actually accurate

The single biggest reason to use combinations rather than faking variants with separate listings is honest, granular stock. If you sell t-shirts you need to know you hold 45 Medium Blue and 3 Large Red — not "85 t-shirts." PrestaShop enforces this at the combination level: a customer can't buy Large Red once that specific row hits zero (assuming you haven't enabled "allow ordering out-of-stock"). The practical payoff is twofold — you stop overselling the variant that always runs dry, and your reorder decisions are driven by the row that's actually empty rather than a meaningless total. Whatever feeds your stock (manual edits, supplier CSV, an ERP sync) has to write at the combination level, or the accuracy collapses back to product-level guessing.

Image swapping on selection

The behaviour customers love — click "Red," see the red product — is built in. You upload every image to the product gallery, then associate specific images with specific combinations on the Combinations tab. PrestaShop's product.js swaps the displayed image (and the price, reference and stock label) when the shopper changes a selection, with no page reload. It's worth its weight for colour variants and largely irrelevant for size-only products that look identical. If themes handle this swap inconsistently — and some do — test it on your live theme before launch, because a broken swap reads as a broken product page.

The combination-explosion trap

Combinations multiply. Five sizes × eight colours × three materials = 120 rows on a single product, each wanting stock, a price and maybe an image. That's the most common way a clean catalogue turns into an unmanageable one. A few disciplines keep it sane:

• Only create combinations you actually sell. If XXL never ships in Lavender, don't generate that row. Generate the full grid, then delete the rows you'll never stock.
• Use CSV import for bulk work. Under Advanced Parameters → Import, the Combinations entity lets you create and update hundreds of rows — stock, price impact, references — without hand-editing. This is also how you sanely push a price or stock change across a large catalogue; the broader mechanics of doing that at scale are covered in mass price updates.
• Question whether a dimension belongs as a feature instead. Does the customer truly choose material on the page, or are you just describing it? If they never pick it, it's a Feature, not an attribute — and Features feed faceted search and filter pages without adding a single stock row.

A workable Combinations CSV is plainer than it looks. The Product reference ties each row to its parent product, and the attribute column packs the group and value together so PrestaShop knows what to build:

Product reference;Attribute (Name:Type:Position)?;Value (Value:Position)?;Quantity;Impact on price
TSHIRT-001;Size:select:0;M:1;45;0
TSHIRT-001;Size:select:0,Colour:color:1;M:1,Blue:2;45;0
TSHIRT-001;Size:select:0,Colour:color:1;L:2,Red:1;3;2.00

Match these headers to PrestaShop's columns in the import mapping step and tick Combinations as the entity — the same import can update quantity and price impact on existing rows on a later run, which is what makes it the sane path for a deep catalogue.

The principle behind all three: every attribute group you add multiplies the others. Keep the structure as small as the buying decision genuinely requires. If a customer needs a flowchart to understand your options, you've overcomplicated the page — and a confusing variant selector is one of the fastest ways to lose a ready buyer, which is exactly the kind of friction broken down in product page anatomy.

Pricing across combinations

PrestaShop gives you three ways to vary price by combination, and they layer cleanly:

• Per-combination impact — the everyday case. Large costs €5 more: set a fixed +5.00 impact on that combination. The product page recalculates and displays the new price the instant the shopper selects it.
• Specific prices — when you need a percentage adjustment or genuinely complex logic (a particular variant on promo for one customer group, or a tiered quantity discount), the Pricing → Specific prices rules can target an individual combination with a fixed or percentage discount.
• Tax-inclusive display — confirm whether the swapped price honours your tax rule and currency. This is theme-dependent JavaScript, so test the live update on your actual theme; a price that doesn't move when the variant does undermines trust at the worst moment.

How that displayed number is framed — anchoring, charm pricing, "from €X" on the listing — is a separate lever worth pulling deliberately; see the psychology of pricing.

When combinations aren't the answer

Some variation needs sit outside the combinations model entirely, and forcing them in is where stores get stuck:

• Buyer-supplied variation (engraving text, a monogram, an uploaded photo) is Customisation, not a combination — configured per product under the Customisation tab with text fields and/or file fields. You're not pre-stocking 10,000 name variants; the customer creates the variant at checkout.
• Dependent attributes — where not every colour exists in every size — aren't natively conditional in core PrestaShop. You either pre-delete the impossible combination rows (so they simply never appear) or add a module that hides invalid options dynamically as the shopper selects.
• True configurators — build-your-own products where each choice changes price, image and description live (a PC builder, a made-to-measure blind) — exceed combinations and call for a dedicated configurator module. Combinations describe a fixed grid of pre-defined variants; a configurator composes a product on the fly.

For the overwhelming majority of stores, standard PrestaShop combinations cover the variant need without any add-on. The skill is recognising the 10% of cases that don't fit — and not contorting the other 90% to match them.

A note on SEO and merchandising

By design, all combinations of a product share one URL and one set of meta tags, and that is usually correct — you do not want "Blue T-shirt Size M" and "Blue T-shirt Size L" competing as separate Google results. PrestaShop's classic theme emits Product structured data for that single page, with one offer reflecting the displayed (default) combination's price and availability rather than a separate offer per variant. The one case worth a second look is when individual colours or models carry real, independent search demand ("red leather bag" vs "black leather bag") — that's the moment the separate-products route earns its keep, and how you actually write those pages to rank without duplicating each other is covered in writing product descriptions that rank and convert. On the merchandising side, a clean variant selector pairs naturally with the rest of the product page — clear specs, trust signals, and the cross-sell prompts laid out in cross-selling and upselling.

Managing attributes across a large catalogue

The pain of combinations rarely shows up on one product — it shows up when you add a new size or colour and have to push it across hundreds of products one at a time. That's the gap our Global Product Attributes module closes: it lets you manage attribute groups, values and their assignments across the entire catalogue from one screen. So what does that mean day to day? Adding "size 47" to every shoe, or retiring a discontinued colour everywhere it appears, becomes one action instead of an afternoon of clicking through products — and because it works from the back office, there's no theme editing or developer invoice involved. For stores with a deep, variant-heavy catalogue, that's the difference between attributes being a chore and being a non-event.

Frequently asked questions

What's the difference between an attribute and a feature in PrestaShop?

An attribute is something the customer chooses on the page (Size: Medium) and that creates a stock-tracked combination. A feature is something that describes the product (Material: cotton) but is never selected — it shows in the Product Details tab and feeds faceted search, adding no stock rows. If a shopper picks it before adding to cart, it's an attribute; if it's just information, it's a feature.

Do combinations get their own URL and rank separately in Google?

No. All combinations of a product share one URL and one set of meta tags by design, and the structured data emits a single offer based on the default combination. That's usually what you want — you don't want "Blue T-shirt M" and "Blue T-shirt L" competing as separate results. Only split a variant into its own product when it has genuine, independent search demand ("red leather bag" vs "black leather bag").

Can I bulk-create combinations without clicking through every product?

Yes. Advanced Parameters → Import has a Combinations entity that creates and updates rows — stock, price impact, references — from a CSV. The attribute column packs group and value together (e.g. Size:select:0,Colour:color:1), the Product reference ties each row to its parent, and a later run with the same references updates the existing rows rather than duplicating them.

How do I stop the combination count from exploding?

Three habits: only generate combinations you actually stock (delete the impossible rows after generating the full grid), demote any dimension the customer never chooses to a Feature instead of an attribute, and use CSV import for bulk edits rather than hand-clicking. Five sizes × eight colours × three materials is already 120 rows on one product — every group you add multiplies the rest, so keep the structure as small as the buying decision needs.

Why does my price (or image) not update when I pick a variant?

The on-selection swap is theme-dependent JavaScript driven by product.js. If the price, image or stock label doesn't move when the shopper changes a combination, the theme isn't wiring the update correctly — test it on your live theme before launch. A combination with no associated image falls back to the cover image, and a price that doesn't move usually means a missing or overridden product.js, not a data problem.

Get the first call right — combination, separate product, feature, or customisation — and the rest of PrestaShop's variant tooling is genuinely capable. Keep the grid only as large as the buying decision needs, track stock at the combination level so your reorder data is honest, and reserve separate pages for the variants that earn their own search demand. Do that, and "this product comes in a few versions" stays a quiet convenience rather than a catalogue you're forever fighting.