The Store Migration Checklist With A Pass Condition On Every Item

You have a launch date and a migration plan. What nobody on the project can yet prove is that the redirects fire, that your product pages kept their titles, and that the new site is no longer hidden from Googlebot.

Migrations lose their rankings in that unproven ground. "Redirects are set up" and "redirects fire" are different states, and only the second protects what your store earns. Every item below carries the condition that proves it passed.

I am John Butterworth and I run Mint SEO, a Shopify and ecommerce SEO agency in Manchester. Across 11+ years in SEO I have driven 3M+ organic sessions, and migrations lean hardest on the technical SEO discipline in our eight-disciplines model.

A fair share of that work has been repairing migrations afterwards. Store owners hand me their completed checklist and it is rarely wrong. It is unverifiable.

Two expectations before you start. A correct migration still dips while Google reprocesses it, so a fall in week two is not a verdict on the work. And what breaks on a shop is mostly not what a general guide covers.

What To Record Before The Old Site Comes Down

This is the only phase you cannot redo. Once the old site is switched off the record of what it held is gone, and every later decision you make reads from whatever you captured while it was still answering.

What To Capture While The Old Site Is Still Up

A crawl on its own is not an inventory. Crawlers reach what is linked from somewhere they already know about, so orphaned pages and pages people only ever reach from search never appear.

For everything the crawl misses, Screaming Frog's migration tutorial says to supplement it with Search Console top pages, log files and sitemaps. Export all three, and treat the union of them as your URL list.

Twelve months of Search Console data gets skipped most often, and it is what prices the inventory. Without it you hold URLs but no sense of which ones earn.

That pricing matters later, when the redirect map gets cut for time and somebody has to say which cuts are cheap.

All of it feeds one artefact. In Lumar's checklist the instruction is to create a mapping document that lists the legacy URL and the new destination URL to show where each URL will be redirected.

One row per old URL, and no blanks.

Old rules go in the same document. Watch too for legacy redirects that might be in place from previous migrations. That is how a store ends up serving a three-hop chain starting at a URL nobody has linked to since 2019.

Scope belongs in this phase too, and it is a decision to take before anyone touches the new build. Google's site-move documentation asks you to change only one thing at a time, and to plan the changes one after another.

Plenty of projects ignore that. A review of migration management by SALT.agency finds it is not unusual to see projects that combine a redesign, platform migration, and URL restructuring into a single release.

Stack three migrations into one launch and no drop afterwards can be attributed to any of them.

Staging the move is the alternative, and it is a real one. For a large catalogue Google suggests you split your move into smaller steps, starting with a section that changes little.

You pay for that in a longer window, and what you get back is the ability to tell which release broke what.

Deciding What Redirects, And What Is Allowed To 404

Redirecting every old URL somewhere is the default, and it is wrong. Where a page has no equivalent, the site-move documentation from Google asks you to return an HTTP 404 or 410 error response code on the new site.

Practitioners get there differently. In an r/SEO thread on redirect chains, the commenter SEO_Humorist noted that 301s eat crawl budget, which is one reason 404-ing worthless pages is tidier.

The redirect itself is not your risk, because Google states plainly that 301 and other permanent redirects don't cause a loss in PageRank. Your risk sits in rules that are missing, chained or aimed at the wrong page.

That makes it a per-URL decision. Direct equivalent, closest relevant parent, or gone.

The URL Traps That Only Break On Stores

Every page ranking for this search is written for a generic website. The three problems below put a store's revenue at risk, and your redirect map can be complete while all three are live.

Collection And Product Handles Move Differently

On Shopify you do not own your URL structure. Products and collections sit under fixed path segments, and only the handle at the end is yours to set.

To put a number on how absolute that is, on 7th August 2026 I pulled the product and collection sitemaps of three live Shopify storefronts. Of the 278 URLs sampled, 275 carried the fixed `/products/` or `/collections/` segment.

That means a store arriving from WooCommerce or Magento cannot keep its old URLs, even for products that have not changed.

Your redirect map covers the whole catalogue by definition. Its size is your product count plus your collection count.

Shopify's own redirect handling adds a second trap. Its URL redirect documentation explains that redirects only work for URLs that return 404 errors, so if you later change the collection's online store visibility back to visible, the URL redirect is automatically deleted. A rule you set in week one can vanish in week six because a merchandiser unhid a collection.

Filters And Facets Multiply On The New Platform

Facet URLs cannot be mapped. The old ones have no counterparts and the new ones did not exist when you built the map.

The reason the old plan does not transfer is given by Truelogic: faceted navigation on the new platform generates URL patterns that the old internal linking strategy didn't account for.

Left open, the effect is not subtle. The same agency documented a plateau that went from a sensibly indexed catalogue of 3,000 pages to 47,000 indexed URLs within three months of launching on a new platform.

