Website migrations are where good sites lose traffic. A new design, a new CMS, a rebrand onto a new domain or a switch to HTTPS can all be positive changes, but each one asks Google to reprocess URLs, signals and content it already understood. Miss a redirect map, leave a noindex tag from staging or change URLs without telling anyone, and years of SEO work can disappear in a weekend.
The good news is that most migration losses are avoidable. They come from a handful of predictable mistakes, and Google publishes clear guidance on how to move a site safely.
This checklist takes you through every phase: defining the scope, building a URL map, preparing and testing the new site, launch day, and the monitoring that follows. Use it for redesigns, replatforms, domain changes and restructures.
Key Takeaways
- Know exactly which type of migration you are doing; each carries different risks and steps.
- Benchmark traffic, rankings and indexed pages before you touch anything.
- Map every old URL to its most relevant new URL and implement server-side 301 or 308 redirects.
- Test the new site on staging (redirects, canonicals, robots rules, content, structured data) before launch.
- Expect temporary fluctuations; monitor closely for weeks and keep redirects for at least a year.
Types of Website Migration
| Migration type | Example | URLs change? | SEO risk |
|---|---|---|---|
| Protocol change | HTTP to HTTPS | Yes (protocol) | Low to medium |
| Domain change | Rebrand to a new domain, or merging two domains | Yes | High |
| Structure / URL change | New folder structure, removing file extensions, changing slugs | Yes (paths) | Medium to high |
| Platform / CMS change | WordPress to Shopify, custom to headless | Often | Medium to high |
| Redesign | New templates, navigation and content | Sometimes | Medium; content and internal links change |
| Hosting or CDN move | New server, same URLs | No | Low, if the server is fast and stable |
Many projects combine several of these. If you can, stagger them; it makes problems easier to isolate. For a pure protocol switch, see our dedicated guide to HTTPS and SEO.
Phase 1: Plan and Benchmark
- Define the scope and goals. Write down what is changing (domain, URLs, templates, content, platform) and what must not change.
- Involve SEO from the start. The cheapest time to fix an SEO problem is before the new site is built.
- Pick a low-traffic launch window. Avoid peak season and make sure developers are available for several days afterwards.
- Benchmark everything. Export organic traffic by landing page, conversions, rankings for priority keywords, indexed pages, Core Web Vitals and backlink targets. Our list of SEO KPIs is a useful template.
- Crawl the current site and keep the export. You will need titles, meta descriptions, canonicals, headings and internal link data for comparison later.
Phase 2: Build the URL Map
The URL map, a spreadsheet pairing every old URL with its new destination, is the single most important migration document. Google's site move guidance stresses mapping old URLs to new ones before you move.
- Collect every old URL from crawls, XML sitemaps, analytics landing pages, Search Console, backlink tools and server logs. Crawls alone miss orphaned and legacy URLs that still get traffic or links.
- Map one-to-one wherever possible. Each old page should redirect to its closest equivalent new page.
- Handle merges deliberately. If several old pages become one, redirect them all to the new consolidated page.
- Decide what to retire. Pages with no equivalent, no traffic and no links can return 404 or 410.
- Prioritise. Flag top traffic, top converting and most linked URLs for extra testing.
“Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site.”
— Google Search Central, Site moves with URL changes
Google notes that such mass redirects confuse users and may be treated as soft 404s. Use server-side permanent redirects (301 or 308); our guide to 301 vs 302 redirects explains why the type matters.
Phase 3: Prepare and Test the New Site
Before launch, test the staging site as if it were live, but keep it out of the index with password protection or IP restrictions (preferable to relying only on noindex, which is easy to forget to remove).
| Area | What to check on staging |
|---|---|
| Redirects | Every mapped URL returns a single 301/308 hop to the right 200 page; no chains or loops |
| Indexability | Production robots.txt ready; no stray noindex; canonicals point to the new self URLs |
| Content parity | Key pages keep their main content, headings, titles and meta descriptions unless intentionally improved |
| Internal links | Navigation, body links and breadcrumbs point to new URLs directly, not via redirects |
| Structured data and hreflang | Valid markup with updated URLs; see our hreflang guide for multilingual sites |
| XML sitemaps | New sitemap lists only new canonical URLs |
| Performance | Core Web Vitals and server response times at least as good as the old site |
| Analytics and tags | GA4, Tag Manager, conversion tracking and consent tools working |
| Rendering | Important content and links visible in the rendered HTML Google sees |
Also make sure the new server can handle the extra crawling that follows a move; Google's guidance specifically mentions ensuring enough computing resources. Our guide to HTTP status codes explains what to look for when testing responses.
Phase 4: Launch Day
- Take final backups and a last crawl of the old site.
- Deploy the new site and switch on redirects at the same time.
- Remove staging restrictions: password protection,
noindextags and disallow rules that were only for the build. - Spot-check priority URLs: old URLs redirect correctly, new pages return 200, canonicals and robots meta are right.
- Set up Search Console for the new property if the domain changed, submit the new XML sitemap and, for domain or subdomain moves, use the Change of Address tool. Google says not to use it for HTTP to HTTPS moves.
- Update what you control: Google Business Profile, social profiles, paid ad URLs, email templates and important partner links.
For small and medium sites, Google recommends moving all URLs at the same time. Larger sites can move one section at a time, which is often safer.
Phase 5: Monitor and Fix
Google warns that rankings may fluctuate while it recrawls and reindexes, and that for a medium-sized site it can take a few weeks or more for most pages to move. Monitor actively:
- Daily for the first week: crawl the old URL list to confirm redirects, check server errors, and review the Page indexing report and URL Inspection for key pages.
- Weekly for the first months: compare organic traffic and conversions by page and section against your benchmark, and track rankings for priority keywords.
- Use server logs: confirm Googlebot is crawling new URLs and following redirects. See our log file analysis guide.
- Watch 404s and soft 404s: add redirects for any old URLs you missed; our guide to fixing 404 errors shows how to prioritise them.
- Collapse new redirect chains created by layering new rules on old ones; see redirect chains and loops.
- Keep redirects long term. Google advises generally at least a year, and the Change of Address tool's effects run for 180 days, so never remove redirects early.
Common Mistakes
- Launching with staging
noindexor robots.txt disallow rules. One of the most common and most damaging errors. - No URL map, or redirecting everything to the homepage.
- Losing content. Trimming copy, merging pages carelessly or dropping FAQs and reviews during a redesign removes the signals that made pages rank.
- Changing too much at once, making any drop impossible to diagnose.
- Using temporary redirects, or JavaScript redirects where server-side ones are possible.
- Forgetting images, PDFs and other files that earn traffic and links.
- Letting the old domain expire. Keep renewing it so redirects keep working.
- Stopping monitoring after launch day. Problems often surface weeks later.
Related Guides
- Orphan Pages: How to Find and Fix Them
- Redirect Chains and Loops: How to Fix Them
- Search Console Page Indexing Report: Every Status Explained
Frequently Asked Questions
How long does it take Google to process a site migration?
Google says that for a medium-sized site it can take a few weeks or more for most pages to move in its index, and larger sites can take longer. Expect some ranking fluctuation in the meantime.
How long should I keep redirects after a migration?
Google recommends keeping them generally for at least a year, and ideally for as long as possible. Old URLs keep receiving visits from backlinks, bookmarks and other sites for years.
Should I use the Change of Address tool?
Use it when moving from one domain or subdomain to another, after redirects are live. Do not use it for HTTP to HTTPS moves or path changes within the same site; redirects and updated sitemaps handle those.
Is it better to migrate everything at once or in stages?
Google recommends moving small and medium sites all at once. Large sites can move one section at a time, which makes it easier to spot and fix problems before moving the rest.
Should I redesign and change domains at the same time?
If you can, avoid combining several big changes. Each one adds risk and makes it harder to diagnose any traffic drop. When they must happen together, invest more in testing and monitoring.
What should I do if traffic drops after migration?
Check the basics first: redirects, robots.txt, noindex tags, canonicals and sitemaps. Then compare page-level traffic and rankings to your baseline to find which sections lost visibility, and check logs and Search Console for crawl errors.
Conclusion
A successful website migration is mostly preparation: benchmark first, map every URL, test thoroughly on staging, launch carefully and monitor for weeks afterwards. Follow Google's guidance on redirects and timing, avoid stacking unnecessary changes, and a redesign or domain move can be a platform for growth rather than a traffic crash.
Planning a migration? Our web development and SEO teams manage migrations end to end, from URL mapping to post-launch monitoring. Get a free quote before you launch, not after.
References
- Google Search Central: Site moves with URL changes
- Google Search Central: Site moves without URL changes
- Search Console Help: Change of Address tool
- Google Search Central: Redirects and Google Search
- Google Crawling Infrastructure: How HTTP status codes affect Google's crawlers
- Semrush: The Complete Website Migration Checklist [SEO-Friendly]



