Replatforming an Online Store Without Losing Revenue
How to replatform an ecommerce store without losing organic rankings: redirect mapping, pre-migration exports, and 30-day monitoring.
Replatforming an online store rarely fails because the new platform is worse — it fails because nobody mapped every old URL to a new one before launch. The most reliable way to migrate without losing revenue is to treat the migration as an SEO project first and a development project second: crawl and export the full existing site before anything changes, build a complete redirect map covering every category, product and content URL, and hold launch until that map is tested and QA’d. Miss this step and even a technically excellent new store bleeds organic traffic for months while rankings that took years to build reset to zero.
Key takeaway
- Most replatforming SEO losses trace back to one cause: missing or incorrect 301 redirects for old URLs, not the new platform itself.
- Crawl and archive your entire current site — URLs, titles, meta descriptions, structured data — before development starts, not after.
- Build the redirect map as a living spreadsheet the whole team can reference, and test every redirect before the new site goes live, not after.
- Budget a 4-8 week post-launch monitoring window; a temporary ranking dip is normal, a sustained one usually points to an unmapped redirect or a technical regression.
Why replatforms lose organic revenue, specifically
Every replatform touches the same handful of signals Google uses to understand your site: URL structure, internal linking, page speed, structured data and content. Change any of them without preserving what worked, and you’re asking Google to re-evaluate pages it already trusted. The failure pattern we see most often isn’t a single catastrophic mistake — it’s a stack of small ones: a product category URL structure that changed from /category/shoes/ to /shop/shoes-c1/ with no redirect, structured data that worked on the old product schema implementation but wasn’t rebuilt on the new theme, and canonical tags that got left pointing at staging URLs after go-live. Individually each is fixable in an afternoon. Left unmonitored for six weeks, together they can cost a store a meaningful share of its organic sessions.
Pre-migration: what to export before anything changes
Before a single line of the new site gets built, crawl the existing store with a tool like Screaming Frog and export the full URL list, along with current rankings from Search Console, your XML sitemap, and every piece of structured data currently live. This becomes your source of truth. Also pull your top-performing pages by organic sessions and conversions from analytics — these are the pages where a redirect mistake does the most damage, so they get manually verified rather than trusted to a bulk redirect rule.
- Full site crawl exported to CSV — every category, product, blog and utility page URL.
- Search Console performance export — which URLs currently get impressions and clicks, and for which queries.
- Current XML sitemap and robots.txt saved as a reference.
- Structured data audit — what schema types are implemented on category, product and article templates today.
- Top 100 pages by organic traffic, flagged for manual redirect verification rather than automated mapping alone.
Building the redirect map without losing link equity
A redirect map is a spreadsheet with old URL, new URL, redirect type and status columns — and it needs to cover every URL from the crawl, not just the obvious ones. Category and product pages are usually mapped one-to-one. The harder cases are discontinued products, which should redirect to the closest matching category or a genuine substitute rather than the homepage, and old blog content, which often gets forgotten entirely during a platform-focused migration. A blanket redirect-everything-to-homepage approach is a common shortcut that actively damages rankings, since it tells Google none of the old content has a real replacement, which weakens the relevance signal a 301 is supposed to carry.
| URL type | Redirect target | Common mistake to avoid |
|---|---|---|
| Active product pages | Matching new product URL | Redirecting to category page loses product-specific ranking signal |
| Discontinued products | Closest matching category or genuine substitute product | Redirecting to homepage instead of a relevant page |
| Category and subcategory pages | Matching new category URL | Flattening subcategories into one parent without a plan for lost specificity |
| Blog and content pages | Matching new content URL, or closest topical match | Forgetting content entirely because focus stays on commerce templates |
| Filtered/faceted URLs | Usually not redirected — replaced by fresh canonical rules on the new site | Trying to 1:1 redirect thousands of old parameter combinations |
Platform-specific technical gaps to check
The platform you’re migrating to matters. If you’re moving toward or between Shopify and WooCommerce, review our comparison of Shopify vs WooCommerce for SEO before finalising the build, since URL structure conventions, native redirect tooling and structured data defaults differ meaningfully between the two. Each platform also has default behaviours that can quietly work against you: some auto-generate faceted navigation URLs with no canonical control out of the box, some strip custom meta descriptions on import, and some change your product variant URL pattern in ways that break existing rankings if you don’t intervene. Confirm these defaults during the build phase, not after launch, when they’re far more expensive to fix.
12-20 weeks
A typical mid-market ecommerce replatform runs three to five months from planning through post-launch stabilisation, depending on catalogue size and how many integrations need to be rebuilt. SEO mapping and QA should run in parallel with development, not be squeezed into the final week before launch.
Source — typical mid-market ecommerce replatforming project timelines
Launch day and the first 30 days
On launch day, submit the new XML sitemap in Search Console, verify a sample of redirects across every URL type in the map (not just the homepage and a couple of categories), and check that the new robots.txt isn’t accidentally blocking the entire site — a surprisingly common last-minute mistake when a staging robots.txt file gets pushed to production by accident. For the following month, monitor Search Console daily for crawl errors and sudden drops in indexed pages, and compare weekly organic sessions against the pre-migration baseline rather than reacting to daily fluctuations, which are normal during re-crawling. Page speed and Core Web Vitals often shift during a replatform too, for better or worse, and are worth checking in the same window since they affect both rankings and conversion rate.
Staging environment testing before you commit
Redirect maps should be tested against a staging or password-protected version of the new site before the DNS switch, not after. Pull a random sample of 50-100 URLs across every page type in your map — not just the ones you’re confident about — and manually verify each one resolves to the correct destination with a single 301, not a redirect chain. Redirect chains, where an old URL bounces through two or three intermediate redirects before reaching the final page, are common when a redirect map gets built in layers by different people, and each extra hop in the chain adds latency and, in extreme cases, can cause Google to stop following the chain altogether. This is also the point to confirm the staging environment itself is blocked from indexing — a staging site that gets crawled and indexed alongside the live site creates a duplicate content problem that’s entirely avoidable with a simple noindex tag or HTTP authentication.
Keep the old site’s server or a full backup accessible for at least a few weeks after cutover. If Search Console shows a serious, unexpected regression in the first days after launch, having the ability to quickly compare against the previous live version — rather than reconstructing it from memory — cuts diagnosis time from days to hours.
Signs the migration is going wrong (and what each one usually means)
- A sharp drop in indexed page count in Search Console — usually a robots.txt or noindex tag issue on the new site.
- Rankings for specific products vanish while categories hold — check whether product URLs redirected correctly or fell through to a generic category redirect.
- Organic traffic drops but rankings look stable — often a Core Web Vitals or mobile usability regression affecting click-through and conversion rather than rankings directly.
- Search Console shows a spike in 404 errors — a gap in the redirect map; cross-reference against the original crawl export to find what wasn’t covered.
- Rich results disappear from search listings — structured data wasn’t rebuilt correctly on the new templates; verify with Google’s Rich Results Test.
Frequently asked questions
How much organic traffic drop is normal during a replatform?
Some short-term fluctuation while Google re-crawls the new site is normal and usually recovers within a few weeks. A drop that persists past 4-6 weeks, or one concentrated in specific page types, typically points to a redirect gap or technical regression rather than a normal adjustment period.
Should I redirect discontinued product pages to the homepage?
No. Redirect discontinued products to the closest matching category or a genuine substitute product instead. Homepage redirects for specific, non-relevant content weaken the relevance signal Google uses to trust a 301, and can be treated more like a soft 404 at scale.
Do I need to rebuild structured data from scratch on the new platform?
Usually yes, at least partially. Structured data implementations rarely transfer automatically between platforms or themes. Audit what schema types were live before migration and verify each one renders correctly on the new templates using Google’s Rich Results Test before launch.
How long should I monitor the site after launch?
Plan for at least 30 days of close daily monitoring in Search Console and analytics, with a lighter-touch review continuing for two to three months. Most redirect and indexing issues surface within the first month, but ranking recovery for competitive terms can take longer.
Can I migrate and redesign the site at the same time?
You can, but it makes diagnosing SEO issues afterward harder, since a traffic drop could stem from URL changes, content changes, or design changes. Where possible, separate platform migration from major content or UX redesign into two phases so problems are easier to isolate.
The bottom line
A replatform doesn’t have to cost you organic revenue — the stores that come through clean are the ones that treat redirect mapping and technical QA as core project deliverables, not an afterthought squeezed in before launch. Start the crawl and export early, build the redirect map as a living document the whole team owns, and hold launch until it’s tested. This sits alongside the wider fundamentals in our ecommerce SEO guide.
Planning a platform migration and want a second set of eyes on the redirect map before launch? See our ecommerce SEO plans.
