What is the right way to add product variants?
The right way to add product variants is to keep one parent product listing and add options only for attributes that change what the buyer receives — size, color, and pack count are the three that usually qualify. Each combination of those options becomes a variant, and each variant gets its own SKU, its own price, and its own stock count. If a shopper would be annoyed to receive the wrong one, it is a variant. If they would never notice, it is not.
Everything else should be a separate product, not a variant. A different fabric, a different fragrance family, a different model number, or a product photographed differently enough that it needs its own gallery and description — those deserve their own listings. The practical test is search and discovery: if a customer would type it into a search box and expect it as a result, it needs its own product page. If they would only pick it after landing on a page, it is a variant option.
When should size be a variant instead of a separate product?
Size should be a variant when the product, the description, and the photos are otherwise identical. A kurta in S, M, L, XL is one product with four variants. Every size shares the same fabric description, the same care instructions, and mostly the same images.
Size should be a separate product when the size change also changes the specification. A 500ml bottle and a 5-litre can of the same floor cleaner are usually better as two products, because the packaging photo, the shipping weight, and often the customer are different. Bulk buyers and retail buyers rarely browse the same way.
Size variants need a size chart on the product page. Indian apparel sizing is inconsistent across brands, and a missing chart is a direct cause of exchange requests. Put measurements in both inches and centimetres, and state whether they are garment measurements or body measurements.
When should color be a variant?
Color should be a variant when the product is functionally the same in every shade. Each color variant needs its own image, and the image should be the first thing that changes when the shopper selects it. A color swatch with no matching photo is worse than no swatch at all, because the buyer forms an expectation from the default image and then disputes it on delivery.
Color should be a separate product when the colorway carries its own name, story, or price positioning — limited editions, prints with distinct designs, or handloom pieces where each piece is genuinely unique. In handloom and handicraft categories, treating every piece as a variant of a generic parent often hides the thing that actually sells it.
Name colors the way your customers say them, not the way your supplier invoices them. "Mustard" sells. "Pantone 7549C" does not.
When should pack size be a variant?
Pack size should be a variant when the unit inside the pack is identical and only the count changes — a pack of 2, 5, or 10 of the same soap bar. The pack count changes price and shipping weight, so each pack variant needs its own SKU and its own weight recorded.
Pack size should be a separate product when the pack is a curated combination rather than a multiple. A gift hamper containing three different products is a product, not a variant of any one of them.
The common mistake with pack variants is inventory. If you hold 100 individual bars and sell them as singles, 2-packs, and 5-packs, the three variants are drawing from one physical pool. Unless your platform supports component-level stock, you will oversell. The safe workaround is to allocate a fixed quantity to each pack variant and reconcile manually, rather than entering 100 against all three.
How should you structure SKUs for variants?
Build a SKU pattern before you create the first variant, because renaming SKUs later breaks your own records. A readable pattern is parent code, then option codes, in a fixed order: KRT-BLU-M for a blue medium kurta, SOAP-LAV-P5 for a five-pack of lavender soap.
Keep the order of options consistent across the whole catalogue. If color comes before size in one product and after it in another, your packing slips become unreadable at volume.
Do not encode price or season into the SKU. Both change. The SKU should identify the physical thing on the shelf and nothing else.
What usually goes wrong with variants in Indian stores?
The first failure is the empty combination. A product with 5 sizes and 6 colors generates 30 variants, and you probably stock fewer than 30. Combinations you do not stock should be hidden or marked out of stock, not left purchasable. Selling a combination you cannot ship generates a refund and a return-to-origin (RTO) cost you never planned for.
The second failure is weight. Shipping in India is priced by weight slab and destination pincode, so a 5-pack and a single unit cannot share a shipping weight. If you enter weight only on the parent product, courier rate calculation will be wrong on every pack variant. Enter dead weight and dimensions per variant.
The third failure is GST. Goods and Services Tax rates in India are set by HSN code, and variants of one product usually share the same code — but not always. Apparel is the classic exception, where the rate can differ by price point. If two size variants fall on either side of a rate threshold, your GST invoice must reflect the correct rate for the variant actually sold, not a single rate applied to the parent.
The fourth failure is photography. A shopper who selects "Green" and sees a blue photo does not trust the rest of the page. Map at least one image to every color variant before you publish.
How many variant options is too many?
Most hosted store platforms cap the number of option types per product, commonly at three. That cap is a feature, not a limit to fight. Three options is already the point where a shopper has to make three decisions before adding to cart.
If you genuinely need four or more dimensions — size, color, sleeve, and fabric — split the catalogue. Make fabric the product and the other three the options. You will get cleaner pages and cleaner analytics, because you will finally be able to see which fabric sells.
Watch the combination count. Twelve variants is manageable. A hundred and twenty is a stock-keeping problem disguised as a product page.
How does this work on a hosted Indian store?
On HOD Media, you create the product once, add options such as size, color, or pack, and each combination becomes a variant you can price and stock separately. Variants flow through to the parts of the order that depend on them: GST invoicing picks up the variant sold, courier integrations for Indian pincodes use the variant's shipping details, and WhatsApp and email order automation reflects the exact variant on the order.
Stores run on custom domains and accept cash on delivery (COD) as well as UPI and card payments, so the variant a customer picks is the variant that appears on the invoice regardless of how they pay. Resellers building stores for clients can use the white-label option and apply the same variant structure across every store they set up.
What should you do before you publish?
Write down the option list on paper first. Decide which attributes are variants and which are separate products before you touch the product form, because restructuring a live catalogue means broken links and lost search history.
Then check three things on the live page: every color variant shows its own image, every unstocked combination is unpurchasable, and every variant has a weight. Those three checks prevent most of the refund and RTO cost that bad variant setup creates.
