How to name and organize size and color variants without confusing your catalog

To name and organize size and color variants without confusing your catalog, the short rule is this: define one single parent product, one axis for size and another for color, write every value ALWAYS the same way (same capitalization, same order, no synonyms), and generate one SKU per variant that follows a fixed pattern. Get those four things right and the same “black shirt, small” is a single thing in Shopify, in Amazon and in MercadoLibre, and your stock stops lying to you.

The pain isn’t having variants, it’s that every channel writes them differently. In Shopify you set Size: S / Color: Black. In MercadoLibre you uploaded it as Small with color Solid Black. On Amazon it landed as S with Black. And in your purchasing spreadsheet you call it BLK-S. Four names for the same garment. When you want to know how many small black shirts you have in total, you have to remember that those four rows are the same product, add them up by hand, and pray you didn’t count one twice. With 20 products you cope; with 20 products across 4 sizes and 5 colors that’s already 400 variants, and that’s where the mess turns into overselling, cancellations, and hours in front of a spreadsheet that never reconciles at the same second.

This article is a catalog-hygiene guide: how to structure parent and children, how to name values so they never duplicate, how to design the variant SKU, and how to keep the same product from splitting into three when it crosses channels. It’s not library theory; it’s the boring work that saves you from chaos when the catalog grows.

parent product first, variants second

The most common mistake is treating each combination as a standalone product. “Black shirt small”, “black shirt medium”, “red shirt small”… six separate listings that don’t know they’re siblings. That way you scatter reviews, fragment sales history, and lose any chance of comparing which size actually moves.

The correct structure is a single one: a parent product (“Basic cotton shirt”) that groups all its variants (the children). The parent carries what’s shared —the description, the brand, the category, the general photos— and each child carries only what changes: size, color, price if applicable, its own SKU and its own stock. This hierarchy is the same idea in Shopify (product → variants), in Amazon (parent ASIN → child ASINs per variation) and in MercadoLibre (a listing with variations). When you respect the parent-child model across all three, one channel talks to the other without translation.

The litmus test is simple: if you have to duplicate the description for two “products” that only differ in color, you’re doing it wrong. That color should be a variant of the same parent, not a brand-new parent.

one axis per attribute: size is size, color is color

Size and color are distinct attributes and each must be an independent axis. It sounds obvious, but it breaks the moment someone types “Small Black” as a single value in a single field. The instant you merge two attributes into one label, you lose the ability to filter “everything black” or “everything small” separately, and the channel stops building the size-and-color selector on the listing correctly.

The rule: size lives on the size axis, color lives on the color axis, and the variant is the crossing of the two. A shirt with three sizes (S, M, L) and two colors (Black, White) gives six clean variants, each defined by one size value and one color value. Never put the color inside the size name or the other way around.

Glossary: the unified catalog is the view where a single product and its variants exist only once, with their attributes kept separate, even though they’re published across several channels at once.

And beware of inventing extra attributes. If “size 38” and “38 EU” are the same thing, they’re not two values: it’s one value written badly twice. Fewer axes and cleaner values always beat a catalog full of nuances nobody maintains.

the name of each value: write it the same way every time

This is where most people lose. Duplication isn’t born from bad faith, it’s born from typing the same value two different ways. “Black”, “black”, “BLACK”, “Solid Black”, “Negro” and “color black” are, in your head, the same thing; to a system they’re six distinct colors. Every extra spelling spawns a ghost variant that fractures your stock.

Fix a canonical value for each size and each color, write it in a table, and don’t stray from it. Decide once and for all: is small S, SM, Small? Pick one and use it everywhere. Is the color Black or Negro? Just one. Define capitalization (Title Case vs lowercase), accents, and the order in which they appear (S → M → L → XL, never alphabetical, which would put L before M). That order matters: if sizes come out scrambled on the listing, the buyer gets confused and so do you when you review them.

A few practical rules that prevent 90% of duplicates:

