Most website migrations do not fail on launch day. They fail in the two weeks before it, when a URL structure gets changed after the redirect map is finished, or in the two weeks after it, when a setting nobody looked for is quietly telling Google to index the wrong version of every page.
A migration changes URLs, internal links, templates, and page layouts at the same time. Search engines have to rebuild their understanding of your site from scratch, and they do it on their own schedule. Some disruption is normal. Losing rankings permanently is not, and the difference almost always comes down to what happened before launch.
Between April and July of 2026, Method and Metric consolidated three Shopify storefronts spread across two accounts into a single domain for Luisa Paixão, a Portuguese homeware brand selling into Europe, the US, and the UK. The US store at luisa-paixao.us and the UK store at luisa-paixao.uk both had years of accumulated rankings and both had to disappear into subfolders on luisa-paixao.com without the brand losing them.
Most of what follows comes out of that project. Here is what to check before you move, what actually breaks, and how to confirm the move worked.
Start With an Inventory
The most common mistake in a migration is skipping the pre-migration audit. Without one you have no benchmark. Traffic goes down after launch and there is no way to say whether that is normal settling or a real problem, because nobody wrote down what normal looked like.
Crawl your current site first and get a complete list of every page. Then layer three data sources over that crawl:
- Google Search Console (GSC) for pages that earn impressions and clicks, including ones you forgot existed
- Google Analytics 4 (GA4) for pages that drive conversions rather than just traffic
On the Luisa Paixão project that meant three inventories, two sets of top pages, and two different pictures of what mattered, because the UK store and the US store had grown differently and were not ranking for the same things.
Back up everything before anything moves.
Keep the Old Accounts Alive
Every account attached to the old setup should stay open well past launch day. The urge to close things down and stop paying for them arrives at exactly the wrong moment.
Search Console and Analytics properties cost nothing to keep, so keep them indefinitely. The old platform account is the one that costs money, and it still deserves a buffer. Give it a month or two past launch. You will find data you did not know you needed to export, and if anything about the migration has to be reversed or re-run, doing that from a live account is a different job to doing it from a backup.
A Migration Moves More Than URLs
Migration advice tends to stop at redirects. Redirects are the part that protects search rankings. They are not the part that protects the business.
The Luisa Paixão consolidation moved products, collections, order history, customer records, and an active Smile.io loyalty program into the destination account. None of that shows up in a crawl. A shopper who logs in after launch and finds their order history gone or their reward points reset doesn’t care that the redirect fired correctly.
Two categories are worth naming specifically, because both are easy to lose by default rather than by accident.
Customer state
Order history, saved addresses, subscription status, loyalty balances, store credit. Confirm each one has a migration path before launch, not after. Some of these have no path at all on certain platforms, which is something you want to know in month one of the project rather than in launch week.
Existing translations
This one is the least obvious and it caused the most deliberation on the project. The destination account already had English translations in place. Migrating the US and UK markets into it would have applied those generic translations over the top of copy that had been running, and converting, in those markets for years.
We imported the existing US and UK translations and treated them as the source of truth for the new markets instead. The default behaviour would have been technically successful and commercially worse. If you are consolidating stores that have been localized separately, decide explicitly which version of the copy wins.
Build a Redirect Map That Holds Under Pressure
The redirect map is the part of a migration that protects your organic performance, and it is also the part most likely to be rushed.
Map One to One, Based on Intent
Every old URL should point to the closest equivalent page on the new site. Not the category page, not the homepage, the equivalent page.
Redirecting large groups of old pages to the homepage is tempting because it takes an minutes instead of a week. It also concentrates the authority those pages built into a single URL and leaves every other page on the new site starting from nothing.
Google treats bulk irrelevant redirects as soft 404s. A soft 404 is a URL that returns a success status but does not serve the content that was requested. When dozens of old product URLs all land on a homepage, Google reads that as the original page being gone rather than moved, so it treats the redirect as a not-found and the ranking signals from the old URL do not transfer to the new one. The redirect works for the server and fails for search.
If a page has no equivalent, it still gets a destination. Send it to the closest genuinely relevant page, or failing that, to its parent category or collection. Every legacy URL on the Luisa Paixão project landed somewhere deliberate for exactly this reason.
We created two maps for each respective domain, sending every legacy URL to its counterpart in the new market subfolder. luisa-paixao.us mapped into luisa-paixao.com/en-us/, luisa-paixao.uk into luisa-paixao.com/en-uk/.
Sort Out Where the Redirects Will Actually Live
When you are retiring whole domains rather than restructuring one, the redirects have to be handled at the domain level, and the platform you are leaving may not be able to do that cleanly once you have stopped paying for it.
We moved DNS management to Cloudflare to handle the domain-level redirects for the retiring US and UK domains reliably. This is a boring infrastructure decision that has to be made early, because discovering in launch week that your redirects have nowhere to live is a schedule problem, not a technical one.
Redirect to the Final Destination, Not Through a Chain
Old URLs should land directly on a live page returning a 200 status. Redirect chains (301 to 301 to 200) waste crawl budget, add latency for real users, and dilute the signal you are trying to preserve. This matters most when you are migrating a site that has been migrated before, because the old rules are still there waiting to stack.
While you are building the map, pull the 4xx errors from the crawl of the old site and fold them in. These are legacy broken URLs that have been sitting there collecting links and going nowhere, and a migration is the cleanest opportunity you will get to point them somewhere useful.
Verify How the Platform Actually Behaves, Not How It Is Documented
Shopify’s documentation for Markets did not match what the platform did in practice on several configurations during this project. Settings did not apply the way the docs described, and the gap only became visible by testing changes and watching the output.
Build in time for this. Any migration onto a platform feature you have not shipped before should assume the documentation is a starting point and the staging environment is the source of truth. Test the full redirect map on staging, every rule rather than a sample, and lock the URL structure before the map is built. A last-minute change to a URL pattern invalidates the map you spent two weeks building, and it will not be obvious that it did.
If you are planning a migration and want a second set of eyes on the redirect map before you launch, get in touch.
Set Up Monitoring Before You Need It
Two things are much harder to do after launch than before it.
Separate Search Console properties per market per section
On the Luisa Paixão project we created separate GSC properties so indexing and performance could be tracked per market rather than as one blended number. This is the difference between seeing that indexation is up and seeing that indexation is up in one market and flat in another. A blended view will hide a market-level failure for weeks.
Segmented reporting
We built a Looker Studio dashboard broken out by market before launch so the client had comparable reporting on day one rather than a gap in the record where the migration happened. Post-migration is exactly when stakeholders start asking questions, and answering them with a dashboard that only shows sitewide totals produces the wrong conclusions.
Telling a Normal Dip From Something That Is Broken
Thirty days after launch, organic traffic is down and someone will tell you to be patient. That advice is usually right. It is also incomplete, because patience after a migration runs on a clock most teams do not know is ticking.
Change of Address Runs for 180 Days
If you have changed domains and filed a Change of Address request in Search Console, Google forwards signals from the old site to the new one, prioritises crawling and indexing the new URLs, and prefers them when choosing canonicals. Those actions continue for 180 days, after which Google no longer recognises any relationship between the old and new sites and treats the old site as unrelated. Google also recommends maintaining the redirects themselves for at least 180 days, and longer if the old URLs are still receiving search traffic. Both points come from Google’s own Change of Address documentation.
Work Through the Checks in Order of Cost
Start with what blocks indexing outright. Staging settings ship to production more often than anyone admits. Look for a noindex tag that survived the launch and a robots.txt still carrying a disallow rule. Both take minutes to find, and they explain the most severe drops.
Then check what your canonical tags are actually pointing at, not just whether they exist. This is where the Luisa Paixão migration produced its most useful lesson, and it only surfaced after launch.
Organic traffic started dipping, so we opened Search Console. The drop was not spread across the site. It sat almost entirely in the migrated blog posts, and every one of them was canonicalizing to a different localization. The pages were live. The canonical tags were valid. Their targets were real, indexed URLs. Google had simply been told the versions we wanted ranking were not the versions worth ranking, and no alert was ever going to surface, because nothing had technically failed.
The reason it hit blog posts and not products is worth understanding, because it generalises well beyond Shopify. Product pages carried enough locale-specific signals on their own, in currency, shipping information, and other market-native elements, for the platform to treat each market version as genuinely distinct. Blog posts are written content and nothing else. Without locale-distinct signals on the page, near-identical text across markets collapses into a single preferred version, and the platform’s native handling does exactly what it is designed to do. The fix was to differentiate the blog content per locale so each market version stood on its own.
How to Confirm the Migration Worked
Loading the site in a browser tells you the pages exist. It does not tell you the migration succeeded, and the gap between those two things is where migrations quietly lose money.
Run Two Crawls
Compare the crawl of the old URLs you captured pre-migration against the new site. In the first crawl, confirm every redirect fires as expected and lands on a 200. In the second, confirm there are no 404 errors and no orphaned pages. Run both again a week later, because rules get changed during launch week.
Watch Indexation, and Watch It per Market
Submit the new sitemaps, then monitor the page indexing report weekly. Three questions matter:
- is the number of indexed URLs climbing?
- are the old URLs dropping out?
- have your top-performing pages been indexed yet?
Indexation is the leading indicator. It moves before rankings do, which makes it the earliest read on whether the move is working.
Read for Trends, Not Levels
Watch organic sessions and, more importantly, conversions. If the landing pages that used to drive conversions are recovering, the migration is working. If sessions recover but conversions do not, the problem is usually tracking rather than search, and the fix is in your analytics configuration.
Track Keyword Recovery Over Months
Rankings shift after a domain or URL structure change. If the redirect map did its job, the new pages should gradually begin ranking for the terms the old pages held. Watch the keywords that drove the most traffic before the move, and keep watching for at least three months. Recovery is rarely linear and rarely complete in six weeks.
Planning a Migration
If you are moving to a new domain, replatforming, or consolidating several storefronts into one, the work that protects your organic performance happens well before launch. Method and Metric runs migrations end to end, from the pre-migration audit and redirect map through to post-launch monitoring and reporting.
Contact us to talk through your migration.
