How to Clean Up Product Data After a Shopify Migration (Duplicates, Variants, Tags, and More)

The migration finished. The store went live. Then the support emails started arriving: someone bought a size that doesn't exist, someone else found two identical listings at different prices, and half your collection pages are showing nothing at all. Nobody puts this phase in the project plan, but you'll need to clean up product data after a Shopify migration while the store is already taking real orders from real customers.

You're not alone in this. Roughly 2.9 million stores are live on Shopify as of Q2 2026, and Shopify runs a 3.1:1 inbound-to-outbound migration ratio (31,946 stores moved in versus 10,271 that moved away). That's a lot of merchants staring at a freshly imported catalog wondering why the descriptions look like someone dropped a plate of HTML on the floor.

Here's the order of operations that matters. Fix things that cost you money today, then fix things that cost you traffic later:

1. Tier 1 (fix today): broken variants, wrong prices, wrong inventory counts, products that can't be added to cart
2. Tier 2 (fix this week): duplicate products, broken handles and missing redirects, orphaned metafields
3. Tier 3 (fix this month): alt text, malformed description HTML, tag cleanup, collection rules

If you're still in the planning stage and reading this as a warning, good. Choosing carefully between the best Shopify migration apps up front prevents maybe half of what's below. For everyone already on the other side, let's fix what you've got.

Why does migrating to Shopify create duplicate products, and how do you find and remove them?

Duplicates almost always come from one of two things: an import that ran twice, or an import that ran without the "Overwrite any current products that have the same handle" option checked. When that box is unchecked, Shopify creates a brand new product for every row that doesn't exactly match an existing handle, and it quietly appends a numeric suffix (yourproduct-1, yourproduct-2) to keep handles unique.

That suffix is your best detection tool. Export your full product CSV, then filter the Handle column for anything ending in a dash followed by a digit. You'll usually find your duplicates clustered there in a neat, embarrassing pile.

The second detection pass should use SKU and barcode. Drop your export into a spreadsheet, build a pivot table on the SKU column, and flag any SKU appearing under more than one handle. Titles lie because migration tools sometimes truncate or re-case them. SKUs rarely do.

There's a third duplication problem that's specific to the days right after launch, and most merchants miss it entirely. Shopify serves the same product at both /products/handle and /collections/collection-name/products/handle. On an established store, canonical tags handle this fine.

On a freshly migrated store, your imported collections often generate hundreds of these collection-scoped URLs at once. If your theme's canonical logic came over half-configured from a template, Google gets a flood of near-identical pages in a single crawl. Our guide to finding and fixing Shopify duplicate content covers the canonical setup in detail.

When you're ready to remove duplicates, archive rather than delete. Archived products keep their order history and can be restored in one click if you kill the wrong version. Filter your product list down to the suffixed handles, select them, and archive the batch. If you're dealing with hundreds of them, a bulk editor app with an undo log turns a nervous afternoon into a five-minute job.

Then add redirects. Every duplicate you remove should 301 to the version you kept, or you'll be serving 404s to anyone who bookmarked the wrong one.

What causes broken or missing variants after importing from WooCommerce, Magento, or Etsy?

Variants break because Shopify's option model is stricter than almost every platform you'd migrate from. Shopify allows a maximum of three options per product, and that cap has not moved. What did change: on October 15, 2025, Shopify raised the per-product variant limit to 2,048 for all merchants on all plans, up from the old 100-variant ceiling. Media stayed capped at 250 files per product.

So if you read a migration guide written before late 2025 that warns about a 100-variant cap, ignore it. The real constraint in 2026 is the three-option limit, and it bites hardest for merchants coming from platforms that allowed four or five attribute dimensions.

The failure mode is platform-specific:

• WooCommerce: attributes that weren't ticked as "Used for variations" don't become Shopify options at all. Variations set to "Any size" (rather than an explicit value) have no Shopify equivalent and typically import as a blank option value, which breaks the variant picker.
• Magento: configurable products and their simple child products sometimes import as separate standalone products, so you end up with one parent that has no variants plus twelve orphan products that should have been its sizes.
• Etsy: Etsy allows only two variation attributes per listing, so your options fit comfortably. The thing that has nowhere to go is Etsy's personalization field, which isn't a variant and silently vanishes.
• BigCommerce: modifiers and options are two different objects. Options become variants. Modifiers (text fields, checkboxes, file uploads) don't, and they're usually dropped without a warning.