• No synonyms. One value, one spelling. No “Gray” and “Oxford Gray” for the same gray.
• No stray spaces or sneaky characters. “Black “ with a trailing space is different from “Black”. Trim them.
• No size and color mixed in the same field, as we already said.
• Document the table and share it with whoever uploads products, even if that’s just you six months from now.

the variant SKU: a pattern, not an improvisation

Every variant needs its own SKU, and that SKU must follow a legible, stable pattern. The SKU isn’t for the buyer, it’s for you: it’s the thread that ties the same garment across Shopify, the marketplace and your 3PL. If you make it up each time, you end up with blk-s, SHR-B-S and shirt_black_1 all pointing at the same thing.

A pattern that works: [PRODUCT]-[COLOR]-[SIZE], with fixed abbreviations. BASSHR-BLK-S is “basic shirt, black, small”. Keep the same length and the same segment order across the whole catalog. With a pattern like that, you read the SKU and know what it is without opening the listing, and when SPORTIFY reorders from a supplier, the code speaks for itself.

Don’t confuse the SKU with the barcode. The SKU is your internal code; the EAN/GTIN is the product’s universal code, the one Amazon and MercadoLibre use to recognize that your shirt is that shirt and not another. Each variant usually needs its own EAN/GTIN.

Glossary: the EAN/GTIN is the universal barcode that identifies one specific variant —this size, this color— to any channel, and it must not be repeated across different variants.

the dangerous moment: when you cross channels

Everything above holds while you sell in one place. The mess explodes when you integrate Shopify with MercadoLibre or Amazon, because each platform has its own list of sizes and colors, and they don’t always match yours. Your S has to map to Amazon’s S and to Meli’s Small; your Black to Negro. If that mapping doesn’t exist, the channel creates new variants and your stock multiplies into ghosts.

That’s why a correct integration isn’t “copy and paste the catalog”, it’s mapping variant against variant: my BASSHR-BLK-S is this listing on Meli and this child ASIN on Amazon, and the three share a single stock pool. When one sells on any channel, availability drops on all of them at the same time. That’s exactly the work a well-built integration solves; we cover it in detail in what syncs when you integrate Shopify with MercadoLibre, where stock, prices and orders stop living each in its own tab.

Glossary: real availability is the sum of physical units of a variant, counted only once, no matter how many channels that size and color is published on.

Doing this mapping by hand, in Excel, is where the hours vanish and the errors creep in. The moment a new variant shows up unmapped, or a color is spelled differently on one channel, the numbers stop reconciling. Having the crossing done once, in real time, is what turns “I think I have ten small blacks left” into “I have ten, counted to the second”.

price and variants: not everything costs the same

A detail that gets overlooked: not every variant is worth the same. An XL size may use more fabric and cost more; a special color may come from a different supplier. If your variant structure is clean, you can set a price per variant without breaking anything, and adjust only the one that needs it. If it’s dirty —with size buried in color, with duplicates— any price change becomes a minefield where you touch one and move three.

With variants well organized, planning prices also stops being a memory exercise. You can raise the size that turns over most, leave the one that barely sells alone, and do it across every channel at once; that plan-instead-of-react approach is exactly the automatic price calendar, which only works well on top of a catalog whose variants don’t get confused with each other.

the summary worth pinning to the wall

Naming and organizing size and color variants isn’t glamorous, but it’s what decides whether your catalog scales or collapses. One parent product per garment. Size and color as separate axes. One canonical value per size and per color, written the same way every time. One SKU with a fixed pattern per variant. One unique EAN/GTIN per variant. And a real mapping —not an improvised one— when you cross to another channel.

Do that and the catalog takes care of itself: you filter without noise, stock reconciles, prices move where you want them, and you stop deciding with yesterday’s numbers. Variant mess almost never shows on day one; it charges its bill the day you have 400 combinations and an oversell cancellation you can’t trace. The hygiene you put in at the start is what saves you on that day.