Facets therefore get rules of their own. Decide before launch which combinations may be indexed, canonicalise the rest to the clean collection, and disallow the parameter patterns you never want crawled.

We give every filter on a store one of four answers, set out in our guide to faceted navigation.

The Two Addresses Your Shop Answers On

Your shop answers on more than one address, and Google Search Console treats each as its own property. In June 2026 Google revised its site-move documentation to ask you to submit Change of Address requests for all subdomains and the www and non-www variants of the old domain name.

That wording matters, because one request does not cover the others. Google's own help page for the tool states that it does not move any subdomains below the domain you specify, www included.

That omission has a cost. A report from Search Engine Land puts it plainly: each variation may have accumulated independent signals in the index, and not migrating one of them may leave part of the site's SEO heritage behind.

Scope matters here, because it changes how you should read the risk. Coverage of the same change by PPC Land establishes it was narrowly scoped, and does not alter how Google processes a move.

The risk was always there, then. Google has only now written it down.

I wanted a base rate for how often this is already broken, so I measured one. On 7th August 2026 I took the 49 storefronts on the featured stores list published by Shopify and requested both addresses of each over HTTPS, followed every redirect, and recorded the final status. One store could not be measured because of a TLS error and is excluded, leaving 48.

Of those 48, exactly 42 serve at least one variant needing two redirect hops to reach the live page, and one store answered both addresses in a single hop. Worse than the extra hop, five fail outright. Two return a 409 on the www address and another returns a 403. One has no DNS record for its www subdomain at all.

On the last of the five, the address returns a 302 to itself, repeatedly, until the request is abandoned. These are well-regarded shops on a list Shopify publishes. Nobody inside them is likely to know the second address is broken, because nobody inside them ever types it.

It happens on Shopify because the two addresses rest on different DNS records. Shopify's domain connection guidance is specific: A records should show 23.227.38.65 as the destination address, and CNAME records should point to shops.myshopify.com. Your www variant rides on the CNAME, so it can be wrong while the root domain works perfectly.

Verification comes before any of it. On the tightened requirements, Search Engine Journal is blunt: you must ensure that you have all of these variants verified in Search Console.

That verification carries a lead time you need to plan for.

None of this is exotic. Lumar's checklist has long listed a test for non-www. URLs redirecting to the www. version (or vice versa) as a standard pre-launch task.

What You Should Refuse To Launch Without

These checks carry a deadline. Each is cheap in the hour before launch and expensive in the week after.

Proving Every Redirect Fires

Reading the redirect file tells you what somebody wrote. It does not tell you what the server does with it.

Those two diverge when a platform rule overrides yours, when rules are ordered wrongly, or when a new rule lands on a leftover from the last migration.

Proof means requesting the old URLs and reading what comes back.

That method is documented in a redirect audit tutorial from Screaming Frog: use list mode to upload a list of old URLs and follow the redirect chain. A rule can fire and still land two hops away, which is what following the chain exposes.

Run it against the new site and the output gives you a status and a full chain for every URL you exported. That is what turns a redirect file into evidence.

Your pass condition is one line to hand a developer. Every old URL, one hop, ending in a 200.

Chains are the thing to hunt in that output, because every extra hop costs you twice over. In the same r/SEO thread, who_am_i_to_say_so summarised the practitioner position as keeping as few hops as possible between point A and point B.

Users pay too. Another commenter there, cinemafunk, described chains costing hundreds of milliseconds of connection time on every visit.

Internal links deserve the same test and get forgotten. A third commenter, Nyodrax, put it simply: every link on your site should lead to a 2xx page.

A new theme aimed at old URLs passes every redirect test you run, while routing each visitor through an extra hop.

Did The Content Arrive, Or Just The Address

A redirect can resolve perfectly onto a page that arrived stripped of its title tag, its H1 and its structured data. Every redirect check you just ran still passes.

That is why whether the content survived is a separate question, and it needs its own proof. That proof is a crawl comparison.

A crawl comparison in Screaming Frog will detect changes in elements and metrics, such as page titles and meta descriptions.

On a store the fields worth raising an alarm over are the title, the H1 and the product schema, because those are what the ranking was resting on.

Crawl the old site before it goes, crawl the new one on staging, then diff the two field by field.

Where URLs changed, the same tutorial's URL Mapping feature pairs them, and without that pairing the comparison has nothing to match on and reports every page as new.

This is established practice. Lumar's checklist has a day-of instruction to review on-page elements of the site such as page titles, headings, and body content.

Google's own sequence opens the same way: prepare the new site and test it thoroughly.

Taking The Site Out Of Hiding

Whatever hid your staging site has to come off, and the things that hide a site are not one thing. Google's documentation asks you to confirm that you'll remove the noindex rules when you start the site move.

