In short
The move itself does not. What causes damage is losing URLs, losing page content, losing internal links, or launching a slower site, and all four are avoidable with preparation. Expect a short period of fluctuation while search engines recrawl and reconcile the new structure, typically a few weeks. A drop that persists past that is a defect, and it almost always traces back to a redirect that was never mapped or a page whose content was quietly shortened during the rebuild.
The damage comes from what gets lost, not from the platform
Search engines have no opinion about which platform runs your store. They see URLs, content, links and speed. A migration that preserves all four is invisible to them beyond the recrawling period.
So the risk register is short and specific. URLs that change without a redirect. Content that was on the old page and is not on the new one. Internal links that no longer exist because the navigation or related-product blocks were simplified. And a new site that is slower than the old one, which is surprisingly common when a design is heavier than the one it replaced.
A fifth, less common but severe, is a staging site's blocking directives shipping to production. A live store that tells search engines not to index it will disappear, and it can go unnoticed for days because nothing on the site looks wrong.
Everything else people worry about during a migration is downstream of those five. Get them right and the migration is a non-event for organic traffic.
The redirect map is the artefact the project turns on
Start it by crawling the existing site and exporting every URL that has ever received a visit or a link, not just the ones currently in the navigation. Pull the list from your analytics, your server logs, your sitemap and Search Console, and combine them, because each source misses something the others catch.
Then map every one of those to its closest equivalent on the new site. Product to the same product, category to the same category, article to the same article. Where a page genuinely has no equivalent, map it to the nearest useful parent rather than to the home page, since a mass redirect to the home page is treated as a soft error.
Watch the patterns that change silently. Product URLs that included a category path on the old platform, pagination parameters, filter URLs that earned links, index pages for brands, and any URL with an uppercase letter or a trailing slash. These are where the gaps hide.
Test the map before launch on a staging environment, and test it again within an hour of going live. Then monitor for a month, because the errors that matter show up as crawl errors rather than as anything a visitor reports.
What else has to survive the move
Page content, in full. A rebuild is often an opportunity to tidy, and tidying frequently means the category description, the specification table or the frequently asked questions disappear. Those were part of why the page ranked. Move the content first and redesign it afterwards.
Titles and headings. Keep them unless you have a specific reason to change one, and change them after the migration has settled rather than during it, so that any movement has a single explanation.
Structured data. Product markup carrying price, availability and reviews affects how listings appear, and platforms differ in what they output by default. Verify it on the new site rather than assuming it came across.
Internal linking. Related products, breadcrumbs, category cross-links and any editorial links from articles into collections all pass signals and drive crawling. A new theme with a cleaner design often has far fewer of them.
And speed. Measure the old site's field performance before you launch so you have something to compare against, because a new site that feels fast to the team on a fast connection can be slower where it counts.
Expect a dip, and know what a normal one looks like
A normal migration produces some fluctuation for a few weeks as pages are recrawled and the redirects are processed. Rankings wobble, impressions move, and things settle back.
What is not normal is a sustained decline past a month, a large fall concentrated in one section of the site, or a drop in the number of pages indexed. Each of those points at a specific fault rather than at the recrawling process.
Monitor the right things during that window: indexed page counts, crawl errors, impressions and clicks by page type rather than in total, and the performance of your top fifty landing pages individually. A total figure hides a category section that has vanished.
And keep the old site's data. Access to the previous analytics, the old crawl and the old rankings is what lets you diagnose a problem in an afternoon instead of guessing. Store an export before the old platform is switched off.
Pre-launch checklist for organic revenue
- URL inventory
- From analytics, logs, sitemap and Search Console combined
- Redirect map
- Every old URL to its closest equivalent, tested
- Content parity
- Category and product copy moved before redesign
- Structured data
- Verified on the new templates, not assumed
- Internal links
- Breadcrumbs, related products and editorial links preserved
- Indexing directives
- Staging blocks removed, checked after launch
- Performance baseline
- Old site measured so the new one can be compared
An illustrative checklist. The first two rows prevent most migration damage, and the last row is what makes any post-launch argument about speed resolvable with data.
Related questions
How long should I keep the redirects in place?
Permanently, as far as practical. Redirects continue to serve links and bookmarks long after search engines have updated, and removing them years later reintroduces errors on pages that still receive traffic. Keep them, and audit them occasionally to remove chains.
Should I redesign and migrate at the same time?
It is more efficient and it makes diagnosis harder, because any traffic change has two possible causes. If organic traffic is important to the business, the safer sequence is to migrate with the design as close as practical, then redesign once the new platform has settled.
What is the first thing to check if traffic falls after launch?
Whether the site is indexable at all, then the redirect map. Confirm no blocking directive shipped to production, then take your top landing pages from the old site and request each one to see whether it resolves to the right new page rather than to an error or the home page.