A website migration is one of the few moments a business can lose years of accumulated rankings in a single afternoon, entirely by accident. A new design goes live, URLs change, redirects get missed, and organic traffic quietly halves over the following month. None of that is inevitable. It happens because migrations get treated as a design or development project with SEO bolted on at the end, rather than planned properly from the start.
The frustrating part is that almost every migration failure traces back to the same handful of preventable causes, not to some unpredictable algorithm change or bad luck. Knowing what those causes are in advance is most of what separates a migration that protects existing rankings from one that quietly destroys them.
None of what follows is complicated in principle. It's simply detailed, unglamorous work that's easy to underestimate until the consequences of skipping it show up in a traffic report a month later.
What counts as a migration
This covers more situations than most businesses assume: a full redesign even on the same domain, moving to a new platform or CMS, changing your domain name, switching from HTTP to HTTPS, restructuring your URL patterns, or consolidating multiple sites into one. Each of these carries the same underlying risk, that search engines lose track of pages they previously trusted and have to rebuild that trust from scratch.
Before anything changes: full documentation
The single most common cause of migration traffic loss is simple: nobody wrote down what the old site actually looked like before it changed. A proper pre-migration process documents every indexed URL, its current rankings and organic traffic, its backlink profile, its meta data, and its internal linking. Without this baseline, there's no way to know afterwards what broke or measure whether the migration actually worked.
Redirect mapping, done properly
Every single old URL that changes needs a 301 redirect to its closest equivalent new URL. Not a blanket redirect to the homepage, which tells search engines the specific content no longer exists anywhere, and not a redirect to a vaguely related page, which passes only a fraction of the original page's authority. This mapping is tedious for a site with hundreds of pages, and it's exactly the part that gets rushed or skipped when a migration is running behind schedule.
The redirect chain trap
A redirect that points to another redirect, which points to a third URL, is a chain, and each hop in that chain leaks some authority and slows the page down. After a migration, every redirect should be checked to confirm it goes directly to its final destination in one hop, not through two or three intermediate stops left over from a previous migration nobody cleaned up properly.
What to check immediately after launch
The first 48 hours after a migration go live matter more than any other point in the process:
- 01Submit the updated XML sitemap to Google Search Console immediately
- 02Check that the new site isn't accidentally blocking search engines via robots.txt, a common mistake left over from staging environments
- 03Test a sample of redirects across every major page type, not just the homepage and a handful of top pages
- 04Confirm canonical tags on the new site point to the correct new URLs, not leftover staging URLs
- 05Monitor Search Console's coverage report daily for a spike in crawl errors or a sudden drop in indexed pages
Content and structure changes need their own plan
A redesign often comes with new page structures, consolidated content, or a different information architecture. Each of these needs its own mapping exercise on top of basic URL redirects. If three old pages get merged into one new page, that new page needs to genuinely cover what all three previously ranked for, or expect to lose the rankings the other two pages held.
What a poorly handled migration actually looks like
A common pattern: a business replatforms from an old CMS to a modern one, the development team focuses entirely on getting the new design live on schedule, and redirect mapping gets treated as a quick task for the final week. Two hundred old URLs get redirected, but eighteen hundred more, mostly older blog posts and resource pages, don't, because nobody had a complete list of what existed on the old site in the first place. Three weeks after launch, organic traffic has dropped by a third, and untangling which specific pages lost their rankings becomes a forensic exercise that takes longer than the redirect mapping would have taken if it had been done properly from the start.
Monitoring in the weeks that follow
A brief dip in rankings for one to two weeks after a well-executed migration is normal, since search engines need time to recrawl and re-evaluate the new site. A dip that continues past that window, or a sharp cliff rather than a gradual recovery, signals a genuine problem worth investigating immediately rather than waiting to see if it resolves on its own. Comparing organic traffic, rankings and indexed page count against the pre-migration baseline weekly for the first two months is the only reliable way to catch a real problem early.
Common objections, answered
We're only changing the design, not the URLs, so we don't need redirects, right?
Correct in principle, but check this assumption rather than assuming it holds. Many redesigns end up changing URL structures as a side effect of switching CMS or restructuring navigation, even when that wasn't the original intent. Confirm explicitly with your development team whether URLs are staying identical, and treat any uncertainty as a reason to prepare redirect mapping just in case.
Our developer says the migration is straightforward, do we still need an SEO specialist involved?
Straightforward from a development perspective and straightforward from a search visibility perspective aren't the same thing. A developer can build a technically clean new site that still loses most of its organic traffic if redirect mapping, content parity and crawler access aren't specifically addressed, since these aren't standard parts of a typical development process unless someone is explicitly responsible for them.
What if we've already migrated and traffic has dropped?
It's recoverable in most cases. Start by auditing which old URLs are returning errors or redirecting incorrectly, check whether AI and search crawlers are being blocked, and compare current content against the pre-migration version for any parity gaps. The earlier this is caught after a drop, the faster recovery tends to be, since search engines haven't had as long to fully deprioritise the affected pages.
Why this is worth planning properly
The businesses that come through a migration with rankings intact, or even improved, treat SEO as part of the migration plan from the first meeting, not a final check before launch. A properly run website migration accounts for redirect mapping, content parity and post-launch monitoring as core deliverables, not optional extras bolted on if there's time left in the project.
Planning a website migration and want to protect your existing rankings?
Book a call