A website migration (domain change, moving from HTTP to HTTPS, switching CMS or URL structure) is, technically, the highest-risk moment for an established site's SEO: all the value accumulated over years of crawling, links and history depends on the transition being correctly communicated to Google, and a single badly executed step can translate into weeks or months of traffic drops while Google rebuilds its trust in the new site.
Why migrations fail: it's almost never a content problem
Page content usually stays the same or improves in a migration; what fails, in the vast majority of documented cases, is the technical communication of the change: URLs that change with no redirect, badly configured redirects (302 instead of 301, as explained in the redirects guide), or an incomplete mapping where some old URLs simply stop existing with nowhere to redirect to. Google doesn't penalize a migration by itself; in practice, it penalizes the loss of signals that used to exist and that the migration broke without replacing them.
URL mapping: the single most important document in the whole migration
Before moving a single page, you need a complete, exhaustive mapping: a table with every indexed old URL and its corresponding new URL, no exceptions. This mapping must be based on real data (a full crawl of the old site, cross-referenced with Search Console to also include URLs that receive traffic but that an internal crawl might not find, like pages with only external links) rather than on an assumption that "the new structure is more logical, Google will figure it out."
Old URL -> New URL
/products/nordic-chair.html -> /furniture/chairs/nordic-chair
/blog/2019/how-to-choose-a-chair -> /blog/how-to-choose-a-chair
/category.php?id=42 -> /category/dining-chairs
Every row of this mapping literally becomes
a 301 redirect rule.The correct order: prepare everything before changing anything in production
A common sequencing mistake is activating the new domain or structure before the redirects are complete and tested. The recommended technical order is: complete the URL mapping, set up and test every redirect on an internally-only accessible staging environment, verify the new site is crawlable (correct robots.txt, no blocks inherited from the staging setup), and only then flip the switch in production with redirects already working from the very first second, not added after Google starts finding mass 404s.
The day of the switch: what to do immediately afterward
As soon as the new site is live with redirects active, three technical actions speed up recovery: submitting the new XML sitemap (with the new URLs) in Search Console, using Search Console's Change of Address tool if the change includes a new domain (this tool explicitly tells Google it's a planned migration, not a different site competing with the old one), and monitoring the Search Console coverage report daily for the first few weeks to catch spikes in 404 errors or "crawled, not indexed" URLs that reveal gaps in the original mapping.
One-to-one redirects versus generic redirects
Migration quality depends directly on the mapping's granularity: redirecting every old URL of a section generically to the new section's homepage (instead of to its exact equivalent) transfers far less ranking value than a one-to-one redirect toward the specific page that truly continues that content. It's a common temptation when exact mapping is laborious, but the cost in lost traffic almost always outweighs the time saved.
What happens to external links pointing to the old URLs
301 redirects don't just serve users who click an old search result; over time, they also transfer the value of external links other sites have pointing to those URLs. This is the underlying reason redirects should be kept indefinitely (see the redirects guide): an external link from five years ago, that nobody is ever going to update, still contributes real value as long as the redirect exists, and stops doing so the moment it's removed.
Partial migrations: when only part of the site changes
Not every migration is a complete domain change; it's just as common to migrate only one section (for example, moving the blog from a subdomain to a subfolder of the main domain, something that usually improves SEO performance by consolidating authority under a single domain). The same rigor of mapping and redirecting applies exactly the same to a partial migration as to a full one; the risk of losing traffic is proportional to the number of URLs affected, not the percentage of the site they represent.
How long it takes a site to recover its rankings after migrating
There's no fixed timeframe, but as a rough reference based on well-executed migrations: sites with established authority and a complete redirect mapping usually see substantial recovery in 2 to 8 weeks, with near-full recovery by 3 or 4 months. Migrations with gaps in the mapping, badly configured redirects, or simultaneous domain and URL structure changes at once (mixing two risk variables in a single move) can take considerably longer, or never fully recover if the errors aren't fixed in time.
Frequently asked questions
Is it safer to migrate gradually or all at once?
It depends on the type of change: a domain change or an HTTP-to-HTTPS switch is usually done all at once because there's no point having the site split between two versions. A URL structure or architecture change, on the other hand, can benefit from being done in phases, section by section, to catch and fix problems before they affect the whole site.
Should I notify Google before migrating?
There's no formal advance notice as such, but Search Console's Change of Address tool, activated the same day as the switch, serves that purpose: it confirms to Google that the change is intentional and planned.
What happens if I'm missing redirects for 5% of the old URLs?
That 5% turns into 404 errors that Google progressively discovers as it tries to crawl the old URLs it still remembers; the impact is proportional to the value of those specific URLs, so reviewing which URLs were left unmapped (using Search Console and server logs) should be an immediate task after launch, not something to check "when there's time."
Does switching CMS affect SEO even if the URLs don't change?
It can affect it indirectly if the new CMS generates different HTML, changes load speed, or handles technical elements like robots.txt, the sitemap, or canonical tags differently. Keeping the URLs the same doesn't eliminate the risk if other technical aspects change uncontrolled.
How long should I keep the old site accessible during the migration?
Ideally the old site should stop serving direct content and switch to returning only the 301 redirects from the very moment of the change, rather than both versions staying accessible in parallel, which would create exactly the duplicate content problem the canonicalization guide describes.