It separately asks for a robots.txt written for the new site, reflecting what you want blocked. The build environment's file should never carry over untouched.

Order matters. Lumar's checklist recommends adding authentication to the website so it can only be accessed by using a username and password.

That leaves a blanket robots.txt disallow as the fallback. Those two are lifted in different places, so removing one leaves the other standing.

Disallow and noindex do different jobs. Blocking a URL in robots.txt stops it being crawled; it does not remove a page already in the index. Check each control by name, on the live host, after the deploy.

While you are choosing the hour to do this in, there is one scheduling note worth taking from Google's own guidance.

Google's advice is to time your move to coincide with lower traffic, if possible. For most stores that means a weekday morning, when the people who can fix things are awake.

What Normal Looks Like After A Migration

Once the work is done the job changes from doing to reading. The curve turning on time is what you are reading for.

What A Normal Dip Looks Like

A correct migration still dips, because the move is reprocessed URL by URL over time.

Google's documentation is explicit here. To consider a site move complete, Googlebot will have to visit every URL on your old and new site at least once. There are no fixed crawl frequencies, so large catalogues recover as a long tail.

For scale, Google's own expectation is that a medium-sized website can take a few weeks for most pages to move in its index, and larger sites can take longer.

Commercial numbers land on the same shape. Across a set of domain transitions, Truelogic describes a window running 4 to 8 weeks for light platform updates.

On the same reading, a large-scale domain change runs 6 to 12 months. Which of those two you land in decides the difference between planning for a bad quarter and planning for a bad year.

The size of the change sets your position in that range.

That size is something Google's John Mueller has spoken to. A protocol move will happen a lot quicker because that type of site move is easier for Google to map. Changing the domain name and file names is the slow case.

When A Dip Becomes A Fault

A dip becomes a fault when it fails to turn. Your threshold is a date, taken from the sizing above. Agree it before launch and hold yourself to it.

The reason to take it seriously is that a real minority never come back. A study by SALT.agency found that 13.9% of domain migrations from the 1,052 tested did not show full traffic recovery signals after 3 years.

A second, independent dataset agrees on that shape. A study of 892 migrations cited by Search Engine Journal found 17% never recovered.

Budget does not decide which cohort you land in, and neither does the size of the team doing the work. SALT.agency's read of its own dataset is that quick recoveries share clean technical execution, correct 301 redirects at scale and no redirect chains. Each of those is decided before launch.

The order to check is fixed. Redirects, then indexation, then content parity.

That order comes from what gets repaired in practice. Two months after a move, the store owner wilecoyote42 described impressions at half their old level and average position gone from 6.7 to 12.3.

In the redirect thread, CheeryRipe noted that repairing bad migrations is done primarily by fixing redirects.

That diagnostic order assumes the drop is yours to explain. Rule out one more thing before you trust it: migration windows run for weeks and core-update rollouts run for weeks, so the two overlap far more often than store owners expect.

When they do overlap, no amount of redirect testing will separate the two effects in your traffic. A ranking change you caused and a ranking change Google caused look identical in Search Console.

Check Google's published ranking-update history for anything that ran across your launch window, then plot those dates on the same chart as your own.

Be honest about the ceiling too. Mueller's position on site moves is that the outcome is impossible to know fully ahead of time.

For what recovery looked like across real moves, we pulled together eleven published ecommerce migrations and what they recovered.

How Long The Redirects Have To Stay

Longer than the project. Google's site-move guidance is to keep the redirects for as long as possible, generally at least 1 year.

On a store carrying earned links the honest answer is that they are permanent, because the links are not yours to update. Back in that r/SEO thread, wilecoyote42 described the position most sites are in: the backlinks still point to the old domain.

Nobody else is going to change them for you. Since a permanent redirect costs nothing to keep, there is no upside to weigh against removing it.

One last expectation, because it surfaces whenever a struggling store replatforms. Moving does not repair a domain.

In an r/SEO thread on a WordPress-to-Shopify move, SnooPuppers4708 put it directly. Shopify will not recover your domain's position in Google, because that is a domain problem rather than a platform one.

Where you move is a separate decision from how you move. I have compared the main ecommerce platforms on ranking terms elsewhere.

Where Mint SEO Fits Into A Migration

A migration is technical SEO work against a deadline that will not move. That is the situation where bringing in someone who has done it before pays for itself.

The work is crawlability and indexation, redirect mapping at catalogue scale, and the structured data that has to survive a template rebuild. All of it sits inside our technical SEO service.

The order we work in on a store is the same one set out in our guide to ecommerce technical SEO. A migration compresses that order into a fixed date.

I run these projects myself, so when you get on a call with Mint SEO you are talking to me.

That call is most useful before the switch, while the plan can still change. Book your free 30-minute consultation and I will go through your current rankings, the shape of your redirect map, and the parts of your move most likely to cost you.