To audit this quickly, export your products and look at the Option1 Name, Option2 Name, and Option3 Name columns. Any product where the option name is "Title" and the value is "Default Title" has no variants. Cross-reference that list against your old platform's export. If a product had variations there and shows Default Title here, it's broken.

For products that genuinely need a fourth dimension (engraving, gift wrap, a file upload for custom printing), variants are the wrong tool anyway. A product options app like Optionize adds those input fields on top of your three real variant dimensions without multiplying your variant count. We walk through the tradeoffs in adding custom product options without breaking inventory.

Why are your migrated product images missing alt text, and how do you fix it at scale?

Most migration tools transfer image files but not image metadata, because alt text lives in a separate field that many source platforms structure differently. Your images arrive, your alt text doesn't, and nobody notices because the storefront looks perfectly fine.

This is a real gap, not a nitpick. Baymard's accessibility research found that 55% of ecommerce sites fail to use alt text to communicate the content of informational images, and 64% embed text directly into images where screen readers can't reach it. The SEO upside of fixing it is documented too: HubSpot's blog team made alt text optimization a priority and grew image search traffic by 779% in under a year, worth about 160,000 additional organic views.

The fix at scale runs through the CSV. Shopify's product export includes an Image Alt Text column, with one row per image. Export everything, fill that column in a spreadsheet using a formula that combines product title, variant, and a descriptive phrase, then re-import with overwrite enabled.

Don't write "product image" 4,000 times. A formula like Title plus color plus product type gets you something like "Merino wool crew sweater in charcoal, front view," which is genuinely useful to a screen reader and to Google Images. Work in batches of 500 to 1,000 rows so the import doesn't time out.

Alt text is Tier 3 work. It won't cost you a sale this week. Schedule it, don't skip it, and pair it with the rest of your on-page cleanup using the Shopify product page SEO checklist.

How do you clean up malformed HTML in product descriptions left over from a CSV import?

Malformed description HTML happens because the Body (HTML) field is a passthrough. Whatever markup your old platform stored gets written into Shopify verbatim, including markup that only made sense inside the old platform's rendering engine.

Four patterns cause 90% of the damage:

• Unrendered shortcodes. WooCommerce descriptions frequently contain WordPress shortcodes like [su_button], [product_page id="99"], or tab shortcodes from a specs plugin. WordPress interpreted those. Shopify doesn't, so they render as literal bracketed text sitting in the middle of your copy.
• Double-encoded entities. A non-breaking space stored as   gets re-escaped during export to  , and your customer reads "Hand-poured soy wax.  Burns for 40 hours."
• Unclosed tags. An orphaned opening tag doesn't stay contained inside the description. It bleeds into the surrounding theme markup and can push your add-to-cart button into the wrong place or italicize your entire footer.
• Pasted styling. Descriptions written in Word or Google Docs carry inline font-family, font-size, and color declarations that override your theme and make one product look nothing like the next.

Here's what a typical WooCommerce leftover looks like before and after cleanup:

Before: <p style="font-family: Verdana; font-size: 11pt;">Hand-poured soy wax.&amp;nbsp;&amp;nbsp;Burns for 40 hours.[su_divider style="dotted"]<p>Made in Vermont.

After: <p>Hand-poured soy wax. Burns for 40 hours.</p><p>Made in Vermont.</p>

Three separate problems in one snippet: inline styling that fights your theme, double-encoded spaces, and an unclosed paragraph tag right after a shortcode that never resolved. Fixing that one product by hand takes 90 seconds. Fixing 3,000 of them by hand takes a week you don't have.

The scalable approach is a find-and-replace across the Body (HTML) field, run as a filtered batch. Three searches catch most of the damage:

• An opening square bracket, to catch every leftover shortcode.
• The string "style=", to catch inline formatting pasted in from Word or Docs.
• The string "amp;nbsp", to catch double-encoded spaces.

