Shopify Migration SEO: Keep Your Rankings in the Move

Published: August 24, 2026

Last updated: August 24, 2026

8 min read

On 3 April 2026, a store moved from one domain to another.

The site looked perfect afterwards.

Every page loaded. Nothing 404'd.

Google, meanwhile, was watching a decade of accumulated authority drain into a domain that no longer resolved.

I know the exact date because I was called in to fix it, and the REHAUS rescue became the most instructive job I've done this year.

Not because the failures were exotic.

Because they were ordinary, invisible from the front end, and every one of them is preventable in an afternoon.

That's the thing about migration SEO.

It doesn't fail loudly.

Your store looks fine while your rankings quietly leave.

This is the migration chapter of my complete Shopify SEO guide: the five-link chain that carries your authority across, the autopsy of what happens when a link breaks, the pre-flight protocol, and the recovery playbook if you're reading this mid-disaster.

Short on time? Here are the key takeaways

Equity transfers along a five-link chain: DNS, domain configuration, redirects, internal references, Change of Address.
Migrations fail silently: the store looks perfect while the rankings drain away.
Map every URL before you move: redirect one to one, and verify rather than assume.
Recovery is possible but expensive: half a day of prevention beats six months of repair.

The five-link chain

Here's the mental model I wish every store owner had before they touch a domain.

Ranking equity doesn't transfer because you meant it to.

It transfers along a chain, and a chain is only as good as its weakest link.

Link one, DNS: the old domain must actually resolve and reach the new one. If DNS still points at nothing, nothing downstream matters.
Link two, domain configuration: in Shopify, an old domain can be set to redirect or aliased. Getting this wrong sends every old URL to your homepage instead of its counterpart.
Link three, path-level redirects: every old URL maps to its specific new URL, one to one. Not to the homepage. Not to a category. To the page that replaced it.
Link four, internal references: your navigation, links, sitemaps and canonicals point at the new URLs, not through redirects to them.
Link five, Google Change of Address: the formal notification in Search Console that tells Google the move is intentional and site-wide. It forwards signals for roughly 180 days, after which Google stops associating the two sites, so the other four links need to be right well before then.

Break any one link and the chain carries nothing.

Break three, which is what I walked into, and you get a store that looks healthy and performs like a new domain.

The autopsy

Now the specifics, because generic warnings never change behaviour and details do.

Link one had failed. The DNS at the registrar was never updated, so the redirects everyone assumed were firing simply weren't.

The first fix of the engagement was at GoDaddy, not in Shopify.

Link two had failed. The old domain was configured in Shopify as a redirect rather than an alias, which meant every legacy URL landed on the homepage.

To Google, a thousand distinct pages had all become the same page, which reads as a thousand deletions.

Link three had failed at scale. There were 5,270 live redirects on the store, and 82% of them pointed at the dead domain. Redirect chains led nowhere.

Separately, 530 product URLs had been changed from numeric to descriptive slugs with no redirects at all.

Rebuilding that took roughly 7,000 spreadsheet checks, mapping old to new through Shopify product IDs because the slugs no longer matched anything.

Link five had never been filed.

No Change of Address, so Google had no signal that any of this was deliberate.

The result was a store with modern URLs, clean design, and the search authority of something launched last Tuesday.

Once the chain was repaired and the foundations rebuilt, average position moved from 24.2 to 10.7, and monthly impressions went from 37,123 in April to 218,042 in July.

The full sequence, phase by phase, is in the REHAUS case study.

Recovery is possible.

It's just far more expensive than prevention, and the months in between cost real revenue.

The pre-flight protocol

Everything below happens before you change anything.

If you're mid-migration and haven't done these, stop and do them.

Crawl the old site and keep the file forever: every URL, its title, its status code. This inventory is the only map you'll have once the old site is gone, and nobody has ever regretted keeping it.
Export your winners from Search Console: every URL with clicks or impressions in the last 12 months. These are the pages whose redirects genuinely matter. Everything else is housekeeping.
Export your backlinks: the pages other sites link to are the pages carrying your authority. A redirect miss here is a permanent loss, not a temporary one.
Build the map before the move, not after: old URL to new URL, one row each, checked. On a Shopify replatform, note that /collections/ and /products/ prefixes are forced, so almost every URL will change, and the architecture you're landing in is the subject of my site structure guide.
Log the baseline: clicks, impressions, average position, indexed page count. Without it, you can't prove recovery or diagnose loss.

