Every redesign or platform migration carries the same risk, and it's one clients rarely think about until we bring it up: Google has to re-crawl and re-evaluate every URL on the new site, and if that process goes wrong, rankings that took years to build can drop sharply within weeks. We've been called in to fix migrations that went wrong more than once, and the fixes are always more painful than doing it right the first time would have been.
The URL mapping step nobody wants to do
The single most important piece of a migration is a complete, one-to-one mapping of every old URL to its new equivalent, with a 301 redirect in place for each one before the new site goes live. It's tedious, unglamorous work — sometimes hundreds or thousands of rows in a spreadsheet — and it's exactly the step that gets rushed or skipped when a launch deadline is tight. Every URL without a mapped redirect is a page that either 404s or loses its accumulated ranking signal, and both outcomes cost real traffic.
We treat this mapping as a hard prerequisite for launch, not a nice-to-have cleanup task for afterward. If the new site's information architecture is different enough that a clean one-to-one mapping isn't possible for some pages, we map to the closest relevant equivalent rather than defaulting everything to the homepage — a blanket homepage redirect for pages that don't map cleanly is a common shortcut that quietly tanks rankings for exactly those pages.
What we check before and after launch
Before launch, we crawl the current site and record its full URL list, indexed status, and current rankings for its top pages, so we have a real baseline to compare against — not a vague sense of “it seemed to be doing fine.” We also make sure canonical tags, meta descriptions, and title tags carry over correctly to the new templates, since a redesign frequently changes the template structure and it's easy for these to get silently dropped or duplicated across every page.
After launch, we submit the new sitemap in Search Console immediately and monitor the coverage report daily for the first two weeks, watching specifically for a spike in 404s or a drop in indexed page count. Traffic dips of some kind are close to unavoidable during the re-crawl window even on a well-executed migration — Google needs time to process the change — but a well-planned migration sees that recover within two to four weeks. A migration where the redirects were rushed or incomplete can take months to recover, if it fully recovers at all.
The mistake we see most often
The most common failure we're brought in to fix isn't a technical mistake at all — it's a client changing their URL structure for aesthetic or branding reasons with no SEO input at all, discovering the redirect mapping only after the new site is already live. By that point we're doing forensic reconstruction of the old site's structure from cached versions and analytics history instead of working from a clean plan, which is a much slower and less certain process than getting the mapping right before launch would have been.
Communicating the migration internally before it happens
A migration that goes technically well can still cause a panic internally if the people who watch analytics dashboards weren't told to expect a temporary dip. We now send a short note to the client's marketing and leadership team before every migration, explaining in plain terms that a traffic dip during the first two to four weeks is normal and expected, not a sign something went wrong. Without that context, the first dashboard screenshot showing a week-over-week drop tends to generate an urgent message asking what broke — even when the migration is proceeding exactly as planned.
We also set a specific check-in date, usually three to four weeks out, rather than leaving the recovery timeline open-ended. An open-ended “it'll recover eventually” invites anxious daily checking during the most volatile period; a specific date to reassess gives everyone a concrete point to actually judge the migration against, using the real baseline data gathered before launch rather than a gut feeling about whether things seem fine.
What we do if recovery doesn't happen on schedule
Occasionally a migration doesn't recover within the expected window, and when that happens we go back to the redirect map first, since an incomplete or incorrectly targeted redirect is the most common root cause even in migrations that seemed well-planned. We re-crawl the live site and compare it against the pre-migration URL list, looking specifically for any page returning a 404 or redirecting somewhere other than its intended destination — mistakes here are easy to make across a large site and easy to miss without a systematic re-check.
If the redirects are clean, the next place we look is whether the new page templates preserved the same on-page signals — heading structure, internal linking patterns, page speed — that the old templates had, since a redesign sometimes changes more than just the URL structure without anyone intending it to. Slower recovery is frustrating for a client to sit through, but it's almost always traceable to one of these two causes once we go looking, rather than something mysterious about how the migration itself was handled.
None of this is exotic — it's the same discipline good SEO work always requires, just applied under the added pressure of a hard cutover date. A migration doesn't need to be a gamble on traffic if the mapping work happens before launch instead of being reconstructed after something's already gone wrong.
