Most replatforming projects treat SEO as a launch-week checklist item. That is why the traffic graph so often looks like a cliff.
The work that protects organic revenue happens during discovery and build, not at cutover. By launch day the redirect map should already be written, tested and reviewed. If you are writing redirects the week you go live, you have already lost some of what you were trying to keep.
TL;DR: Inventory every URL that exists, not just the ones in your sitemap. Map each one deliberately. Test that your redirect rules actually match the URLs they are supposed to match, because the commonest failure is a rule that looks right and silently does nothing. Capture a ranking baseline before you cut over, or you will not be able to tell recovery from decline.
The Three Things That Actually Go Wrong
Across the migrations we have run and the ones we have been called in to repair, losses almost always trace to one of three causes.
1. URLs nobody knew existed. Your sitemap lists the URLs you know about. Search engines index the ones that exist. Those sets are never the same. Old campaign landing pages, paginated category paths, parameter variants, pages from a CMS you replaced two platforms ago, PDFs. They have links pointing at them and they rank for things.
2. Redirect rules that silently fail. Not rules that error. Rules that return a 404 while looking completely correct in the config file. This is the most expensive category because nothing alerts you.
3. Changing everything at once. New URLs, new templates, new copy, new internal linking, all in one release. When traffic drops you have no way to isolate the cause, so you cannot fix it.
Step 1: Inventory Every URL, From Four Sources
One source is never enough. Pull all four and deduplicate:
- Search Console. Every URL that has received an impression over the last 16 months. This catches ranking pages your CMS has forgotten.
- Server logs or analytics. Every URL that has actually been requested, which catches pages with inbound links but no rankings.
- A full crawl of the live site. What is actually reachable today.
- The platform's own export. Products, categories, CMS pages, including ones that are disabled but still resolve.
Then sort by impressions and inbound links, because the mapping effort should follow the value. On the QC Supply migration this exercise surfaced more than 10,000 indexed URLs, carrying Magento path structures with .html suffixes and layered navigation parameters that no simple export would have produced.
Step 2: Map Deliberately, Never to the Homepage
Every old URL needs a decision, and there are only four valid ones:
| Decision | When |
|---|---|
| 301 to the direct equivalent | The page exists on the new platform. The default for most URLs. |
| 301 to the closest parent | The specific page is gone but its category or hub survives. |
| Let it 404 | No successor, no traffic, no links. A clean 404 is better than a misleading redirect. |
| Rebuild it | The page earns enough traffic or links to justify recreating it. |
A bulk redirect of everything to the homepage is the one genuinely destructive option. Search engines treat it as a soft 404 and it passes essentially nothing, while also hiding the problem from you because nothing 404s.
Step 3: The Rules That Look Right and Do Nothing
This is the section worth the most money, and it is the one generic migration guides skip.
Redirect rules are pattern matches. A pattern that does not match produces no error, no warning and no log entry. It produces a 404 that looks exactly like a URL you forgot to map, and you will not find it unless you test for it.
A concrete example from our own infrastructure. We run trailing-slash URLs, and a catch-all rule written as /foo/:path* does not match a URL ending in a slash. Both variants have to exist:
Every catch-all needs the no-slash and the trailing-slash form. One without the other silently 404s half your traffic.
We learned this the expensive way: 183 indexed legacy URLs were quietly returning 404s because the catch-all rules had only been written in the no-slash form. Nothing in the config looked wrong. The rules were there. They simply never matched.
Three more failure modes worth testing explicitly:
- Redirect chains. Old URL to interim URL to final URL. Each hop loses a little and slows crawling. Every rule should point at the final destination, not at another rule.
- Ordering. A broad catch-all placed above a specific rule swallows it. We once broke a brand-new service page on its first deploy because a catch-all for that path prefix was matching before the real page could serve.
- Case and parameter variants. Uppercase paths, trailing query strings and index file variants all resolve separately unless you handle them.
Test the rules against the real URL list. Take the inventory from step 1, request every URL against the staging environment, and assert on the status code and the final destination. This is a script, not a spot check, and it is the single highest-value hour in the whole project.
Step 4: Preserve What Was Actually Earning
Redirects preserve the address. They do not preserve the reason the page ranked.
For your top pages by organic revenue, carry across the title and meta description, the heading structure, the body copy in full rather than a shortened rewrite, structured data, and the internal links pointing at the page. That last one is the most commonly dropped: a page that had fifteen internal links on the old site and three on the new one has been demoted by your own architecture, regardless of redirects.
If the new design genuinely requires less copy, launch with the old copy and change it afterwards, separately, so the effect is measurable.
Step 5: Cutover
- Capture the baseline first. Rankings, impressions and clicks for your top pages and queries, exported and saved before anything changes. Without this you are guessing for the next three months.
- Check the staging environment is not indexable, and that the production site is. Launching with a leftover noindex is a genuinely common and completely avoidable disaster.
- Submit the new sitemap and keep the old URLs out of it. Redirected URLs do not belong in a sitemap.
- Verify canonical tags and the www and non-www, http and https variants all resolve in one hop to the canonical form.
- Do not launch on a Friday and not in your peak season.
Step 6: Monitor, and Know What Normal Looks Like
A dip is expected. A cliff is not.
Normal: 10 to 20% down for two to six weeks, then recovery as search engines recrawl and reassign signals. Larger sites take longer because recrawling takes longer.
Not normal: an immediate drop of more than half, a steady decline that never turns, or indexed page counts that keep falling after week two.
Watch daily for the first fortnight: crawl errors and 404s, indexed page count, and rankings for your top revenue pages. When a 404 appears, fix the rule rather than adding a one-off redirect, because a rule that missed once is usually missing a whole pattern.
One caution from experience: segment by country before you panic or celebrate. Site-wide averages mix real buyers with rank-tracking bots and scrapers, which can mask a real decline in your actual market or invent a recovery that is not there.
Platform Notes
Magento and Adobe Commerce. Expect deep category paths, .html suffixes, and layered navigation parameters that multiply a single category into hundreds of indexed variants. Pattern-based rules are essential; a one-to-one spreadsheet will not scale. Our Magento to Shopify migration service and the cost breakdown cover the wider project.
BigCommerce. Both directions carry the same trap: product and category URL conventions differ enough from Shopify's that direct equivalents often do not exist, so mapping has to be rule-based. We run migrations to BigCommerce and from BigCommerce to Shopify, and the right direction depends on the business rather than the platform. Our comparison of Shopify Plus and BigCommerce Enterprise covers that decision.
B2B stores. Customer-specific catalogs mean a URL can return different content to different buyers, and logged-out crawlers see the public view. Decide deliberately what is indexable. Our B2B implementation guide covers the surrounding requirements work.
Planning a Replatform?
If you are scoping a migration and organic revenue matters, the redirect map and the URL inventory should be in the project plan from week one, not the week of launch. Bring us your current platform, your indexed URL count and your top organic pages, and we will tell you where the risk actually sits. Explore our platform migration services or talk to us directly.
Frequently Asked Questions
How much organic traffic do you lose in a replatform?
A well-executed migration should see a dip of roughly 10 to 20% for two to six weeks while search engines recrawl and reassign signals, then recovery. Losses that are larger or that do not recover usually trace to one of three causes: URLs that were never mapped, redirect rules that silently do not match, or page content and internal linking that changed at the same time as the URLs.
Should I redirect old URLs to the homepage?
No. A bulk redirect to the homepage is treated as a soft 404 and passes essentially nothing. Map every old URL to its closest equivalent. Where no equivalent exists, redirect to the most relevant category or hub page, and only let a URL 404 when it genuinely has no successor and no traffic or links.
How long should redirects stay in place?
Permanently, in practice. Search engines drop them from the index over months, but inbound links from other sites do not expire. Our own redirect table still carries rules for URL patterns retired years ago because those paths still receive real traffic from third-party sites and directories.
Should I change URLs and redesign at the same time?
Avoid it if you can. When URLs, templates, content and internal linking all change together and traffic drops, you cannot tell which change caused it. If both must happen, at least instrument them so you can separate the effects, and expect diagnosis to be harder.
What should I monitor after launch?
Crawl stats and 404s daily for the first two weeks, indexed page counts weekly, and rankings for your top revenue pages against a pre-migration baseline you captured before cutover. The baseline is the part teams forget, and without it you cannot tell recovery from decline.
Does migration SEO differ between platforms?
The principles are identical. What differs is the shape of the old URLs and the redirect tooling. Magento and Adobe Commerce tend to produce deep category paths, .html suffixes and layered navigation parameters. BigCommerce and Shopify both impose their own path conventions for products and collections, which means a one-to-one mapping is rarely possible and rules have to be pattern-based.