Half a day of this saves the six-month version of the REHAUS rescue.

Migration day and the fortnight after

The sequence that keeps the chain intact:

Redirect one to one, every time: old URL to its direct replacement. Bulk-redirecting a catalogue to the homepage is the single most destructive move in migration SEO, and it's the default outcome when domain settings are wrong. A redirect-management app earns temporary residence here, as covered in my Shopify SEO apps guide.
Verify the redirects actually fire: request old URLs and read the response codes. 301, single hop, correct destination. Assumption is what broke REHAUS.
File the Change of Address immediately: Search Console, on the day, for a domain move. Two details most people miss: it works on domain-level properties only, and Google now advises running it for every subdomain variant of the old domain, www and non-www included, each verified first.
Keep both properties verified: you need the old property's data to diagnose what's dropping.
Update internal links to final destinations: navigation and body links should point at new URLs directly. Chains work, but they leak and they slow crawling. The canonical hygiene involved is covered in my duplicate content guide.
Submit the new sitemap, resubmit weekly for a month: you want the new URLs discovered fast.
Watch daily for two weeks: indexed pages, 404s and impressions. A migration failure shows in Search Console within days, and a fortnight of attention beats a quarter of archaeology.

Expect a dip regardless.

A clean migration wobbles for two to four weeks and recovers. A broken one flatlines and stays there, which is how you tell them apart.

Once the dust settles, re-run the whole 40-point checklist. Migrations break metadata, canonicals and schema in ways nobody notices for months.

If you're already broken

Reading this because your traffic fell off a cliff after a move? Work in this order.

First, test the chain from the top. Request an old URL and follow what happens.

If DNS or domain configuration is wrong, fixing redirects is pointless because nothing reaches them.

Second, triage by value. Take your Search Console export and your backlink list and fix the redirects for those pages first.

A hundred pages that earned clicks matter more than four thousand that never did.

Third, file the Change of Address if you missed it, even late.

Fourth, rebuild rather than patch.

At REHAUS the redirect file was so compromised that auditing every entry was faster than trusting any of it, and that instinct has been right on every rescue since.

Fifth, use the disruption.

You're already touching everything, so fix the metadata, templates and schema while you're in there rather than restoring exactly what you had.

That's what turned a rescue into a rebuild.

Migrations are recoverable.

The stores that don't recover are the ones that keep assuming the chain is fine because the site looks fine.

Final Thoughts

Migration SEO isn't complicated.

It's just unforgiving, and it fails silently.

Five links: DNS, domain configuration, path-level redirects, internal references, Change of Address. Verify each one rather than assuming it, because a store can look immaculate while carrying none of its authority.

Map before you move. Redirect one to one.

Watch daily for a fortnight.

And if you're staring at a traffic graph that fell off a cliff last month, that's precisely the work I do. The technical SEO audit covers the full chain, and the free audit will tell you which link broke.

Get in touch, or email me directly.

Author Bio

Graeme Whiles is an independent SEO and AEO consultant at GWContent. He has worked with enterprise and SaaS brands, including Originality.ai, Connecteam, 6sense, Practice Better, and Peppr, growing organic traffic and AI search visibility across some of the most competitive categories in B2B. He also built Three Putt Golf Clothing from a blank domain as a live proof of concept for his methodology.

Shopify Migration SEO Frequently Asked Questions

How long does it take to recover rankings after a Shopify migration?

A clean migration dips for two to four weeks and recovers. A broken one doesn't recover on its own, because the problem is structural rather than temporal. At REHAUS, a rescue starting in April had impressions up 5.9x by July, but that took a full chain repair plus a foundations rebuild, not patience.

Do I need to redirect every old URL?

Every URL with traffic, backlinks or indexation, which is a smaller list than every URL. Prioritise pages with clicks, impressions or external links, and map them one to one. Redirecting the long tail to relevant collections is acceptable. Redirecting everything to the homepage is the classic catastrophe.

Does changing my Shopify domain hurt SEO?

Only if the chain breaks. Domain changes are routine when DNS resolves, the old domain is aliased correctly, path-level redirects fire, internal links update and Change of Address is filed. Every serious migration loss I've audited traces to one of those five links, not to the move itself.

Should I redesign and migrate at the same time?

Ideally no, because when traffic drops you won't know which change caused it. If you must combine them, migrate the URLs and redirects first, verify recovery, then change the design. The exception is a rescue, where everything is already broken and the rebuild is the recovery.