A free 3-part training series, delivered by the SEO pros at Candour, covering the ideal migration scenario, a brought-in-too-late emergency protocol, and a traffic-tanked disaster recovery plan.
- Home
- Website Migrations
Learn Website Migrations
Understand how to plan, execute and recover from website migrations without tanking your traffic.
Free On-Demand Training Course
Website Migrations Training
A free 3-part training series, delivered by the SEO pros at Candour, covering the ideal migration scenario, a brought-in-too-late emergency protocol, and a traffic-tanked disaster recovery plan.
Understanding website migrations
A website migration is any significant change to a site that could affect its search engine visibility.
That covers a lot of ground: rebranding, moving to a new domain, switching to HTTPS, restructuring URLs, redesigning templates, re-platforming onto a new CMS, merging several sites into one, or changing how pages are rendered. In the real world, migrations are usually a combination of several of these at once, which is a big part of why they're so risky.
What are the risks of website migration?
The reason migrations make SEOs nervous is simple. When you change URLs, content, internal linking and rendering all at the same time, you give search engines a lot to re-evaluate.
Get the planning, redirects and parity checks right and a migration can be a non-event for traffic. Get them wrong and you can lose months of organic performance overnight, then spend even longer clawing it back.
Migrations rarely fail because of one big dramatic mistake. They fail because of an accumulation of small things nobody checked: a redirect map that missed a chunk of high-value URLs, a robots.txt that shipped straight from staging, canonical tags still pointing at the old domain, content that quietly got thinner in the redesign.
When should SEO get involved in a migration?
As early as humanly possible. How early SEO gets a seat at the table is the single biggest predictor of whether a migration goes smoothly. In practice you'll find yourself in one of three scenarios:
SEO is involved from day one of planning. The ideal. You can de-risk decisions before they're baked in.
SEO is consulted at the last minute, just before launch. Far more common, and where an emergency protocol earns its keep.
SEO is brought in to resuscitate a site after a migration has already gone wrong. Damage control, but recoverable with the right framework.
Wherever you land, the goal is the same: protect the organic visibility, traffic and revenue the business has already earned.
How long should a website migration take?
There's no single number, because a "migration" can be anything from a quick domain swap to a full re-platform with a rebrand stacked on top. But it helps to break the question into three separate timelines, because people tend to ask about one and worry about another.
Planning and preparation: Don't underestimate it! On a large site, the risk assessment alone can take a few weeks before any of the actual migration work starts. A healthy migration generally wants a month or two of lead time at minimum, and more for a complex one. If you're brought in late and have days rather than weeks, the work doesn't get faster, it just gets narrower: you're deciding what you're not going to do rather than doing everything well. As a rule of thumb, if you don't have time to do everything you'd want in a migration plan, the notice is too short.
The migration itself: The switch to the new site is essentially a point-in-time event, and the first few hours and the first day after launch are the critical window. The temptation is to judge the whole project by that moment, but it's the least representative part. What matters is that you treat those first hours as a deliberate checkpoint, because giving Google a clean, stable picture of the new site as quickly as possible helps it process the change faster.
Settling and recovery: This is the timeline everyone actually means when they ask how long a migration "takes", and it's the one you have the least control over. Even in a best-case scenario, plan for around a 20% dip in unbranded traffic in the short term, where short term optimistically means two to four weeks. Competitive, unbranded queries take longer to recover than branded ones, and bigger or more complex changes take longer still.
“A best-case migration should factor in about a 20% decline in traffic, at least in the short term. And the short term here is optimistically going to be two to four weeks, but your mileage may vary.”
For domain changes specifically, Google itself says the change of address process takes roughly 180 days to digest, and in practice it can take a year or more for Google to fully stop serving the old URLs. Long-tail effects can surface well after the headline traffic has recovered.
Two practical consequences follow from this:
Set expectations with stakeholders up front: a couple of months of instability is a reasonable minimum to communicate, not a worst case.
Keep the old domain and its redirects live for a good while afterwards. Twelve months is the sensible minimum, and twelve to twenty-four months is safer for a large migration, both so Google can keep consolidating the redirects and so you have an old version to compare against if something needs investigating.
So the honest answer is: planning can take days to weeks, the changeover happens on a single date in time, and full recovery typically takes anywhere from a few weeks to a year or more depending on what changed.
Core learning resources
Kick-start your learning with these website migration resources.
Website migration best practices
Before the migration: planning
1. Quantify the risk and get stakeholder buy-in
Calculate the financial value of the organic traffic at risk, and use that figure to secure the time, budget and sign-off you need.
Map page-level priority against sensitivity before you touch a single redirect, so effort goes where it matters most.
“The less that you as an SEO are involved in the process, the greater the potential risk is, and more risk means more potential money lost.”
2. Benchmark everything before you change anything
Crawl and archive the current site in full: URLs, status codes, titles, headings, canonicals, hreflang, structured data and internal links.
Record baseline performance from Google Search Console and analytics so you have a "before" to compare against.
“Benchmarking is very, very important to your migration, because you need something you can measure against to determine whether the migration is going well, or whether something's gone wrong and you need to find out why.”
3. Choose the right migration approach
Understand the different migration types and their risk profiles, remembering that most migrations combine several at once.
A staggered, phased migration reduces risk for most sites. Know the one scenario where it backfires before you commit.
“The more that changes at once, the higher your overall risk level is going to be. If you isolate changes into smaller chunks, Google has an easier time understanding what the relationship was pre-migration versus post-migration.”
4. Build a complete redirect map
Map every old URL to its closest equivalent new URL using 301 redirects.
Don't redirect everything to the homepage. Avoid redirect chains and loops, and double-check high-value and high-traffic URLs by hand.
“You want to make sure your redirect map is comprehensive, including everything. And this isn't just your standard HTML URLs; think about your PDFs, your images and your other resources too.”
During the migration: launch
1. Protect crawlability and indexability at launch
Make sure the staging robots.txt and any noindex tags don't ship to production — a classic, catastrophic migration mistake.
Confirm canonical tags reference the new URLs, not the old domain or staging environment.
“It is not that unusual for a team to push a brand new site live with a no index meta robots tag on every single page. So you want to make sure that's not the case.”
2. Preserve content and template parity
Check that pages haven't quietly lost content, headings, structured data or internal links in the redesign.
Compare old vs new templates for rendering differences, especially on JavaScript-heavy builds.
“I've seen important, revenue-driving pages removed from something like a main menu. It makes them harder for users to find, and it will be inferred by search engines as well: this page isn't as important, because it's not linked to from other important pages. It's a really quick way people kill their revenue without realising it.”
3. Update technical signals
Submit new XML sitemaps and, for domain changes, use the Google Search Console Change of Address tool.
Verify hreflang, structured data and pagination all carry across correctly.
“Once you've hit the change of address button in Google Search Console, Google itself says it takes around a hundred and eighty days to digest the switch, for it to properly stop treating the old domain as a serious entity”
4. Test redirects on the live site
Re-crawl the live site immediately after launch to confirm redirects fire correctly and resolve in a single hop.
Catch any URLs returning 404s, 302s or chains before they cost you rankings.
“Crawl that entire list in Sitebulb and verify your redirects early. Make sure they're working. Make sure Googlebot is getting where you wanted it to go.”
After the migration: monitoring & recovery
1. Monitor performance and crawling closely
Watch indexation, crawl stats, rankings and traffic daily in the weeks after launch.
Expect short-term fluctuation, but know the difference between normal settling and a genuine problem.
“Some traffic loss, some instability after a migration is practically inevitable. So you need not always freak out when things don't return to normal immediately or very quickly.”
2. Run a parity audit if traffic drops
Systematically compare old vs. new across links, content, navigation , indexability and rendering to find what changed.
Don't trust post-migration data blindly — run sanity checks first, because the data itself can mislead you.
“I'm obsessed with the idea of parity. Did you change paths or slugs? Did you prune a lot of content during the course of a migration? A lot of that content might have been doing more heavy lifting than you realised.”
3. Know when to hold, fix or roll back
Decide whether you have a genuine disaster or normal post-launch noise before pulling things apart.
Learn when to hold your nerve, when to intervene surgically, and when to cut your losses and roll back.
“Sometimes you ride the wave, let the dust settle, and tweak again. Other times you reach a threshold where waiting to see simply isn't worth it, and the right call is to roll the migration back.”
Common website migration issues
The table below lists common SEO issues that arise during website migrations. These issues are all discussed in our Website Migrations Training Series. We've included which session covers each issue, 'cos we're good like that.
Issue | Category | Training Session |
|---|---|---|
Missing or incomplete redirect map | Planning | Webinar 1 |
Redirect chains and loops | Launch | Webinar 1 |
Staging robots.txt / noindex shipped to live | Launch | Webinar 2 |
Canonical tags pointing at old domain | Launch | Webinar 2 |
High-value URLs redirected to homepage | Planning | Webinar 1 |
Lost or thinned content after redesign | Launch | Webinar 2 |
Internal links still pointing to old URLs | Launch | Webinar 2 |
Broken or missing structured data | Launch | Webinar 2 |
hreflang not carried across | Launch | Webinar 2 |
Rendering differences on new templates | Recovery | Webinar 3 |
Misreading post-migration data | Recovery | Webinar 3 |
No pre-migration benchmark to compare against | Planning | Webinar 1 |
Website migration auditing tools
No single tool runs a migration for you, but the right stack makes the difference between catching a problem in staging and discovering it weeks after launch. These are the tools the SEOs at Candour use for planning, launch and recovery.
Sitebulb (Desktop and Cloud)
Crawl the old site, the staging site and the live site, and save multiple crawls in one project so you can compare them directly.
Useful migration features include:
URL Explorer (build custom reports and pull in Search Console data per URL)
Prioritized Hints
URL Rank for spotting internal-linking and information-architecture changes
Response vs Render for diagnosing JavaScript-heavy rebuilds
Change monitoring
API connectors for GSC and GA data
A direct link out to the Wayback Machine from any crawled URL
Google Search Console
The change of address tool for domain moves, the Indexing and Sitemap reports, the Performance report for benchmarking clicks and impressions, and the under-used Crawl Stats report (hidden in Settings) for seeing exactly how Googlebot is hitting the old and new sites.
Google Analytics (GA4)
Capture and preserve historical revenue, conversion and key-event data before launch so you have a true "before" to compare against.
Looker Studio/Data Studio
Blend old and new Search Console data to compare pre- and post-migration performance at URL or page-group level across the full look-back window.
Ahrefs / Semrush
Benchmark rankings before launch, surface broken backlinks pointing at removed pages (a quick redirect-map win), and estimate the financial value of at-risk traffic using CPC data.
A robots.txt validator/testing tool
Confirm that no important URLs, including redirect targets sitting mid-chain, are accidentally blocked on either the old or new domain.
A meeting recorder (e.g. Fathom)
Capture and search everything stakeholders tell you during the fact-finding phase, so you have a reliable trail when information turns out to be wrong or incomplete.
The Wayback Machine
Pull up the old site's pages to compare against the new build when you need to see what content, links or navigation went missing.
Practical How-To Resources
Put your website migration learning into practice.