How to Migrate to Shopify Without Losing Your Google Rankings (2026 Playbook)

I’ve watched two migrations land on the same Tuesday in different cities, both from WooCommerce to Shopify, both about the same revenue, both with similar catalogs. Two weeks later, one was up 8% in organic traffic. The other was down 47%.

The difference wasn’t luck. It wasn’t Google. It was a list of 14 steps. One agency ran them. The other didn’t.

I’m going to tell you about both projects, because the contrast is the cleanest way to explain what actually moves SEO during a migration. Then I’m going to walk you through the 14 steps in the order we run them on every project, so you can either do this yourself or grill an agency on whether they will.

Two migrations, two outcomes

Project A belonged to a fashion brand at $2.6M/yr, 4,800 SKUs, four years of accumulated organic equity. Their agency built the redirect map in week one of a six-week project. Validated every URL before cutover. Ported metadata in lockstep with the design. Speed-budgeted the new theme. Monitored Search Console daily for 30 days. By day 14 post-launch, organic impressions were up 6%. By day 30, up 8%. CTR went up because the new metadata was sharper.

Project B belonged to a home goods brand at $2.1M/yr, 3,400 SKUs, similar organic profile. Their agency promised a “fast” migration, five weeks. The redirect map happened in week five. Metadata was “filled in” the day before cutover. Nobody ran Lighthouse on the new theme. Nobody opened Search Console for 12 days post-launch. By day 20, organic was down 47%. By day 60, recovered to -22%. They lost about $80K in organic revenue across the recovery window.

I know how Project B’s story ends because they called us in week three of the bleeding to figure out what went wrong. By then, the technical work was twice as hard because we were diagnosing live damage instead of preventing it.

The bedtime version: every Shopify migration carries SEO risk. The risk is preventable. The 14 steps below are the prevention. Here’s how to run them.

Where the drops actually come from

Project B’s drop wasn’t an act of God. It was three causes:

1. URL structure changed without 301 redirects. Old URLs returned 404s. Google de-indexed them inside two weeks. All link equity to those URLs evaporated.
2. Metadata loss. Title tags, meta descriptions, canonical tags, and structured data didn’t get ported. Google lost the signals it was using to rank them.
3. Speed regression. The new theme was 30% heavier than the old one. Core Web Vitals dropped to red. Ranking signals shifted down.

Same three causes, every time. The 14 steps below address all three. Run them in order.

Pre-migration: the audit phase

Step 1: Export every URL Google has indexed

Open Google Search Console. Go to Coverage → Valid. Export the full list of indexed URLs. This is your floor, every URL on this list must either still resolve to the same intent on the new site, or 301-redirect to a page that does.

Cross-reference with Bing Webmaster Tools (still about 5-8% of search traffic for most ecommerce categories). Bing’s index isn’t identical to Google’s.

Step 2: Crawl the existing site as a baseline

Use Screaming Frog (free up to 500 URLs, $209/year unlimited) or Sitebulb. Crawl the entire current site. Export:

• All URLs returning HTTP 200
• Title tag for each URL
• Meta description for each URL
• H1 for each URL
• Canonical URL for each URL
• Schema/structured data types per URL
• Internal link count to each URL (the higher, the more important to preserve)
• Page word count (proxy for content depth)

Save as a CSV. This is your contract with the new site.

Step 3: Identify the “ranking pages” subset

From the crawl, filter to URLs that have organic value. The signal is impressions in Search Console over the last 90 days. Tier them:

• Tier 1 (priority preservation): over 1,000 impressions/month. Lose any of these and the migration was a failure.
• Tier 2 (important): 100-1,000 impressions/month. Most should survive intact.
• Tier 3 (acceptable loss): under 100 impressions/month. Try to preserve, but minor loss here is recoverable.

Most stores have 5-20% of URLs in tiers 1+2 driving 80%+ of organic traffic. That’s the bullseye. Project A had 340 URLs across tiers 1 and 2; we preserved every single one. Project B had 280 URLs in those tiers; the agency lost 90 of them in week one.

Step 4: Plan URL strategy before design

The single highest-leverage decision in the migration. Three rules:

• Don’t change URLs unless you have a reason. Every URL change is redirect work.
• Preserve the URL taxonomy. If your products were at /product/[slug]/ on WooCommerce, they’re at /products/[handle]/ on Shopify. Some change is unavoidable; minimise it.
• Document every intentional change. “We’re consolidating these 3 collections into 1” is a redirect spec. Write it down.

Most “necessary” URL changes during a migration aren’t necessary. They’re aesthetic preferences. Push back on them.

Pre-launch: the build phase

Step 5: Build the redirect map in week one

Not week six. Not the weekend before launch. Week one. The redirect map is the blueprint for the entire URL preservation strategy.

Format: a Google Sheet or CSV with these columns:

