Products vs. variants vs. collections - getting the model right from day one

The question sounds trivial: is the blue version of this shirt a variant, or its own product? But this single decision determines your URLs, your search presence, your feed structure, and how much duplicate content you'll be fighting for years.

The rule of thumb

If customers think of it as the same item in different options, it's variants. If they'd search for it separately, it's separate products.

A shirt in S/M/L: variants. Nobody searches "shirt size M" expecting a different page.

The same shirt in navy and in a bold floral print: this is where it gets interesting. If the prints have different names, different photography, and customers search for them by name - separate products may serve you better. Each gets its own URL, its own page to rank, its own feed entry.

What each choice costs

Too many variants on one product means one URL trying to represent many things. Your navy shirt and floral shirt share a description, share search rankings, and share a single Merchant Center entry unless you configure variant-level feeds. Customers landing on the page may see the "wrong" color first.

Too many separate products means duplicate content - five near-identical descriptions competing with each other - plus inventory and data maintenance multiplied by five. Every copy change happens five times.

The 100-variant ceiling

Shopify caps products at 100 variants (2,048 on some newer setups, but don't design for the exception). Fashion brands hit this fast: 8 sizes × 12 colors is 96 variants and no room to grow. If your matrix is that large, splitting by color into separate products is usually the cleaner model - one product per colorway, sizes as variants. It matches how customers shop, and it gives each colorway its own URL and images.

Changing your mind later is expensive

Merging products deletes URLs (and their rankings). Splitting products means new URLs starting from zero. Both require redirects, feed updates, and re-linking from collections and blog content. It's all doable - we cover it in Data Operations at Scale - but it's a project, not a toggle. Deciding deliberately now is much cheaper.