How to Replatform Without Losing the Traffic You Paid For
Why migrations go wrong at the same point every time
Replatforming is one of the few projects where a marketing team can lose a year of accumulated search performance in an afternoon, and it happens often enough that most practitioners have a story about it. The failure is almost never a surprise in hindsight: the information architecture changed, nobody mapped the old addresses to the new ones, and the equity landed on error pages.
The structural reason is sequencing. Search requirements arrive at the end of a build, as a checklist handed to whoever is left, by which point the structure is agreed and the budget is spent. Everything in this piece is about moving that conversation to the beginning, where it is a design input rather than a complaint.
Migrations fail in a familiar way. Design signs off, the build goes well, launch day passes quietly, and six weeks later organic revenue is down a third and nobody can say exactly when it started.
It is a mapping exercise first
Before anything is designed, you need every indexed URL and a decision for each one. Not a rule that generates decisions, a decision. Automated redirect maps are where collapses come from, because they are plausible enough that nobody audits them.
The sequence that works
- Inventory indexed URLs from Search Console, analytics and a crawl, combined
- Map each to a destination, or mark it deliberately for retirement
- Preserve internal linking structure, not just the destination pages
- Keep titles, headings and schema unless there is a reason to change them
- Stage the site and crawl the staging environment before launch
- Verify redirects after deploy by crawling the old URL list against production
- Watch coverage and log files daily for the first fortnight
The part that gets skipped
Step six. Everyone writes the redirect map, few crawl the old list against the live site afterwards. That single check catches chains, loops and silent 404s in an afternoon, and it is the difference between a quiet launch and a quarter spent recovering.
The two weeks before launch decide everything
A replatform loses traffic for one of three reasons, and all three are decided before the site goes live. Addresses change without a map, so equity lands on error pages. Templates change so the content that earned the position is no longer on the page. Or the new build renders through JavaScript in a way the old one did not, so pages that were readable become blank to a crawler. None of these is discovered by looking at the design.
The useful preparation is a frozen inventory: every indexable address on the old site, its impressions and clicks over the last twelve months, its primary query, and the words on the page that answer that query. Freeze it two weeks before launch and nothing can be lost silently, because you can prove afterwards what existed and what it earned.
The order that keeps traffic
- Export the inventory and sort by clicks, because that is the order you will fix problems in.
- Map every old address to exactly one new address, and reject any map with a many-to-one row unless the merge is deliberate.
- Check that the new template still contains the text that answered the query, not a redesigned version of it.
- Render the staging site with JavaScript disabled and confirm the content is still there.
- Launch, then re-crawl the old inventory within forty eight hours and fix every non-200 before doing anything else.
Redirecting everything to the home page
It is the fastest way to produce a tidy report and the fastest way to lose the traffic. A redirect to an address that does not answer the original query is treated as a soft error, and the equity does not transfer. Where no equivalent page exists, the honest options are to build one or to let the address return a 404, which at least tells the truth.
Common questions
How long should redirects stay in place?
At least a year, and there is rarely a good reason to remove them. They cost nothing to keep and removing them re-breaks every old link pointing at you.
Is a traffic dip after migration normal?
A small dip for two to four weeks while addresses are reprocessed is common. A dip of more than a fifth, or one that has not recovered after six weeks, is a fault rather than a phase.
Should we migrate and redesign at the same time?
If you can avoid it, no, because when something goes wrong you will not know which change caused it. When the project forces both, freeze the inventory first so you can at least compare page by page.
What about changing domain and platform together?
Two large variables at once. If the business can tolerate it, move platform first on the old domain, confirm stability, then move domain.
