Problem
Organic traffic dropped after platform migration: how to fix it
A drop after a replatform is normal for a short period and permanent only when something structural was lost. The three things that cause lasting damage are redirects that do not resolve to the equivalent page, crawling that is still blocked from launch day, and content or internal links that did not make the move. Check those three before anything else, because each one is recoverable and each one gets harder to fix the longer it runs.
By CartKernel · Last reviewed 2026-09-07
Does this look familiar?
- Organic sessions fell within days of launch and have not recovered
- Search Console shows a spike in not found errors on the old address pattern
- Rankings for category terms fell while brand searches held
- Indexed page count dropped sharply and keeps falling
- The old sitemap is still submitted and full of addresses that no longer exist
- Product pages load correctly for a visitor but return a redirect chain when tested
Causes, ranked
Why it happens, most common first
Check them in this order. The first two account for most cases we open.
- most common
Redirects are missing, chained or pointed at the wrong page
A redirect map that sends every old address to the homepage, or that passes through several hops, loses most of the value the old page held. Missing redirects for older categories, retired products and blog content are the usual gaps, because those were not on the migration checklist.
- most common
Crawling or indexing is still blocked from the build
A robots file copied from staging, an indexing directive left on a template, or password protection on part of the site will remove pages from search within weeks. This is the fastest cause to check and the fastest to fix, so it is always worth ruling out first.
- common
Content did not survive the move
Category copy, buying guides, specification tables, reviews and metadata often live in fields the new platform does not have, and they quietly do not migrate. The pages exist and rank for less, because most of what made them useful is gone.
- common
Internal linking changed shape
A new theme with a different navigation, fewer collections or shallower related product modules redistributes internal signals across the site. Pages that were well linked become deep, and their rankings follow the links rather than the content.
- common
The URL structure changed more than it needed to
Every changed address depends on a redirect being right. Migrations that also reorganise categories, rename products and introduce new path patterns change thousands of addresses at once, which multiplies the chance of gaps and lengthens recovery.
- occasional
Page experience got worse on the new stack
Heavier themes, new app scripts and unoptimised images can slow the site relative to the previous build. It rarely causes a large drop on its own, but it slows recovery and compounds whatever else is wrong.
- occasional
Structured data and international annotations were not rebuilt
Product markup, breadcrumbs and language or region annotations are often generated by the previous platform and have to be recreated. Losing them costs rich presentation in results and, for multi region stores, causes the wrong version to be shown.
The fix
In this order
Each step is something you can do today. Do them in sequence; skipping ahead is how a review fails twice.
Prevent it next time
- Build and test the redirect map on staging before launch, using the old site's real address list
- Keep the previous URL structure unless there is a specific reason to change it
- Export category copy, metadata and reviews before decommissioning the old platform
- Crawl the new site on the day of launch and compare it against the last crawl of the old one
Confirm the site can be crawled and indexed
Read the live robots file, check response headers and page heads on each template for indexing directives, and confirm no environment protection remains. Fix anything found here first, because nothing else matters while pages are excluded.
Rebuild the redirect map from real data
Take the old site's addresses from analytics, Search Console and the last crawl before launch, then map each to its closest equivalent on the new site. Send every address to the specific page a visitor wanted, never to the homepage as a catch all.
Remove redirect chains and loops
Crawl the old address list and check each resolves in a single hop to a live page. Collapse chains that pass through intermediate addresses, and fix any that end in a not found or a redirect back to where they started.
Restore the content that did not migrate
Compare the old and new versions of your highest traffic categories and products, and put back missing copy, specifications, reviews, images, titles and descriptions. Prioritise by the traffic those pages used to receive rather than working alphabetically.
Rebuild internal linking deliberately
Restore the navigation depth, category cross links and related product modules the previous site had, or better. Check that the pages that used to earn the most organic traffic are still within a few clicks of the homepage.
Resubmit sitemaps and use the change of address tool if the domain moved
Generate fresh sitemaps containing only live canonical addresses and submit them. If the domain itself changed, use the change of address process in Search Console and keep both properties verified while the move settles.
Recreate structured data and regional annotations
Add product, breadcrumb and organisation markup that matches what is visible on the new pages, and rebuild language and region annotations so each market points at the correct address in both directions.
Track recovery against the right baseline
Compare organic clicks and impressions by page type against the same period last year, not against the week before launch. Note the launch date in your reporting so everyone reads the same timeline, and expect several months for a large catalogue to settle.
When to get help
Ask for help when the drop has persisted past a couple of months, when the old platform has already been decommissioned and the address list is incomplete, or when the migration also changed the category structure so mapping is a judgement exercise rather than a lookup. Recovering from an incomplete redirect map after the source data is gone means reconstructing addresses from archives, backlink data and log files, which is slow work but usually returns most of what was lost.
Free. We reply within one business day.
How long should recovery take after a well executed migration?
For a small catalogue with matching URLs, a few weeks. For a large store where addresses changed, expect a dip for the first month and a return over three to six months as pages are recrawled. A drop still deepening after two months is a signal that something structural is unresolved.
Is it too late to add redirects months after launch?
No. Adding them later is less effective than having them at launch, but old addresses continue to be requested and linked for a long time, and the redirect still passes signals when it resolves. Prioritise the addresses that had the most traffic and the most external links.
Should old addresses redirect to the homepage if there is no equivalent?
Only as a last resort. Send them to the closest category or a genuinely relevant replacement product, which is more useful for the visitor and preserves more relevance. Where nothing relevant exists, returning a not found page with good navigation is more honest than a homepage redirect.
Do I need to keep the old site running during a migration?
You need the old site's data, not the old site. Export the full address list, page content, metadata, reviews and analytics history before decommissioning. Keeping the old environment available on a staging domain for a few weeks makes comparison work far easier.
Related problems, answers and terms
Stop the leak.
A free Growth Analysis finds what is broken and ranks it by the revenue it costs you.