Old URL	New URL	Type	Source	Notes
/product/blue-widget	/products/blue-widget	301	Auto-generated	Handle preserved
/product/?p=123	/products/blue-widget	301	Auto-generated	Parameterised version
/collection/best-sellers	/collections/bestsellers	301	Manual	Slug rename
/shop/category/skincare	/collections/skincare	301	Manual	Path consolidation

For WooCommerce specifically, you usually need both pretty URLs and parameterised URLs in the map. Forget either, lose backlinks.

If you remember nothing else from this post, remember this: ask your migration agency when they build the redirect map. If the answer isn’t “week one,” that’s your warning sign.

Step 6: Implement redirects in Shopify before cutover

Shopify supports 301 redirects natively under Online Store → Navigation → URL Redirects. Bulk-import the CSV from your map. Then:

• Test 50 random redirects manually before cutover
• Test all Tier 1 redirects manually before cutover
• Run a script to verify every entry resolves to a 200 (a redirect chain ending in 200 is fine; ending in 404 is not)

This is the most common point of failure in migrations. Don’t skip the validation. Project B’s redirects were “imported” the night before launch. Half of them pointed at the wrong target URL because the import script normalized slug case and the new theme didn’t.

Step 7: Port metadata for every preservable URL

For every URL in tiers 1+2, the new page must preserve:

• The title tag (or improve it, same intent, similar length)
• The meta description (or improve it, 130-160 chars)
• The H1 (the visible page title)
• The canonical URL (point to the new URL, not the old)
• All structured data the old page had

Shopify makes this easier than WooCommerce because metadata is in product/collection/page records, not split across plugin databases. Use Shopify’s bulk product editor or Matrixify for catalog-scale edits.

Step 8: Audit and port image alt text

Image SEO is a quiet ranking factor. From your Screaming Frog crawl:

• Filter to images with descriptive alt text
• Cross-reference against the new site’s image inventory
• Ensure every image with meaningful alt text on the old site has equivalent alt text on the new

For new images on the new site, write proper alt text describing what’s in the frame. “image” or "" doesn’t count.

Step 9: Verify schema parity per page type

Run Google’s Rich Results Test on:

• The old homepage and the new homepage, same Organization, WebSite schemas
• An old product page and an equivalent new product page, same Product, Offer, AggregateRating
• An old blog post and an equivalent new blog post, same BlogPosting, Article, BreadcrumbList
• Any FAQ pages, same FAQPage schema

Theme developers sometimes “clean up” schema thinking it’s clutter. It’s how Google renders rich results. Don’t lose it.

Step 10: Speed-budget the new theme

Before cutover, run Lighthouse on a staging URL of the new theme. Compare against the production site:

• LCP must be ≤ current production LCP
• CLS must be ≤ 0.1
• INP must be ≤ 200ms

If the new theme is slower than the old one, fix it before launch. Speed regression after cutover means rankings drop in 30 days. Don’t ship until the speed budget is met.

This is the step Project B skipped most clearly. Their new theme had 4 hero carousel slides loading on every page above the fold, plus three font weights, plus a third-party countdown app. Mobile LCP went from 2.3s to 4.6s. The damage showed up in week three.

Step 11: Generate and submit the sitemap

Shopify auto-generates sitemap.xml and sitemap-index.xml (which lists individual sitemaps for products, collections, pages, blogs). Verify:

• Every Tier 1 URL is in the sitemap
• The sitemap is reachable at /sitemap.xml
• robots.txt allows crawling

Do not submit the new sitemap to Search Console until cutover is complete. Submitting before cutover causes Google to crawl URLs that aren’t live yet, generating spurious 404s.

Cutover: the launch window

Step 12: Cutover in a low-traffic window

Tuesday or Wednesday at 2am-5am in your highest-traffic timezone. Avoid:

• Fridays (no team available for the weekend if something breaks)
• Weekends (peak ecommerce traffic, peak risk)
• Holiday weeks (peak peak peak)

Sequence on cutover night:

1. Final QA pass on staging (15 min)
2. Disable any “site is being updated” banners on the staging site (we want zero friction)
3. DNS swap to point at Shopify
4. Wait for DNS propagation to start (~5-10 min globally)
5. Verify a sample of Tier 1 URLs resolve correctly
6. Verify the Shopify checkout completes a real order (use a test card)
7. Submit the new sitemap to Search Console
8. Submit Tier 1 URLs for re-indexing via URL Inspection (don’t bulk-request)

Step 13: 24-hour standby

Someone is awake and watching for the first 24 hours post-cutover. Specifically watching:

• Server response codes (any 4xx/5xx surge is a redirect issue)
• Order completion rate (any drop is a checkout issue)
• Customer support inbox (real users surface real problems)
• Search Console real-time data (URL Inspection on suspicious patterns)

Most issues that show up in production but not staging are about redirects. Have the redirect map open and ready to add entries.

Post-launch: the 30-day window

Step 14: Monitor Search Console daily for 14 days, then weekly through day 30

Open Search Console every day for the first two weeks. Watch:

Coverage report:

