The new platform is live. The launch went smoothly. Traffic reports look normal for the first week. Then, around day 10, organic sessions start dropping — 15%, then 25%, then 40% below the pre-migration baseline. By the time the team diagnoses the cause, three months of recovery work are ahead. This scenario plays out in 80% of poorly executed ecommerce migrations, according to Semrush data. Not because redirects were skipped or the new platform was misconfigured, but because most development teams define “done” as the moment the new platform goes live, while Google defines it as the moment it has fully re-processed all the changes — a process that takes 3 to 6 months. That gap is where traffic disappears.
Changing ecommerce platforms is one of the highest-risk SEO interventions you can make. Not because it’s inherently complicated, but because it combines three risk factors simultaneously: massive URL structure change, technology rendering change, and frequently a content architecture change as well. When all three factors coincide in the same launch, the potential impact on organic traffic can be severe and recovery isn’t automatic.
This guide is written for teams that have already made the decision to migrate and want to execute it correctly from the start. It’s not a generic verification list: it’s a work methodology ordered by phase, with the critical points where most migrations fail and how to avoid them.
Why ecommerce migrations destroy organic traffic
The organic traffic of an online store is the accumulated result of months or years of crawling, indexation and authority signal consolidation. Google knows every URL, has assigned a value to each page based on its content, inbound links and user behavior history. When you change platforms, that map Google has of your site gets invalidated all at once.
A Semrush study analyzed 150 documented ecommerce migrations between 2022 and 2024 and found that 80% of poorly executed migrations lost between 20% and 60% of organic traffic in the first 90 days. 15% took more than 12 months to recover to pre-migration traffic levels. Only 5% completed the migration without detectable traffic loss.
The two factors that most differentiated successful migrations from failed ones were URL mapping coverage (complete coverage vs. partial mapping) and time between preparation and launch (minimum 4 weeks of preparation in successful cases vs. less than 2 weeks in failed ones).
There’s an aspect of migrations almost nobody mentions: the crawl budget impact. When Google discovers that thousands of URLs it knew now return 404 or redirect, it increases crawl frequency to process the changes. This consumes crawl budget verifying redirects instead of discovering new content. For large ecommerce sites, this process can take weeks. Meanwhile, new content on the destination platform may not be getting crawled at the necessary frequency.
Johanna Westerberg, SEO Strategy Lead at a major European payments company that has migrated multiple ecommerce platforms at scale, explained at a BrightonSEO conference in 2024: “The mistake we see repeated in every migration is treating the launch as the end of the project. The launch is the start of the most critical phase. The two weeks following go-live determine whether the migration will recover on its own or needs emergency intervention.”
Pre-migration checklist: what to audit before moving anything
Preparation is 60% of a successful migration. All work done before launch determines what can or cannot go wrong on launch day. This checklist covers the areas most frequently skipped.
Complete URL inventory. Generate a full Screaming Frog crawl before touching anything. Export all URLs with status 200, their H1 titles, meta titles, meta descriptions, canonical tags, number of internal links received and number of external backlinks if you have access to Ahrefs or Semrush. This inventory is the reference document for verifying that the migration is complete.
Don’t forget to crawl images too. An ecommerce site with 10,000 products averages 50,000 image URLs. Images with external backlinks and history of appearing in Google Images have their own SEO value. If the new platform changes image URLs without redirects, that value is lost.
Backlink analysis. Export all site backlinks with Ahrefs or Semrush. Prioritize backlinks pointing to pages with the most authority: these are the URLs whose 301 redirect is most critical. If a category page has 300 referring domains pointing to it, that specific URL cannot be left without a redirect under any circumstances.
Google Search Console data. Export the last 16 months of impressions and clicks by URL. This gives you two things: the list of URLs that generate real traffic (the most critical to map) and a traffic baseline against which to compare after launch.
New URL structure analysis. Before confirming the URL architecture in the new platform, systematically compare how each type of current URL will translate in the new one. The most problematic differences between popular platforms:
- Magento uses
/catalog/product/product-name.html, Shopify uses/products/product-name - WooCommerce uses
/product/product-name/, PrestaShop uses/en/category-name/product-name.html - Many platforms add or remove the category name from the product URL
Identify these differences before writing a single redirect.
The URL mapping process
URL mapping is the technical core of an SEO migration. It consists of creating a table that assigns each URL from the old platform to its equivalent in the new one. Without this complete mapping, 301s will be incomplete and traffic will be lost.
The correct process has four steps:
Step 1: Categorize URLs by type. Separate the inventory into: product pages, category pages, filter or faceted pages, blog or content pages, static pages (about us, contact, shipping) and image URLs. Each type has its own mapping logic.
Step 2: Automatic mapping by patterns. Most URLs in a migration follow a transformable pattern. If Magento generates /catalog/product/nike-pegasus-shoes.html and Shopify generates /products/nike-pegasus-shoes, you can map all product URLs with a regex: remove the /catalog/product/ prefix, remove the .html extension, add the /products/ prefix. This automatic mapping covers 70-80% of URLs in most migrations.
Step 3: Manual mapping for exceptions. URLs that don’t follow the general pattern (discontinued products, reorganized categories, content being merged or split) require manual mapping. You need to decide case by case where each URL should redirect.
Step 4: Map validation. Once the mapping table is complete, verify that all destination URLs exist in the new platform with status 200. A 301 redirect to a URL that returns 404 is just as bad as having no redirect.
For an ecommerce site with 10,000 products, the complete mapping including variants, categories and content pages typically produces between 25,000 and 40,000 redirect rules. The volume isn’t a technical problem for modern servers, but it is a problem for manual verification. That’s why automatic mapping by patterns is so important: it reduces manual mapping to the genuinely exceptional cases.
A practice that significantly accelerates the process is generating the mapping as a CSV file from the start. Ecommerce platforms and web servers have specific formats for bulk redirect imports: Shopify accepts CSV, Cloudflare Pages uses _redirects, Apache uses .htaccess. Keeping the mapping in a neutral format (CSV with source and destination columns) allows converting it to the destination platform’s format with a simple script.
Implementing 301 redirects
With the complete mapping in hand, the next step is implementing the redirects in the new platform. There are several levels where they can be configured, and the choice affects performance and maintainability.
Server/CDN level: The most efficient. Redirects are processed before the application executes, with minimal latency. Cloudflare, Fastly and Vercel allow managing bulk redirects at this level. For Cloudflare Pages, the _redirects file accepts thousands of rules and processes them in under 1ms. This is the recommended level.
Application level: The ecommerce platform manages redirects internally. Shopify has a native URL redirects manager with a 20,000-rule limit (expandable via API). WooCommerce manages them through plugins like Redirection. It’s functional but slower than CDN level.
Web server level: Apache with .htaccess or Nginx with configuration blocks. Works well but makes maintenance harder if redirects are managed across multiple files.
Regardless of the chosen level, there are two technical rules you must not violate. First: don’t create redirect chains. If /old-url-1/ redirects to /intermediate-url/ which redirects to /new-url/, Google will follow them but with additional crawl cost. Each redirect should go directly to the final URL. Second: verify that destination URLs respond with 200. A 301 to a 404 transfers no signals; Google ignores the redirect and treats the original URL as inaccessible.
Regarding images: while technically possible to redirect all image URLs, in practice it’s only done for images with external backlinks or Google Images history. The rest can be left without redirects, accepting that the impact is minimal. If the new image URLs are predictable (same file name, different directory), a regex pattern mapping is sufficient.
To understand the complete technical architecture context of your store, the technical SEO guide for ecommerce covers how to structure canonical tags, sitemaps and crawl budget coherently with the new platform.
Testing before launch: the critical 48 hours
The testing period before launch is where most migrations rush and where most errors are made. The staging environment (the new platform’s test environment) must have restricted access to prevent Google from indexing it before launch, but must be fully functional for tests.
Tests that cannot be skipped:
Redirect testing with a representative sample. You can’t manually test 30,000 redirects, but you can test a structured sample: the 100 URLs with the most external backlinks, the 50 pages with the most organic traffic, a random sample of 200 product URLs and the URLs of all main categories. If the sample works correctly, the pattern likely works for the rest.
Canonical tag testing on the new platform. Staging must have canonical tags configured correctly from the start. Use Screaming Frog to crawl the staging and export the canonicals. Verify that all product pages have self-referencing canonical and that variants point to the base product according to your strategy. This point has its own detailed resource: canonical tags in ecommerce.
Page speed test. Compare Core Web Vitals on staging with those of the current platform. A migration that improves content but worsens LCP can lose positions even if the redirects are perfect. Use PageSpeed Insights on product pages, category pages and the homepage. If staging is slower, investigate the cause before launching.
XML sitemap test. Generate the new platform’s sitemap on staging and verify that it includes all URLs that should be indexed and excludes those that shouldn’t (variants with external canonical, filter pages with no SEO value, pagination pages without self-referencing canonical). Compare the URL count with the current sitemap. A large difference (more than 20%) requires investigation.
robots.txt test. Verify that the staging robots.txt has no blocking rules that shouldn’t be in production. It’s a classic error: staging is configured with Disallow: / to prevent indexation during development, and that file accidentally reaches production.
Launch day protocol
The launch of an ecommerce migration isn’t a single event: it’s a sequence of actions that must be completed in a specific order within a controlled time window.
T-1 hour: Final crawl of the current platform. Generate a Screaming Frog crawl of the current production platform right before launching. This is the final reference point. If something goes wrong and you need to roll back, this crawl documents the exact state to return to.
T=0: DNS switch and activation. When DNS is changed or the new platform is activated, redirects must already be fully configured. There is no valid sequence where the platform activates before the redirects are in place.
T+15 minutes: Critical URL verification. Manually open the 20 most important URLs in your store (homepage, main categories, flagship products) and verify they load correctly on the new platform. Also verify that 5 old URLs of each type redirect correctly to the new ones.
T+1 hour: Sitemap submission in Google Search Console. Access Search Console, remove the old sitemap and add the new one. This explicitly indicates to Google that there’s a new sitemap to process. It’s also the time to use the Change of Address tool if the domain has changed.
T+2 hours: First post-launch crawl. Run a full crawl of the new production platform with Screaming Frog. Export all status codes and canonical tags. Compare with the staging crawl: any unexpected difference is an alarm signal.
T+24 hours: Search Console review. Check coverage errors in Google Search Console. Crawl errors appearing in the first 24 hours are the most urgent: they may indicate that the new platform has response problems or that redirects aren’t working for Google’s bot.
Post-migration monitoring: the first 60 days
The first 60 days after a migration are the most critical period and the most frequently underestimated. Google needs time to process all changes, re-crawl URLs, evaluate redirects and recalculate authority signals. This process isn’t instantaneous or linear: there are normal fluctuations that don’t indicate a problem and drops that do require intervention.
Weeks 1-2: Normal fluctuations. It’s common to see traffic drops of 10-20% in the first days post-migration. Google is processing redirects and some rankings fluctuate while the algorithm re-evaluates URLs. Don’t intervene based solely on the first 7 days of data.
Weeks 3-4: First real signal. If at 3-4 weeks organic traffic has dropped more than 30% against the pre-migration baseline, there’s a problem requiring diagnosis. First places to look: 404 errors in Search Console, incorrect canonical tags, robots.txt blocking sections, and critical pages not included in the sitemap.
Weeks 5-8: Progressive recovery. A well-executed migration starts recovering traffic between weeks 4 and 8. The speed of recovery depends on site size and the crawl frequency Google applies. Large ecommerce sites with high domain authority recover faster.
Semrush data on post-migration recovery time shows that full recovery takes between 3 and 6 months even in well-executed migrations. This data is important for managing internal expectations: a traffic drop in month 2 doesn’t mean the migration has failed.
The monitoring dashboard should include: daily organic traffic (vs. same period last year), positions for the top 50 keywords (vs. pre-migration baseline), Search Console coverage errors (404, soft 404, redirect errors) and total indexed pages in Search Console.
A practical tool for detecting redirect problems at scale is Screaming Frog in “spider” mode with the “follow redirects” option disabled. This generates a list of all URLs returning a redirect instead of 200, which can reveal circular redirects or chains that weren’t visible during testing.
Recovery strategies if traffic drops
Despite best preparation, some migrations result in traffic drops exceeding expectations. When this happens, the response matters as much as the initial preparation.
Diagnose before acting. A post-migration traffic drop can have multiple causes that are resolved differently. Before changing anything, confirm what the real problem is. Most frequent causes by probability:
- Critical URLs returning 404 (missing redirect)
- Incorrect canonical tags consolidating signals onto the wrong pages
- Deteriorated page speed (worse Core Web Vitals than previous platform)
- Content that changed during migration (rewritten product descriptions, merged categories)
- Incomplete sitemaps or sitemaps with incorrect URLs
Prioritize by traffic impact. Export from Search Console the URLs with the greatest impression loss in the last 30 days. These are the pages to intervene on first. Verify their status code, canonical and sitemap presence.
Don’t make mass changes without data. The instinctive reaction to a traffic drop is aggressive intervention: changing structures, adding content, modifying redirects. Each additional change adds more variability to a system already in the process of stabilizing. Act only when you have clear evidence of a specific problem.
If traffic continues dropping after week 8 without recovery signals, consider running a comparison crawl between the old platform (if you maintain access) and the new one to identify structural differences you hadn’t detected. Also consider checking whether the new platform has JavaScript rendering problems that may be preventing Google from processing content correctly.
You can also review the duplicate content implications that the migration may have introduced in the resource on duplicate content in ecommerce, as migrations are one of the main moments when this type of problem is introduced.
Migrating an ecommerce platform with zero organic traffic loss is achievable. It’s not the norm, but it’s possible with sufficient preparation and a disciplined execution protocol. The difference between migrations that go well and those that don’t, in most cases, isn’t technical: it’s about planning and the time invested in the preparation phase.
Complete URL mapping before touching anything, thorough staging testing, an orderly launch protocol and daily monitoring for the first 60 days are the four practices that most consistently separate successful migrations from failed ones. None of the four is hard to implement. All require time and attention that many teams don’t allocate because they’re focused on launching as quickly as possible.
If you’re in the planning phase of a migration, the most practical recommendation is this: double the time you think you need for the preparation phase. What seems excessive in planning turns out to be exactly what’s needed when real problems appear. And they always appear.
To complete your ecommerce technical strategy, the starting point is the technical SEO guide for online stores, which provides the general framework within which platform migration is a specific intervention.
FAQ about platform migration ecommerce SEO
When is the best time to migrate an online store?
The best time is during a low-seasonality period for your business. For fashion, after sale periods; for toys, after the holiday season. Avoid migrating on Black Friday, the holiday period or any sales peak. You need at least 4-6 weeks of preparation before the migration and 4-8 weeks of post-launch monitoring. A total 3-month window with reduced traffic pressure is the safest scenario.
Should I change URLs during a migration?
Ideally keep exactly the same URLs. Every URL that changes needs a 301 redirect, and the more redirects, the higher the risk of errors. If URL changes are unavoidable because the new platform uses a different structure, map ALL old URLs to new ones before launching. An ecommerce site with 10,000 products can have 30,000+ URLs including variants, categories and filters.
What tools do I need to monitor a migration?
Three indispensable tools: Google Search Console to monitor indexation, crawl errors and impression losses; Screaming Frog to run a full crawl pre and post-migration comparing URLs, status codes and canonical tags; and a rank tracking tool (Semrush, Ahrefs or Sistrix) to track daily position evolution for your main keywords during the first 60 days.
Can I migrate in phases rather than all at once?
Phased migrations are possible but technically more complex. They require both platforms running simultaneously with a reverse proxy directing traffic to one or the other based on the URL. This is an option for ecommerce sites with more than 50,000 products where a full migration carries too much risk. The downside is that the coexistence phase generates complexity in canonical tags, sitemaps and data analysis.