Starting Saturday, April 18, we have had issues with the bulk product editor. Only editing 20 items per batch these days due to progressive performance degradation, and now doing simple text edits causes the entire tab to crash. I’ve contacted support on two separate occasions, only to be given the same basic troubleshooting that goes nowhere. This is happening on multiple computers, across all browsers. The bulk editor is literally the only thing we have issues with, yet there’s no avenue to get this looked at seriously. Any advice?
This does not appear to be a browser, device, or network issue. The problem is isolated specifically to the bulk editor and is likely due to a platform-level performance regression or increased load from product data (e.g., metafields, variants, or multiple columns).
Suggested Solution: 1. Use CSV Import/Export
The most stable and reliable alternative:
- Export products from Shopify
- Edit required fields in Excel or Google Sheets
- Re-import the updated CSV
Avoids UI crashes completely, the best option for bulk updates.
2. Minimize Bulk Editor Load. If the bulk editor must be used:
- Remove all unnecessary columns
- Avoid metafields, images, and variant-heavy fields
- Keep only essential fields (e.g., Title, Price)
3. Work in Smaller Batches in the Bulk Editor
- Limit edits to 5–10 products at a time
- Helps reduce memory load (though not always fully reliable)
Hopefully it will work,
Hi @DptyShopko
As a Shopify partner, this usually is a matter of catalog size and memory limits in the bulk editor rather than an outage affecting everyone. Good practical workarounds are doing bulk edits via CSV export/edit/import or using Matrixify, which is way more reliable when working with big data sets. Also, attempt to split your changes by product type, or metafields, and see if that lowers the load per session.
Since the issue reproduces across browsers and computers, I would stop spending time on local browser cleanup and reduce the edit surface while you collect one useful support record. Export a dated restore point first, then try 5–10 products at a time with only the one or two columns that must change. Leave metafields, images, and variant-heavy columns out of that pass, and wait for each save to settle before moving to the next batch.
Keep a short exception register: batch identifier, intended product count, completed count, skipped/failed count, timestamp, and one example affected product. That makes a support escalation concrete and gives you a safe CSV-based fallback without calling a partially completed bulk job a success.
Disclosure: I’m Ethan Carter, developer of CatalogDelta, a separate read-only diagnostic that does not fix Shopify’s bulk editor or edit products. I used AI to help draft this response and reviewed it for accuracy.
“Export a dated restore point first” is the line to underline, and it deserves to be stronger. The freeze is annoying; the expensive version of this story is a batch that half-saved. The bulk editor writes row by row, and when the tab dies mid-save some products carry the new value and some the old, with no list of which is which.
So for the small-batch workaround: one column per pass, and after every save re-export and diff against the pre-batch export rather than eyeballing the grid. That diff is also your rollback. The rows that changed are exactly the ones to revert if the batch was wrong.
The tool-shaped version of the same discipline is a versioned copy of the products that is compared with the store after each batch, and that shows the writes before any restore. StoreVault does that part: versions as products change, a plan listing every field a restore would touch, undo for what it overwrote. It does not make the bulk editor faster. It makes a frozen tab cost a re-run instead of an afternoon of reconciliation.