Variant safety · verified 13 July 2026
Why do Shopify CSV variant fields need Option1?
Shopify treats fields such as SKU and weight as data for a particular variant. Its documentation says those columns depend on Option1 name and Option1 value; omitting the option data during an update can create a new default variant and delete existing variants.
What counts as a complete option?
Option1 needs both a name and a value on each variant row, such as name “Color” and value “Red.” Option2 should not appear without Option1, and Option3 should not appear without Option2. A simple product can use a default single variant, but an update carrying variant fields still needs careful dependency review.
Why can changing an option value be destructive?
Shopify warns that changing Option1, Option2, or Option3 values can delete existing variant IDs and create new ones. Apps, integrations, analytics, feeds, or custom code that reference those IDs may break even when the visible option text looks correct.
How does CatalogVigil respond?
It raises a blocker when variant data appears without complete Option1 fields and when later option levels are incomplete or out of order. It does not invent option names, generate variants, or change option values. The audit explains the affected row so the operator can compare it with a fresh store export.
What is the safer workflow?
- Export and back up the current catalogue.
- Use a small representative file first.
- Keep every product's variant rows together.
- Run the local preflight and resolve blockers.
- Read Shopify's import preview and overwrite warning before confirmation.
- Verify variants, inventory, images, and dependent apps after the staged import.
Primary source: Shopify Help Center product CSV dependencies and overwrite cautions.