Run each replacement as its own pass so you can verify the result before moving on, and always check a preview against a handful of real products first. Our guide to importing products to Shopify from a CSV file without errors covers the encoding settings that prevent half of this on the next import.

What causes wrong SKUs, handles, and URLs after migration, and how do you fix them without tanking your SEO?

Shopify generates handles from product titles using its own slug rules, so your URLs change whether you want them to or not. Old structures like /shop/category/product-name or /product/12345 have no Shopify equivalent, which means every product URL in Google's index is about to 404 unless you redirect it.

The cost of getting this wrong is well documented. An August 2026 analysis of 4,000 AI responses across ChatGPT, Gemini, Claude, and Grok found that poorly executed ecommerce migrations cost merchants 20% to 40% of organic traffic, with a 6 to 12 month recovery window. Every platform in that study attached the same qualifier: the loss applies specifically when redirect mapping and post-launch validation are incomplete.

Build your redirect map from a crawl of the old site, not from your product export. The export only contains products. The crawl contains product pages, category pages, blog posts, and that one landing page from 2019 that still pulls 400 visits a month. Upload the map in Shopify under Content, then Menus, then URL redirects (on older admin layouts it sits under Online Store, then Navigation, then View URL redirects).

If you need to change a handle after launch, edit it in the product's search engine listing section and leave the "Create a URL redirect" checkbox ticked. Shopify will build the 301 for you automatically. Untick it and you've just orphaned a page that may already have accumulated links.

SKUs need their own pass. Watch for source-platform prefixes that came along for the ride (WC-, MAG-), the same SKU repeated across multiple variants (which quietly breaks any inventory sync you connect later), and blank SKUs on variants that had them before. Fix duplicates before you connect a 3PL or an ERP, not after. For the full pre-launch and post-launch checklist, see how to prevent SEO traffic loss when migrating to Shopify.

Why do metafields, tags, and collections break during migration, and how do you rebuild them?

Metafields break in a way that's uniquely nasty: the data can import successfully and still be invisible. A metafield value without a matching definition is orphaned. It exists on the product, it's stored in your database, and your theme has no idea it's there.

Magento migrations suffer worst here because Magento's EAV model stores every custom product attribute separately, and each one needs an explicit mapping to a Shopify metafield definition. Miss the mapping and your technical specs, compatibility charts, and care instructions all disappear from the product page while appearing perfectly intact in your data.

The fix is to go to Settings, then Custom data, then Products, and create definitions whose namespace and key exactly match what your import wrote. Case matters. A definition for custom.material will not pick up values stored under Custom.Material. Once the definition exists, tick the storefront access option or your theme still can't render it.

There's a second metafield trap that catches people weeks after launch. Shopify's CSV importer treats a mapped-but-blank column as an instruction to erase. As Shopify's own CSV documentation explains, leaving a non-required column blank erases that data, while omitting the column entirely preserves it.

So when you export everything, edit only the price column, and re-import, every metafield column that came back empty for some products wipes those values across your catalog. Delete the columns you're not updating. Don't just leave them empty.

Tags degrade differently depending on where you came from. Etsy allows 13 tags per listing and its category taxonomy often gets dumped into them, so you arrive with a tag cloud of 4,000 near-duplicate keywords. WooCommerce merges product categories and product tags into a single comma-separated Tags field, so your navigation structure and your keyword tags become indistinguishable.

Export the tag list, sort by frequency, and delete anything used on fewer than three products. Most of it is noise.

Collections deserve a separate audit because automated collections don't migrate as rules. They migrate as memberships, or they arrive empty. If a smart collection condition depends on product type or vendor and those values changed shape during import, the collection silently stops matching anything.

Check every automated collection's product count against your expectation, then rebuild the conditions against your actual post-migration field values. The WooCommerce data that gets lost during migration guide has a field-by-field mapping if that's your source platform.

How do you catch inventory and pricing errors before they cause overselling or wrong charges at checkout?

Reconcile inventory and audit prices before your first promotional push, not after. Inventory distortion (the combined cost of overstocks and out-of-stocks) is a $1.73 trillion problem globally, equal to 6.5% of retail sales every year, and a fresh migration is one of the highest-risk moments a store ever has for creating it.

