Every PrestaShop catalog eventually hits the same fork in the road. A merchant adds a t-shirt in five sizes and four colors, or a sofa in three fabrics, and has to decide whether those are twenty combinations of one product or twenty products in their own right. The admin screen makes combinations look like the obvious answer. Search data, merchandising and stock reality often say otherwise.
This guide walks through how PrestaShop actually stores combinations, what each modeling choice does to stock, URLs, canonicals and indexing, and how to move between the two models without burning the links you already earned. It sits inside our broader guide to product data, catalogs and the digital shelf, which covers the attribute strategy that sits upstream of this decision.
In short
- Combinations are rows in a child table of one product: they share a description, a URL and a review pool, but each can carry its own price impact, stock, reference and barcode.
- Separate products earn their own URL, title, images and structured data, which matters when shoppers search for a specific variant by name (for example “walnut dining table” rather than “dining table”).
- The deciding question is search demand per variant: if a variant has its own query volume and its own imagery, it usually deserves its own page; if it is a size, it almost never does.
- Stock accuracy is easier with combinations, because PrestaShop tracks quantity and reservations per combination inside a single product record.
- Switching models later is possible but costly: plan 301 redirects, Merchant Center item group IDs and review migration before you touch a single product.
How does PrestaShop model combinations under the hood?
PrestaShop builds variants from two layers of data. At the top sit attribute groups, such as Size, Color or Material, which you manage under Catalog and then Attributes & Features. Inside each group sit the attribute values: S, M, L, or Red, Navy, Black. A combination is simply a product linked to one value from one or more groups.
In the database, the parent product lives in the product table, and each combination lives in a child table (product_attribute in the standard schema), with a link table mapping each combination to its attribute values. That structure explains almost every behavior you will see in the storefront. The parent owns the name, descriptions, category, URL rewrite and most SEO fields; the combination owns only the deltas.
What a combination can override
Each combination can hold its own reference (SKU), EAN-13, UPC, ISBN and MPN, its own quantity, a minimum order quantity, a low-stock threshold and an availability date. It can also carry an impact on price, weight and unit price relative to the parent, and a subset of the parent’s images assigned to it.
What a combination cannot hold, at least in core PrestaShop without modules, is its own product name, long description, meta title or meta description. That single limitation drives most of the SEO argument for separate products later in this guide.
The combination generator and the Cartesian trap
The back office includes a generator that creates every possible pairing of the values you select. Pick eight sizes, twelve colors and three materials, and it will create 288 combinations in one click, whether you stock them or not. Many of those rows will never have inventory, but they still load into the product page, the faceted search index and any feed module that reads them.
Large combination counts are one of the more common causes of slow product pages and slow back-office saves on PrestaShop, especially on shared hosting. If you are already fighting performance, our note on where PrestaShop still fits in 2026 covers the hosting and version context. A sensible discipline is to generate only the pairings you actually sell, then delete the rest.
Product types in PrestaShop 8 and 9
The redesigned back-office product page, introduced as an option in the 8.x line and made the default in PrestaShop 9, asks you to choose a product type up front: standard product, product with combinations, pack of products, or virtual product. Changing the type later is possible, but switching away from “product with combinations” deletes the combinations attached to it. Treat that choice as a modeling decision, not a formality, and export your combination data before changing it.
What is the case for combinations: stock, pricing and admin effort?
Combinations exist because most variants are not meaningfully different products. A shopper looking for a merino crew-neck sweater wants one page that shows every size and every color, with the price and availability updating as they click. Splitting that into fifteen pages would make the experience worse and the catalog harder to run.
One record, one set of reviews
With combinations, every review, rating and question lands on the same product. Ten reviews spread across ten size pages look thin; a hundred reviews on one page look like social proof. The same logic applies to backlinks: any external site linking to the product links to the one URL that matters.
Pricing that follows the parent
Price impacts are relative. If the parent sells at 60 and the XXL combination carries a plus 5 impact, a later price change on the parent moves every combination with it. Catalog price rules and specific prices can also target the whole product or individual combinations, which keeps promotions manageable. With separate products you would maintain each price independently, or rely on a bulk-edit module and the discipline to use it.
Lower admin effort per SKU
Content work scales with the number of products, not the number of SKUs. One description, one set of features, one category assignment and one set of meta fields covers every combination. For a catalog with 500 base products and 6,000 sellable SKUs, that difference is the gap between a manageable content backlog and an impossible one. If you rely on modules to bulk-edit or sync stock, check how each handles combinations before you commit; our roundup of PrestaShop modules for a serious store flags which categories of module tend to struggle here.
Filters that work out of the box
The faceted search module indexes attribute values, so a shopper can filter a category by size or color and see only products with matching combinations. Because the filter knows about quantities, a merchant can also choose to hide products whose matching combination is out of stock. Separate products can be filtered too, but only through features or custom attributes, which you have to keep in sync manually.
What is the case for separate products: search demand and imagery?
The strongest argument for separate products is that search engines rank pages, not combinations. A combination has no title tag of its own, no H1 of its own and, in most themes, no indexable URL of its own. If people search for a variant by name, a combination cannot compete for that query on its own merits.
When variants carry their own search demand
Size almost never carries independent demand. Nobody searches for “medium” as a product. Color sometimes does in fashion and homeware (“sage green velvet sofa”), material frequently does in furniture and jewelry (“solid oak”, “14k gold”), and model or edition almost always does in electronics and books. When keyword research shows meaningful volume for the variant term combined with the product type, a dedicated page with its own title, description and H1 is usually the stronger play.
A practical test: take your product type and add each variant value, then check search volume and the live results. If the top results are variant-specific pages from competitors, Google is telling you it treats that variant as a distinct intent. If the top results are general product pages with a variant selector, combinations are probably fine.
Imagery, copy and merchandising
Separate products let you write copy for the variant itself. A walnut finish deserves a paragraph about grain and patina; an oak finish deserves a different one. They also let you build a full image set per variant, place the variant in different categories, and feature it independently on the homepage or in campaigns.
Feeds and marketplaces
Shopping feeds can represent combinations correctly, since Google Merchant Center groups variants through the item_group_id attribute. But many feed modules and marketplace connectors handle combinations less gracefully than standalone products, especially when combinations lack their own images or barcodes. If a combination has no GTIN of its own, feeds that require one will often reject it. Separate products avoid that class of problem at the cost of more catalog maintenance.
| Factor | Combinations | Separate products |
|---|---|---|
| Own URL and title tag | No (shares the parent’s) | Yes |
| Own description and meta fields | No in core PrestaShop | Yes |
| Reviews and backlinks | Pooled on one page | Split across pages |
| Stock per variant | Native, per combination | Native, per product |
| Price changes | Relative impacts follow the parent | Each price edited separately |
| Faceted filtering by size or color | Native through attributes | Needs features kept in sync |
| Variant-specific search queries | Weak | Strong |
| Content effort | Low | High |
| Risk of thin or duplicate pages | Low | High if copy is not differentiated |
How do URLs, canonicals and indexing work for each model?
This is where most PrestaShop variant problems actually show up, because what the admin shows and what Googlebot sees are not the same thing.
How combination URLs are built
Default PrestaShop product routes can include the combination ID, so a product URL may look like a numeric product ID, a dash, a combination ID, then the rewrite, ending in .html. The selected attribute values are often appended as a hash fragment, for example a fragment such as #/2-size-m/11-color-black. Search engines generally ignore everything after the hash, so the fragment does not create a separate indexable page.
The combination ID in the path is a different matter. If your route includes it and your theme exposes those URLs in links or sitemaps, crawlers can discover one URL per combination, each serving nearly identical content. Check the product route under Shop Parameters and then Traffic & SEO, and check what your sitemap module actually lists.
What the canonical tag should say
For a product modeled with combinations, the safe default is that every combination URL canonicalizes to the main product URL. Canonical behavior depends on the PrestaShop version, the theme and any SEO module you run, so do not assume; open three combination URLs, view the source and read the rel=”canonical” value on each. If they point to themselves, you have created a set of near-duplicates competing with each other.
The deeper SEO trade-offs between canonicalizing, indexing and blocking variant URLs apply to every platform, and we cover them in detail in product variant URLs and SEO. The PrestaShop-specific point is that core gives you no per-combination title or description, so a self-canonical combination page is almost never the right answer here.
Structured data for variants
Google supports a ProductGroup type with hasVariant and variesBy properties, which lets a single page describe a family of variants with their own SKUs, GTINs, prices and availability. Google’s guidance on product variant structured data describes both single-page and multi-page setups. Many PrestaShop themes still output a single Product object with one offer, so check your theme or SEO module’s output with the Rich Results Test before relying on variant-level rich results.
Separate products and duplicate content
Separate products carry the opposite risk. Ten pages for ten colors with identical copy and swapped images can look like thin duplication to a search engine, and they will compete with each other for the same head query. If you split variants into products, each one needs genuinely different copy, a distinct title and ideally a distinct image set. Linking them together with a “also available in” block helps both shoppers and crawlers understand the family.
How accurate is stock, and what reservation quirks should you know?
PrestaShop tracks stock in a stock-available record per product and per combination. When a product has combinations, the parent’s quantity is the sum of its combinations, and what the storefront shows as purchasable is driven by the combination the shopper has selected.
Physical, reserved and available quantity
Since the 1.7 line, PrestaShop distinguishes physical quantity, reserved quantity and available quantity. Orders in states that have not yet shipped reserve stock, and the reserved amount is released or consumed as the order moves through its states. If order states are misconfigured, for example a custom “awaiting pickup” state that is not flagged correctly, reserved quantities can drift from reality and the storefront will show the wrong availability.
That mechanism works the same way for combinations and for standalone products. The practical difference is that with combinations, all the reservations for one product family live under one record, which makes auditing simpler.
Where combinations get tricky
Three situations cause most stock confusion with combinations:
- Packs that include a combination. A pack can draw stock from its components, but how the pack is configured to decrement (the pack itself, its components, or both) decides whether a specific combination’s quantity moves.
- ERP or warehouse sync by SKU. If combinations lack unique references, an external system cannot map stock correctly. Every sellable combination needs its own reference, and ideally its own barcode.
- Out-of-stock behavior. The “allow orders when out of stock” setting is set on the product and applies to all of its combinations, which can be wrong if one size is made to order and the others are not.
When separate products are easier to stock
If a variant has a different supplier, a different lead time or a different out-of-stock policy, a separate product is often cleaner because every stock setting is independent. Made-to-order fabric options on furniture are the classic example: one fabric ships from stock, another is made in six weeks, and forcing both into one product pushes the merchant into workarounds.
| Stock scenario | Better fit | Why |
|---|---|---|
| Same supplier, same lead time across sizes | Combinations | One record, simple audits |
| Different lead times per variant | Separate products | Independent availability and out-of-stock rules |
| ERP syncs by SKU with unique barcodes | Either | Works if every variant has a unique reference |
| Variants sold in packs or bundles | Combinations, carefully | Pack decrement settings must be tested |
| Hundreds of variants per base product | Split into a few products with combinations | Keeps page weight and generator output manageable |
How do you migrate from one model to the other without losing links?
Merchants usually discover they chose the wrong model after launch: a combination turns out to have real search demand, or a catalog of separate color pages turns into a maintenance burden. Either migration is doable, but it touches URLs, feeds, reviews and stock at the same time.
From combinations to separate products
- Export the product and its combinations, including references, barcodes, quantities and image assignments.
- Create the new products with their own names, copy, meta fields and images, and give each a clean rewrite.
- Move stock to the new products and remove the matching combinations from the parent, or retire the parent entirely.
- Redirect any combination URLs that were indexed or linked externally to the new product that matches them, using permanent redirects.
- Update the shopping feed so each new product carries the right item_group_id if you still want the family grouped in Merchant Center.
Reviews are the hardest part. Most review modules attach reviews to a product ID, so splitting a product leaves the reviews on the parent. Decide in advance whether the parent remains as a “family” page with the pooled reviews, or whether reviews are copied to the most relevant child products with the module’s import tool.
From separate products to combinations
Consolidation runs the other way. Pick the strongest page, usually the one with the most backlinks, reviews and organic traffic, as the surviving parent. Recreate the other products as combinations of it, then disable the old products and set each one’s offline behavior to a permanent redirect to the parent.
PrestaShop includes a per-product setting for what happens when a product is offline: redirect permanently or temporarily to another product or to a category, or (in recent versions) return a not-found or gone status. That built-in redirect is often enough for consolidation, as long as you keep the old products disabled rather than deleted, because deleting a product removes its redirect setting along with it.
Checks after any migration
- Crawl the old URLs and confirm each returns a single 301 hop to the right destination.
- Resubmit the sitemap and watch the indexing reports in Google Search Console for the next few weeks.
- Confirm the feed has no orphaned item IDs and that variant groupings look right in Merchant Center.
- Spot-check stock on ten random SKUs against the ERP or warehouse system.
If the migration is part of a broader replatforming, the same redirect discipline applies on a larger scale; our candid guide to migrating from PrestaShop to Shopify covers how variant limits on the destination platform change the calculation.
What are the rules of thumb by product category?
No rule fits every catalog, but patterns repeat across verticals. Use these as starting points and confirm them with your own search data.
Apparel and footwear
Size should almost always be a combination. Color is a judgment call: core colors usually stay as combinations, while a hero colorway with its own campaign and its own search demand can justify a separate product. Many fashion merchants run one product per color, with sizes as combinations, which is a middle path PrestaShop handles well.
Furniture and homeware
Dimensions and small finish options work as combinations. Materials and wood species often carry their own demand and their own lead times, which pushes them toward separate products. Fabric swatches for upholstery tend to live as combinations unless a specific fabric is a bestseller worth promoting.
Electronics and accessories
Storage capacity and color are typically combinations. Different models or generations should be separate products, because shoppers search for them by name and they carry different specifications. Compatible-device variants for cases and chargers (“for model X”, “for model Y”) almost always deserve their own pages, since the device name is the search query.
Beauty, food and consumables
Pack sizes and multi-packs work as combinations, with clear price impacts. Shades and flavors often carry real demand, especially in cosmetics, and benefit from their own pages with their own swatch imagery. Scent or flavor ranges with a dedicated following (“vanilla protein powder”) deserve separate products.
Print, books and media
Formats such as hardcover, paperback and ebook carry different identifiers (each format typically has its own ISBN), but shoppers usually search for the title. A common pattern is one product per title, with formats as combinations, each carrying its own ISBN in the combination’s identifier field.
| Category | Usually a combination | Often a separate product |
|---|---|---|
| Apparel | Size, minor colors | Hero colorways, collaborations |
| Furniture | Dimensions, leg finish | Wood species, material lines |
| Electronics | Storage, color | Model, generation, device fit |
| Beauty | Pack size | Shade ranges, signature scents |
| Books and media | Format | Different titles or editions |
A decision checklist before you build the product
When a new product line arrives, a short checklist prevents most modeling mistakes. Answer each question for every variant dimension (size, color, material, model) separately, not for the product as a whole.
- Is there search demand for the variant term combined with the product type? If yes, lean toward a separate product.
- Does the variant need its own copy and images to sell? If yes, lean toward a separate product.
- Does the variant have a different supplier, lead time or out-of-stock policy? If yes, lean toward a separate product.
- Would splitting create pages with nearly identical copy? If yes, keep it as a combination.
- Would the variant count produce hundreds of combinations per product? If yes, split into a few parent products with combinations under each.
- Does every variant have a unique reference and barcode? If not, fix that first, whichever model you choose.
Hybrid models are normal. One product per color with size combinations, or one product per model with storage and color combinations, captures most of the search benefit without multiplying content work. The data layer that makes those choices sustainable, consistent attribute names, clean identifiers and differentiated copy, is the subject of our product data and digital shelf guide, and if you are still weighing platforms entirely, start with how to choose the right e-commerce platform.
FAQ on PrestaShop variants
What is a combination in PrestaShop?
A combination is a variant of a product built from one value in each of one or more attribute groups, such as size M in color black. It shares the parent product’s name, description and URL, but can carry its own reference, barcode, quantity, price impact, weight impact and image subset.
Can a PrestaShop combination have its own URL for SEO?
Combinations can appear in URLs through the combination ID in the product route or through a hash fragment, but in core PrestaShop they do not get their own title tag, meta description or H1. In most setups they should canonicalize to the main product URL. If a variant needs to rank on its own, a separate product is usually the better tool.
How many combinations can one PrestaShop product have?
There is no small fixed limit, but performance degrades as counts grow, both on the product page and in back-office saves. Many merchants find a few dozen to a couple of hundred combinations per product manageable on decent hosting; beyond that, splitting into several parent products is common.
Do combinations affect Google Shopping feeds?
Yes. Each combination is usually exported as its own item, grouped under the parent through the item_group_id attribute. Combinations without their own GTIN or image may be rejected or shown poorly, so give each sellable combination a unique barcode and assign at least one image to it.
Should color be a combination or a separate product?
It depends on demand. If shoppers search for the color by name together with the product type, and the color has its own imagery, a separate product often performs better. If color is a minor option that shoppers choose after landing on the product, keep it as a combination.
How do I redirect old products after merging them into combinations?
Disable the old products rather than deleting them, then use the product’s offline redirect setting to send traffic permanently to the surviving parent product. Check each old URL afterward to confirm a single 301 hop to the right page.
Does stock reservation work differently for combinations?
No. PrestaShop tracks physical, reserved and available quantity the same way for combinations and standalone products. With combinations, the parent quantity is the sum of its combinations, and reservations follow the specific combination ordered.
What happens if I change a product type away from combinations?
In the newer back-office product page used in PrestaShop 8 and 9, switching a product away from the “product with combinations” type removes the combinations attached to it. Export combination data first, and test the change on a staging copy of the store.