• New errors (404s, redirect chains, server errors): investigate same-day
• Drops in “Valid” URLs: triage tier first, then investigate

Performance report:

• Total impressions vs. 30-day pre-launch baseline: ±10% is normal noise; >10% drop is a flag
• Total clicks vs. baseline: similar
• Average position vs. baseline: stable or improving on key queries
• CTR by page: a redesign with better metadata often shows CTR lift even when rankings hold

Core Web Vitals report:

• Field data takes ~28 days to stabilise on the new theme
• Watch the LCP, CLS, INP buckets, green is the goal

Sitemap status:

• All submitted URLs accepted
• No errors on sitemap parsing

If a Tier 1 URL has lost impressions after 14 days, request indexing manually via URL Inspection. Don’t request indexing on every URL, only the high-value ones that haven’t recovered.

Project B’s agency never opened Search Console for 12 days after launch. By the time they did, the 47% drop was already two weeks old.

What success looks like at day 30

A migration that respected this checklist looks like Project A:

• Total impressions: ±5% of pre-launch baseline, or up
• Total clicks: flat or up (better metadata, faster site = higher CTR)
• Average position: flat or up on key queries
• Coverage errors: 0-3 minor issues, all resolved
• Core Web Vitals: all green or improving
• Tier 1 URL preservation: 100%

A migration that skipped the checklist looks like Project B:

• Total impressions: down 20-60%
• Total clicks: down proportionally
• Coverage errors: dozens of 404s on previously-ranking URLs
• Core Web Vitals: mixed or red
• Tier 1 URLs: some lost entirely

Recovery from the second outcome takes 60-90 days minimum. Two months of lost organic revenue while you scramble to fix what should have been pre-launch hygiene.

The tools we use

Full transparency on the toolkit:

• Google Search Console, coverage, performance, sitemap, URL inspection
• Bing Webmaster Tools, secondary index monitoring
• Screaming Frog, pre/post crawl comparison, schema validation
• PageSpeed Insights / Lighthouse, speed budget enforcement
• Schema.org Validator + Google Rich Results Test, structured data parity
• Microsoft Clarity, verifying real-user behavior matches expected
• Matrixify (Shopify app), bulk metadata import/export
• A spreadsheet, the redirect map

There’s no proprietary “migration SEO tool.” The work is the work.

The single biggest mistake

If we had to name the one thing that separates good migrations from bad ones: the redirect map gets built in week one, not week six.

When agencies leave the redirect map for the final week before cutover, four things happen:

1. There’s no time to validate it
2. There’s no time to handle parameterised URLs
3. There’s no time to QA all Tier 1 URLs manually
4. The map ships with gaps, and rankings drop

When the redirect map is built in week one, alongside the data audit and the URL strategy decisions, there’s time to find the edge cases, validate every entry, and ship a complete map.

If you’re evaluating a migration agency: ask them when in the project they build the redirect map. If the answer isn’t “week one,” find a different agency. Project A’s agency built theirs on day three. Project B’s built theirs on day thirty-eight. Same tools. Same Google. Two completely different outcomes.

Frequently asked

Will I lose rankings even with a perfect 301 redirect? Google has stated repeatedly that 301 redirects pass nearly all link equity. Real-world: expect <5% drift on a perfectly-redirected URL change. The drops you read about in horror stories are almost always missing redirects, not redirect-induced loss.

How long until rankings fully stabilise? Two weeks for most signals. 30 days for full stabilisation including Core Web Vitals field data. 60 days for any URLs that did move (rare with this checklist).

Should I noindex the staging site? Not necessary if it’s behind Shopify’s password protection (default). If you removed password protection, add a noindex meta and robots.txt disallow. Don’t ship noindex to production by accident, it happens, and it’s brutal.

What if I find a missed redirect after launch? Add it to the Shopify redirects panel immediately. Submit the affected URL for re-indexing. The faster you catch it, the smaller the impact.

Do I need an SEO consultant in addition to the migration agency? Only if the migration agency can’t speak to the 14 steps above. The good ones bake SEO into the migration. The cheap ones don’t, and you’ll need an SEO consultant to clean up after.

Can rankings go up after a migration? Yes, and they often do. Faster site, better metadata, cleaner schema, modern theme architecture all contribute. Project A’s rankings went up 8% in 30 days. The migration is the right time to fix things that were holding the old site back.

Want this run on your migration?

We run a free pre-migration SEO audit covering the 14 steps above. You send us your current store URL plus the source platform. We send back a written report covering:

• The redirect-map strategy specific to your platform
• Tier 1 URLs we’d prioritise
• Schema gaps to address
• Speed budget for the new theme
• Specific platform-side gotchas (WooCommerce, Magento, Wix, etc.)

Get a free migration SEO audit, 48-hour turnaround.

Related reading: The Complete Migration Buyer’s Guide, WooCommerce Migration Real Costs, and Redesign Without Losing SEO, same SEO principles apply.