Decide what belongs to the product and what belongs to a variant
The product record describes the shared item; the variant describes a selectable combination that may need its own price, stock, SKU, barcode, image or fulfilment detail. Make the distinction using the actual way the business sells and fulfils the item, not merely the number of fields the platform offers.
Shopify describes a variant as a combination of option values, such as one size and one colour, and lets merchants manage inventory for each variant. Other commerce systems may model choices differently. Confirm the platform's current limits and behaviour before designing an import format around assumptions from another system.
Make the data match what is actually stocked
One Shopify merchant described two frame types and 22 fabrics creating 44 combinations, while the physical stock was 20 frames shared across the fabric choices. The merchant said an order reduced stock only for the selected combination and asked how to avoid overselling the shared frames. This is one self-selected store example, not detail of typical Shopify behaviour; it shows why the team must identify the physical stock unit before copying quantities into variant rows.
Use a small matrix to separate common product details from fields tied to a sellable combination. Treat the stock rule as its own decision: if several options consume the same physical item, record that relationship and verify that the chosen platform or inventory integration can enforce it. Do not duplicate a shared quantity across rows unless the stock system actually treats those quantities separately.
| Record | Fields to decide | Fictional example | Import check |
|---|---|---|---|
| Shared product | Name, maker, product type and common description | Studio chair; oak or walnut frame; navy or sand upholstery | Keep shared details at product level where the platform supports it |
| Sellable variant | Option values, platform variant ID, SKU if used, and any price or image that changes | Oak + navy; CH-OAK-NAV | Check the selected value, order line and fulfilment record refer to the same item |
| Inventory rule | Physical item counted, stock location and which sale consumes it | Oak frames: 20 units shared across fabric choices | Do not copy 20 into every oak/fabric row; verify shared-stock handling in the chosen system |
| Unavailable combination | Whether the combination can actually be sold | Walnut + sand: not offered | Do not import a selectable option without a sellable item and fulfilment path |
Create controlled option names and values
Use one confirmed option label for one concept, such as ‘Size’, and standardise values such as ‘Small’, ‘Medium’ and ‘Large’. Decide whether colour names describe the appearance shoppers see, the supplier's code or both. Keep internal identifiers out of customer-facing labels unless they help a purchase decision.
Check combinations for impossible or unavailable pairings. A product may not exist in every size and colour. The selection interface should show which combinations can be purchased and prevent the buyer from choosing an invalid state.
- Option name and allowed values
- Variant identifier and SKU owner
- Price and inventory source
- Variant image or specification changes
- Unavailable combinations and display behaviour
Treat variant images and URLs as deliberate decisions
Assign a specific image when the variant changes a visible feature a buyer needs to confirm. Check that selecting a value updates the image and any related specification, and that the selected state is plain to keyboard and screen-reader users.
Google Search Central says a product variant can be identified by its own URL, such as a path or query parameter. Its guidance also says to use the base product URL as canonical when an optional query parameter identifies the selected variant. Decide how the storefront represents a selection, then check that the URL, visible product information, canonical and internal links agree. A variant URL and a separate indexable product page are different decisions; meeting Google's technical requirements does not guarantee indexing.
Validate the import against operational examples
Before a bulk import, select a small sample that includes a simple item, a multi-option item, a discontinued option and an item with variant-specific stock. Compare the source spreadsheet with the storefront, order record and fulfilment view.
Check that the buyer's selected label, the order's variant identifier and the warehouse's pick information refer to the same item. Resolve mismatches before importing the full catalogue; correcting inconsistent identifiers after orders begin is harder to control.
Document who owns catalogue changes
Name the owner for option vocabulary, identifiers, price and stock data. Give the team a rule for introducing a new option and updating an existing product when supplier terminology changes.
Keep a record of the import date, validation sample and unresolved exceptions. A clean data model helps product content, search, filters and fulfilment stay aligned, but it cannot replace accurate stock and pricing operations.