Start with locations. If your migration created a default location and your fulfillment actually happens somewhere else, every product may show stock at the wrong place or be marked "not stocked" at the location that ships. That produces phantom availability, which produces overselling, which produces refunds. Our guide to managing Shopify inventory across multiple locations covers the assignment rules.

Then check the "Continue selling when out of stock" flag. Some migration tools set it globally to true so nothing fails to import. If yours did, you're accepting orders for stock you don't have on every product in the catalog.

Pricing has three classic migration bugs. First, tax-inclusive versus tax-exclusive: WooCommerce stores commonly hold VAT-inclusive prices, and if Shopify is set to add tax on top, every product is suddenly 20% more expensive at checkout. Second, multi-currency carryover from BigCommerce or Magento, where a secondary currency's price column maps into Shopify's base price field. Third, compare-at prices that imported the regular price into both fields, so every product displays a fake 0% discount badge.

Audit all three by exporting Variant Price and Variant Compare At Price and sorting for anomalies: compare-at values equal to or below price, prices ending in unusual decimals (a giveaway for converted currency), and anything more than 30% off your expected margin. Then work through the full reconciliation process in reconciling inventory counts after migrating to Shopify, and if you're rebuilding sale pricing from scratch, scheduling bulk price changes is safer than editing live.

What's the fastest way to clean up product data after a Shopify migration without editing every product one by one?

The fastest way is filter, preview, apply, verify, with the ability to undo. Every tool below can do the first four. The difference between them is whether they can do the fifth, and that's the one that matters when you're touching 3,000 products on a store that's already selling.

Here's my honest opinion, and it goes against most migration content out there. Every checklist tells you to clean your data before cutover. That advice is technically correct and almost useless, because nobody catches every broken variant, mangled description, and orphaned metafield in a staging environment under a launch deadline.

You find them when a real customer hits a real bug. The skill that actually saves migrations isn't pristine pre-migration hygiene. It's having a fast, reversible way to fix things in bulk the moment you discover them.

Your realistic options:

• Shopify's native bulk editor. Free and already there. It shows 50 products per page, the column picker omits several fields entirely, and critically, it saves the moment you leave a cell with no confirmation and no rollback. Fine for 20 products. Genuinely dangerous at 2,000.
• CSV export and re-import. Unlimited scale and full field access, which makes it the right tool for alt text and description find-and-replace. The tradeoff is the blank-column deletion behavior covered above, and the fact that a bad import is very hard to reverse.
• Shopify Flow. Free on Basic and every plan above it. Excellent for rules that should keep running (auto-tag anything under $25, alert you when a variant hits zero), less suited to one-time catalog-wide corrections.
• Matrixify. The heavyweight for bulk import and export across products, orders, metafields, and redirects. Steeper learning curve, but it handles data structures the native importer won't touch.
• A dedicated bulk editor app. The category exists specifically to solve the preview-and-undo gap.

On that last point, Edify is built around exactly the post-migration situation described in this article. You build filters with AND/OR conditions to isolate the affected products (say, every item where the description contains an opening square bracket), chain multiple actions into one task, and preview every change before it goes live. Every edit is logged with its old and new values, so a single click reverts the whole task if a find-and-replace turns out to be greedier than you expected. It also supports scheduled edits with auto-revert, which is handy once you shift from cleanup into running actual promotions.

That undo log is the part worth caring about. Preview catches obvious mistakes. Undo catches the ones you only notice three days later when a customer mentions that all your candle descriptions now end mid-sentence. If you want to compare options, we ranked the category in the best Shopify bulk product editor apps of 2026, and the mechanics of filtered batch editing are covered in our complete guide to Shopify bulk product editing.

Whatever tool you pick, work in tiers and export a CSV backup before each batch. Broken variants and wrong prices first, because those cost you money every hour they exist. Duplicates and redirects next, because those cost you rankings over weeks. Alt text, description formatting, and tag cleanup last, because those are improvements rather than emergencies.

Nobody finishes a migration with clean data. The stores that recover fast are the ones that stop trying to and start fixing efficiently instead.