In short
Product variants are versions of an item that differ in one or more properties, such as size, colour, material or length, but otherwise belong to the same base product. A T-shirt in blue and size M is one variant; the same T-shirt in red and size L is another.
Each variant is an independently saleable item with its own item number, its own stock level and often its own price, while the name, description and images of the base product are shared.
The variant model decides how well a range can be represented, maintained and found in the shop. With a range of 200 items without versions, this is not an issue. For a technical wholesaler, a fashion retailer or a manufacturer of configurable products, the data model decides maintenance effort, performance and SEO. This entry explains how product variants are structured, where their limits lie and which mistakes occur most frequently in practice.
How product variants are structured
A variant model has three levels that recur in almost all shop systems, even if they have different names:
- Base product (parent item): the higher-level item that carries the shared data: name, description, category, manufacturer, images.
- Options or properties: the characteristics by which the variants differ, for example colour, size or length. Each option has several possible values.
- Variant (child item): the concrete combination of option values, such as "blue, M". It is the unit that ends up in the basket and is ordered.
The number of variants results from combinatorics. Two options with four values each produce 16 variants; three options with 16, 8 and 16 values produce 2,048. This is exactly where the trap lies: every additional option multiplies the number of variants, and just a few characteristics produce thousands of records.
Variants, properties and separate items
Not every difference belongs in a variant. A common mistake is to turn characteristics into variants that do not ask the customer to make a choice. The distinction can be made with a simple question: does the customer consciously select this version in the purchasing process, and can it be ordered individually? If so, it is a variant. If the characteristic merely describes, such as the country of origin or the weight, it is a product property used for filtering and comparison that does not need an item number of its own. And if two versions differ so much that they need their own descriptions, images and search terms, they are better off as two separate products.
Inheritance of data
So that not every variant has to be maintained completely, shop systems work with inheritance. Shopware represents variants as separate product records that can inherit fields from the main product. Description and images are maintained once on the main product, while the item number, stock and, where applicable, price differ per variant. If an inherited field changes on the main product, the change applies to all variants that do not override it. This saves maintenance effort but requires discipline: anyone who overrides values on individual variants loses inheritance for that field and has to make future changes there separately.
Shopify, on the other hand, works with products that carry up to three options and a limited number of variants per product. The limit is currently 2,048 variants, and the number of options remains at three. The comparison Shopware vs Shopify shows how this affects specific ranges. For ranges with four or more characteristics, such as technical products with length, diameter, material and coating, workarounds via apps or custom development are needed on Shopify.
Why the variant model is business-critical
For retailers, the variant model is more than a question of presentation. It affects several areas at the same time:
- Warehousing: stock is kept per variant. A wrongly set-up model leads to items appearing as available even though the desired size is sold out.
- Pricing logic: prices can differ per variant, for example for special sizes. Together with tiered prices, the question arises as to whether quantities are added up across variants.
- Interfaces: ERP, merchandise management and marketplaces work with item numbers. The variant model in the shop must match the item structure in the ERP, otherwise assignment errors occur with every synchronisation.
- Findability: search, filters and search engines must understand which variants belong together.
- Returns and customer service: if size or colour information is not unambiguous, returns increase.
Unambiguous identification with GTINs
Every variant needs a unique identifier. In retail, this is often the GTIN (Global Trade Item Number), which is issued by GS1 and identifies the item uniquely worldwide. It is important that every saleable version receives its own GTIN: the item in blue has a different GTIN from the one in red. Marketplaces and price comparison engines check this assignment strictly, and incorrect assignments lead to product data being rejected.
Variants and search engine optimisation
From an SEO perspective, variants represent a classic conflict of objectives. On the one hand, search engines should understand that the variants belong to one product. On the other hand, a thin, barely distinguishable page should not be created for every variant. Basically, there are three approaches:
- One page for all variants: the base product has one URL, and variants are selected via a selection field on the page. This bundles the signals and avoids duplicate content but gives away long-tail search queries such as "safety shoe S3 size 44".
- One URL per variant with a canonical to the main product: each variant can be linked directly, but the main page counts for indexing. This is a common compromise.
- A separate indexable URL per variant: only makes sense if the variants differ significantly in content and have their own search demand.
Which approach fits depends on the range and search behaviour. Regardless of this, Google recommends structured data to mark up variants as belonging together. The ProductGroup schema groups the variants with the properties variesBy, hasVariant and productGroupID, as described in Google's documentation on product variants. This lets the search engine understand which products are versions of the same base item. How structured data works in principle is explained in the entry on schema markup.
Example: variant explosion with technical products
A retailer of fasteners sells screws. A single type of screw can be distinguished by length, diameter, material and head shape. Suppose there are 12 lengths, 6 diameters, 4 materials and 3 head shapes. Mathematically, this gives 12 times 6 times 4 times 3, i.e. 864 combinations for a single type of screw. Not all of them actually exist, because a very short bolt with a large diameter is not manufactured. Nevertheless, several hundred valid items are created, each with its own item number, its own stock and its own price.
A shop that is supposed to list all these combinations as variants of a single product runs into two limits. First, some systems only allow a limited number of options per product; in this example there are four, and Shopify supports three. Second, the product page becomes confusing if the customer has to operate four selection fields one after the other. In practice, retailers solve this with a combination of variant model and filter logic: the range is cut into sensible base products, common characteristics such as material and head shape become separate products, and length and diameter remain options. In addition, a quick order function helps, in which the buyer enters item numbers or tables directly instead of clicking through selection fields.
Where the range of characteristics becomes too large, a product configurator is a good option: the customer puts the product together step by step, and the system generates the appropriate item number or a quote from it, without every combination having to exist as a record in advance.
Typical mistakes and misconceptions
"Every version is automatically a variant." Not every characteristic justifies a variant. Anyone who creates descriptive properties as options inflates the data model and makes user guidance worse.
"Variants replace clean product data management." The variant model in the shop is only as good as the data source. If attributes are kept inconsistently in the ERP, for example "Red", "red" and "RAL 3020", three colours are created in the shop instead of one. A PIM creates a central place for attributes and their values here.
"More variants mean more revenue." Too many options overwhelm customers. What makes sense is a selection that corresponds to actual demand, not the representation of every technically possible item.
"Variants are purely a front-end topic." They have an effect right into the warehouse, pricing, interfaces and reporting. Changing the variant model after go-live is therefore laborious and affects all connected systems.
Keeping an eye on performance
Every variant is a record that search, indexing, price calculation and interfaces have to process. A range with tens of thousands of variants noticeably burdens imports, index runs and search queries. When selecting a system, it is therefore worth testing with realistic volumes of data rather than with a handful of demo items. Anyone who only discovers after the launch that a price import takes hours has an architecture problem, not a configuration problem.
Outlook
The trend is towards more flexible data models. Instead of rigid option limits, modern platforms rely on open attribute systems in which variants arise via freely definable properties. At the same time, complexity is shifting towards configuration: where combinatorics gets out of hand, configurators replace the set of variants created in advance. And with AI-supported search and product discovery, the importance of clean, structured product data is growing, because systems that generate answers from product data need unambiguous attributes for each variant. For retailers, this means: the variant model is not a one-off decision at the shop launch but part of the data strategy.
Frequently asked questions about product variants
What is the difference between a product and a variant?
The product is the base product with the shared data such as description and images. The variant is a concrete, individually orderable version with its own item number, its own stock and, where applicable, its own price.
How many variants can a product have?
That depends on the shop system. Shopify allows three options and currently up to 2,048 variants per product. Other systems have no hard limit, but maintenance effort and system load grow with every variant. Check the limits in the current documentation for your system.
Does every variant need its own GTIN?
Yes, if the version is sold as a separate item in retail. Marketplaces and price comparison engines expect a unique GTIN for each saleable variant.
How do I mark up variants for search engines?
With structured data according to the ProductGroup schema, which connects variants via the properties variesBy, hasVariant and productGroupID. In addition, you decide whether variants get their own URLs and whether these refer to the main product via a canonical.
When is a configurator better than variants?
When the combinatorics becomes so large that not all combinations should exist as records any more, or when customers put products together according to their own specifications. The configurator only generates the combination when needed.