If you went looking for the variants screen last week and couldn't find it, it hasn't broken. Shopify moved variant management onto the product page itself on 29 October. You no longer click a size and get thrown onto a separate page for that single SKU: in the new layout you edit variants on the product page, with price, SKU, barcode, inventory and variant image opening in place while the title, description, media and collections stay on screen behind them. For an apparel brand restocking S to XXL across four colourways on day three of a Diwali sale, that's one screen instead of twenty-four page loads on a warehouse Wi-Fi connection.
Where the variants page went
Nowhere good or bad. It collapsed into the product record. Previously every variant had its own URL and its own form, which meant that checking whether Maroon / L had the right SKU required leaving the product, reading the variant, and coming back. The old URL pattern still resolves in most cases, but it isn't where the admin sends you anymore.
What you get instead is a variant list on the product page with inline editing and multi-select. Tick five rows, change the column you care about, save once. The product's media library sits right there, which matters more than it sounds: assigning images to variants used to be the step everyone forgot because the images were on a different screen.
The festive restock, before and after
Take a kurta set in four colourways and six sizes. 4 × 6 = 24 variants. A mid-sale restock means updating inventory on maybe sixteen of them because the rest never sold out.
Under the old flow that was roughly five interactions per variant: open, click the quantity field, type, save, go back. Eighty actions, plus sixteen round trips to the server. Under the new one it's a single list, filtered, with the quantity column editable in place. We time these things when we rebuild a merchandising workflow and the honest number is a 60 to 70% reduction in clicks for a mixed-size restock. Not revolutionary. But if your merchandiser does this four times a week through October and November, it adds up to most of a working day.
The bigger win is contextual. When the product description, the size chart metafield and the collection assignments are all visible while you're editing stock, you catch the thing you weren't looking for. A colourway still sitting in the "Diwali Edit" collection three weeks after it sold out, for instance.
How to bulk edit sizes and colours on Shopify, and which tool to use when
There are three ways to change a lot of variants at once, and they're good at different jobs.
- Inline multi-select on the product page. Best for one product, up to a few dozen variants. Changing the price on every size of one style, marking a size run as continue-selling-when-out-of-stock, fixing SKUs after a vendor changes their code.
- The bulk editor grid. Still there, still the fastest thing Shopify has built for typing numbers across many products at once. Select products from the product index, open the bulk editor, add the columns you want. This is what you use when you're repricing forty styles for end-of-season.
- CSV export and import. For 200+ variants, or when the source of truth lives in your ERP or a spreadsheet your production team maintains. One warning that costs people real money every EOSS: the inventory quantity column in a CSV import sets the value, it doesn't add to it. Export, edit, re-import at 11pm and you can zero out stock on styles you never touched.
Rule of thumb we use: one product, use the product page. Many products, one field, use the bulk editor. Many products, many fields, use CSV and test on two products first.
Adding a new colourway to an existing product
On the product page, open the Colour option, add the value, and Shopify generates the new size run against your existing size option. Four sizes already there means four new variants, created empty. Then you do the three things people skip: set inventory at the right location, assign the variant images, and check the SKU format matches the rest of the catalogue.
The real decision is upstream. Should the new colourway be a variant at all, or its own product?
Keep it as a variant when the price, fabric, GST rate and size curve are identical and you want all the review and ranking signal pooled on one URL. Split it into a separate product when the colour is genuinely a different buy, when you want it to rank for its own query, or when you need it as a distinct item in a Meta catalogue with its own creative. Most Indian apparel brands overuse the second option, end up with eleven near-duplicate product pages for one silhouette, and then wonder why none of them rank.
One structural constraint worth knowing before you commit: if you sell from more than one location, every new variant needs stock set per location, and a bulk import that only carries one location column will quietly leave the others at zero.
Option order and size charts for Indian clothing
Put Colour first and Size second. Most themes render the first option as the primary selector, and shoppers choose colour before size on apparel. Get this backwards and the customer picks XL, then switches colour, then finds XL is sold out in that colour and has to start again. On mobile, on a 4G connection in a metro, that's where they leave.
Option names need to be boringly consistent across the catalogue. "Maroon", "Marroon" and "Dark Red" are three facets in your filter menu and three rows in your merchandising report. Same for sizes: pick one scheme per product type and stick to it. Mixing S/M/L with 38/40/42 inside the same collection makes the size filter useless, which matters because collection filtering is how most customers shop a catalogue over about 150 SKUs. If your size and colour filters are already a mess, FilterPro will give you cleaner facets and search, but it reads what you give it: fix the option values first.
Size charts belong to the product, not the variant. The clean way is a metafield on the product holding either a chart reference or the measurements table, with the theme rendering it near the size selector. Build one chart per fit (kurta, straight-leg, relaxed) rather than one per style, and give measurements in inches with the body measurement, not the garment measurement, unless you say which you mean. Indian sizing varies enough between brands that "L" alone tells a shopper very little, and ambiguous sizing is a direct input into your return rate.
Variant images: the step everyone gets wrong
Uploading maroon photos to the product media library does not make them show when someone selects Maroon. You have to assign the image to the variant. With the new layout the media sits on the same screen as the variant list, which removes most of the excuse, but the assignment is still a deliberate act.
Two things to check in your theme. First, whether selecting a colour swaps the whole gallery or only the featured image. Many themes do only the featured image, so a customer picking Maroon sees one maroon shot followed by five navy ones. Second, image weight. Twenty-four variants at 1.2 MB a photo is roughly 28 MB sitting on one product page. Compress the same set to 150 KB each and you're at 3.6 MB, which on a weak mobile connection is the gap between a page that loads and one that gets abandoned. Lazy-load everything below the first image. If product pages are your slowest templates, that's usually variant media plus app scripts, and it's fixable in a week of focused work: our speed work starts by measuring both.
Editing variant prices without the bulk editor
Click into the variant on the product page and change the price field. For a handful of sizes that's quicker than opening the grid.
For a sale, don't do either. Use an automatic discount or a price list instead of rewriting prices, because every price edit churns your Google Merchant Center and Meta feeds, invalidates compare-at pricing, and leaves you doing a manual reversal across hundreds of variants when the sale ends at midnight on the last day of EOSS. Automatic discounts expire by themselves. Edited prices do not, and we have cleaned up enough post-festive catalogues where half the range was still at sale price in the second week of December.
Where per-variant price editing genuinely earns its place: a size that costs more to make. 3XL in a heavier fabric, a plus-size range cut from more cloth. Price those up at the variant level and keep the GST rate in mind, since the 1,000 rupee threshold on apparel means a size-based price bump can push one variant into a different slab. That one catches people.
Why the inventory number on this screen lies, and what to do about it
None of this admin tidiness fixes the structural problem with Indian apparel inventory: cash on delivery. If a large share of your orders are COD and a meaningful fraction of those are refused at the door, the stock figure on your product page is wrong for the ten to fourteen days it takes Delhivery or Shiprocket to get the parcel back to your warehouse and for someone to scan it in.
Practical consequences. Hold a buffer on fast-moving sizes rather than selling to zero, because an L that shows out of stock when 30 units are in RTO transit is a sale you refused. Reconcile returns into inventory weekly, not monthly. And if you oversell during the festive peak, decide in advance whether to cancel or backorder, because deciding at 2am with 400 orders in the queue goes badly.
A worked example on the size curve
Say you're reordering 600 units of a style that sells across six sizes. Flat split gives 100 per size. Your actual sell-through curve looks more like S 10%, M 22%, L 26%, XL 20%, XXL 14%, 3XL 8%.
On the curve, L should get 600 × 0.26 = 156 units. Flat gives it 100, so you stock out of your best size about 36% earlier in the season. At the other end, 3XL should get 48 units; flat gives it 100, leaving 52 units that only move in EOSS.
Put money on it. A kurta at ₹1,200 with ₹500 cost carries ₹700 of margin at full price. Sold at 50% off, revenue is ₹600 and margin is ₹100. The gap is ₹600 a unit, and 52 × ₹600 = ₹31,200 of margin handed away on one style because the buy was split evenly. Run five styles that way and you've paid for a season of merchandising help.
The admin change doesn't fix your buying. But a variant list that shows every size's sell-through in one view makes the curve visible while you're looking at it, which is the first step to buying against it.
Quick answers
Can I still use the bulk editor? Yes. It's unchanged and still the right tool for repricing many products at once.
Did anything break in my theme or apps? The storefront is untouched. What changed is the admin surface. Apps that wrote to variants through the API behave as before. If an app injected UI into the old variant detail page, that's worth checking.
Can two people edit the same product at once? They can both have it open, and the last save wins. During a festive restock, split by colourway rather than by size so two people aren't saving the same rows.
Is there a faster way to add 200 variants? CSV, every time. Build it in a sheet with the option columns in the order you want them rendered, import, then fix images on the product page.
What to do this week
Export your products as CSV and pivot on Option1 Value and Option2 Value. If that list has more unique values than you have actual colours and sizes, you have a data problem that no admin redesign will solve, and it's currently breaking your collection filters and your product feeds. Clean it before the next big sale, not during.
If the cleanup needs theme work (gallery swap on colour selection, a proper size chart metafield, variant-aware structured data), that's a scoped job rather than an ongoing one. You can bring in a developer for the specific piece, or send us the store URL and we'll tell you what we'd fix first in a free audit.