Catalog migration: move 10k products without SEO loss

Catalog migration: move 10k products without losing SEO

An ecommerce migration is the technical operation that fails most often in SEO. Real statistic: 50% to 70% of poorly prepared migrations lose 30% to 80% of their organic traffic in the first year. The best teams come out of it with stable traffic or slight growth.

The difference is neither technical skill nor luck — it is preparation. Here is the complete method to migrate a catalog of 10,000 products without breaking your SEO.

The 4 types of migration

Type 1 — Platform migration: Shopify → WooCommerce, WooCommerce → Shopify, Prestashop → Shopify, etc. URL structures change.

Type 2 — Domain change: old-brand.com → new-brand.com. All external backlinks must be transferred.

Type 3 — URL redesign: same domain, same platform, but a structure change (/products/xxx → /shop/xxx). Often happens during a design redesign.

Type 4 — Category restructuring: same product URLs, but categories/collections are reorganized.

Types 1, 2, and 3 are the riskiest. Type 4 is simpler. This article covers all 4.

Phase 1 — Map legacy URLs (2-3 days)

The first rule: you cannot migrate what you do not know. Before doing anything, export:

Export 1 — List of all your URLs

Combined sources:

Google Search Console: Performance → URL. Export the last 16 months.
Current XML sitemap: parse all URLs
Full crawl with Screaming Frog
Incoming backlinks: via Ahrefs, Semrush, Majestic. URLs targeted by external backlinks are the most critical.

Aggregate everything in an Excel or Google Sheets file. Typically for 10,000 products: 30,000-50,000 total URLs (products + categories + pagination + filters + blog + static pages).

Export 2 — Performance by URL

For each URL, from GSC over 12 months:

Impressions
Clicks
Average position
Top 3 keywords

The URLs in the top 20% by traffic carry 80% of SEO value. These are your redirect priorities.

Export 3 — Reviews and UGC

List products with:

Number of reviews
Average rating
Recently published reviews (freshness signal)

Products with many reviews should never lose their history. That is irreplaceable SEO equity.

Phase 2 — Generate the redirect file (1 day)

This is the core of the project. The redirect file is a 2-column table:

Old URL                                    → New URL
https://old.com/products/derby             → https://new.com/shop/leather-derby
https://old.com/collections/shoes          → https://new.com/category/shoes
https://old.com/blog/post-123              → https://new.com/blog/article-title

Build rules:

Rule 1 — One redirect per URL, no wildcards except in specific cases

Prefer explicit mapping over generic wildcards. A redirect like /products/* → /shop/* looks convenient, but creates problems if slugs change (/products/derby-shoe redirects to /shop/derby-shoe, which does not exist).

Exception: for categories where the structure is identical (/collections/xxx → /category/xxx where all xxx values exist on both sides), a wildcard can work.

Rule 2 — Use 301 redirects (permanent), not 302

301 transfers about 95% of link juice (SEO authority). 302 (temporary) transfers nothing. Use 301 for any permanent migration.

Rule 3 — No redirect chains

❌ A → B → C (a chain of 2 redirects) = signal loss + slower crawling.

✅ A → C directly.

If B existed in your history, consolidate: any URL that should go to C should use A → C and B → C, not A → B → C.

Rule 4 — Redirect to relevant content

If the old URL is a discontinued product with no direct replacement, redirect to:

A very similar product (priority 1)
The parent category (priority 2)
The homepage (last resort, avoid it)

Never return a 404 on a URL that had traffic. That is giving away SEO for free.

Rule 5 — Clean slugs in the new structure

Use the opportunity to fix old slugs:

Remove stray numbers (derby-shoe-1234 → derby-shoe)
Standardize case (all lowercase)
Remove stop words (the, of, and) where relevant
Remove accents (chaîne → chaine)

But only do this if the new URL stays readable. A well-formed slug lasts forever — you might as well start clean.

Phase 3 — Preserve reviews and UGC (1-2 days)

On the new platform, before launch:

Import reviews

Shopify Product Reviews, Yotpo, Judge.me, Trustpilot: all allow export/import while preserving dates.

Step 1: export reviews from the old platform (CSV by product with date, rating, comment, author).

Step 2: import into the new platform with mapping by SKU or by slug if the SKU is identical.

Step 3: verify that AggregateRating is generated correctly on the new site (schema.org Product JSON-LD).

Visible UGC on product pages

Customer photos, Q&A, helpful votes: migrate them if possible. If the new plugin/app does not support import, at least prioritize text reviews (they carry more SEO weight than photo UGC).

Preserve dates

Original review dates matter for:

Product freshness/age signal
Rich snippets (Google prefers dated reviews)
User trust ("2,847 reviews since 2021")

Check that the import preserves review_date, not just the import date.

Phase 4 — Handle images at scale (1-2 days)

Images are rarely migrated automatically. Process:

Export images from the old platform

Shopify: scripts via the API + download from the Shopify CDN. WooCommerce: direct access to the wp-content/uploads/ folder.

Temporary hosting

Upload them to a public CDN (S3 + CloudFront, Bunny CDN, Cloudflare Images). The URLs become public and stable during the migration.

Import into the new platform

Via CSV with image URLs, or via API. The new platforms download the images from the temporary CDN and store them locally (Shopify CDN or wp-content/uploads/).

Alt text and image SEO

Also migrate the alt text for each image. It is a meaningful SEO signal, especially in visual verticals (beauty, home decor). A catalog of 10,000 products × 5 images = 50,000 alt texts to preserve.

Phase 5 — Test in staging (1-2 days)

Never launch directly to production.

Staging environment

Shopify: *.myshopify.com staging store (duplicate of your production store)
WooCommerce: staging on Hostinger, Kinsta, WP Engine
Custom: private subdomain staging.example.com with noindex robots

Tests to run

Top 20 URLs by traffic: each one redirects to the correct new URL (status 301 → 200)
20 random URLs: redirects without chains
Schema.org Product present and valid on new pages (Rich Results Test)
Correct hreflang if multilingual
Sitemap generated with new URLs only (no leftover old URLs)
Robots.txt allows crawling of new pages
Core Web Vitals at least equal to the old site

Also test from an anonymous session (private browsing) to simulate a new user.

Phase 6 — DNS cutover + submission (launch day)

On launch day:

T - 24h

Lower DNS TTL to 300 seconds (5 min) to speed up propagation
Complete a final re-check of all staging tests

Launch time

Change DNS: A record or CNAME points to the new server
Enable 301 redirects (via .htaccess file, nginx config, Cloudflare Workers, or a Shopify Redirect plugin)

T + 1h

Test from several IPs (VPN, mobile network) that the new production site is responding
Check a few critical redirects

T + 24h

Submit the new sitemap to Google Search Console
Use "Request indexing" on the top 10 traffic URLs to speed things up
Submit to Bing Webmaster Tools
Raise DNS TTL back to a normal value (3600 s or more)

Phase 7 — Post-migration monitoring (4 weeks)

Week 1

Check server logs: 404 errors on URLs that should redirect
GSC: Coverage → identify excluded/error URLs
Organic traffic: monitor in GA4

Weeks 2-4

Position changes on top keywords (GSC Performance)
Compare organic traffic to the pre-migration baseline
If -20% at 3 weeks → deep audit (broken redirects, forgotten URLs, different content)
If -5% at 4 weeks → normal, it should recover within 8 weeks

Month 2

Organic traffic should be at ≥95% of baseline
Average positions should stabilize
If the decline persists, bring in an external SEO auditor