A website migration is any change to where a site lives or how its URLs look: a new domain, a new platform or CMS, a new URL structure, a move to https or a new host. For SEO, a migration succeeds when every old URL leads to its new equivalent in one permanent redirect and the new site can be indexed from the first day; then traffic dips for a few weeks at most and recovers. This guide is the map for site owners, marketers and the developers they work with: which kind of migration you are doing, the strategy and timeline, the redirect map at the centre of it, and how to prove it worked. The step-by-step checklist and the platform guides are linked where you need them.
Quick answer
- Know your migration type first. A host move keeps every URL; a domain, platform or structure change replaces them. Only the second kind needs a redirect map, and it carries most of the risk.
- Change as little as possible at once. Keep URLs wherever you can. Every changed URL is a ranking that has to be moved.
- Build the redirect map before you build the site. Every old URL that has traffic, links or rankings gets a one-hop 301 to its closest new equivalent. No home-page catch-all.
- Launch everything at once on small and medium sites, as Google recommends: redirects, new sitemap, canonicals and internal links on the new URLs, staging
noindexremoved. - Verify on staging, on launch day and a week later, with every old URL, not a sample. The migration redirect validator checks up to 1,000 pairs per run.
- Expect a few weeks of movement. Google says most pages of a small to medium site move within a few weeks. Keep the redirects for at least a year.
What is a website migration?
In SEO, "migration" covers any project that changes the addresses search engines have indexed or the system that serves them. Google's documentation splits them into two groups, and that split is the most useful way to think about risk.
Moves without URL changes. You switch hosting provider, move behind a CDN or rebuild the design, but every page keeps its address. Search engines only need to see that the same URLs still answer, quickly and with the same content. Google's guide to site moves without URL changes covers hosting moves.
Moves with URL changes. You change domain, switch from http to https, move to a new CMS that writes different URLs, change the URL structure, or merge sites. Every indexed URL now has to be replaced by a new one, and the only way to carry its rankings over is a redirect from the old address to the new. Google's guide to site moves with URL changes covers these.
| Migration | URLs change | What carries the rankings | Risk |
|---|---|---|---|
| New host or CDN | No | Nothing to transfer; speed and uptime matter | Low |
| Redesign on the same URLs | No | Content, internal links and templates must stay as good | Medium |
| http to https | Scheme only | One site-wide 301 rule | Low when done in one hop |
| New URL structure | Paths | A redirect map | High |
| New CMS or platform | Usually paths | A redirect map plus rebuilt metadata and schema | High |
| New domain | All | A redirect map plus Change of Address in Search Console | High |
| Merging sites | All on the merged site | A redirect map to the matching pages | High |
Many projects combine several rows, such as a new platform with a new design and new URLs. Each row you add multiplies what can go wrong and makes a traffic drop harder to explain afterwards.
Why do migrations lose traffic?
Search engines keep an index of URLs, and everything they know about a page, including its links, history and rankings, is attached to its address. When the address changes, that knowledge has to be moved, and the mechanism is a permanent redirect that Google finds when it recrawls the old URL. The losses come from four places.
- Old URLs without a redirect. They answer 404, and the links pointing to them from other sites now point at nothing.
- Redirects to the wrong place. A product sent to the home page or a category is not an equivalent. Google's documentation warns against redirecting many old URLs to one irrelevant destination, and may treat those redirects as soft 404s.
- A new site that cannot be indexed. A
noindexor aDisallow: /carried over from staging, canonicals that still name the old domain, or content that now appears only after JavaScript runs. - A new site that is worse. Pages merged or cut, thinner text, lost internal links, missing structured data, or slower templates. Redirects cannot carry over content that no longer exists.
The first three are mistakes you can find and fix within hours with the right checks. The fourth is a content decision, and the time to catch it is before launch, by comparing the new templates with the old pages.
Your SEO migration strategy
A good migration strategy is mostly about saying no. These principles apply whatever the platform.
Change one thing at a time where you can. Moving to https in one project and to a new CMS in another makes each easier to verify, and makes any drop traceable to one cause. When a combined move is unavoidable, the redirect map and the verification become even more important.
Keep URLs that are fine. A new CMS does not require new URLs. Most platforms let you set slugs and folder structures, and every URL you keep is a redirect you do not need and a ranking that does not move.
Treat content as part of the migration. List the pages that earn traffic and links, and make sure each one has a new home with at least the same text, headings, internal links, structured data and metadata.
Move everything at once on small and medium sites. Google's site move guidance recommends moving all URLs at the same time rather than one section at a time for small and medium sites. Very large sites may move section by section, starting with a small one to learn from.
Plan the measurement before the move. You cannot tell whether a migration worked without a baseline: rankings, traffic per page, indexed pages, Core Web Vitals and the getReport report on key templates, recorded before launch.
Pick a quiet launch window. Avoid your busiest season and the days before a holiday, and launch early in the week when the people who can fix things are around.
The website migration plan and timeline
Durations depend on the size of the site and how much changes, so treat these phases as an order, not a schedule. A small site can go through all of them in a few weeks; a large shop may need months for phases 1 and 2 alone.
Phase 1: inventory and baseline
Export every URL you have: the XML sitemap, the pages that get traffic in your analytics, the pages with impressions in Google Search Console, the URLs other sites link to, and a crawl of the current site. Record the baseline for your key pages. The cluster guide on measuring before and after a redesign shows how to pick those pages, what to record and how to compare at 7 and 28 days; it applies to any migration, not just redesigns.
Phase 2: the redirect map
Pair every old URL with its new URL in a two-column spreadsheet. This map is the single most valuable document in the project, and it is covered in its own section below.
Phase 3: build and test on staging
Build the new site with the new URLs, then test it before anyone outside the team sees it: every template indexable, one canonical per page on the new addresses, titles and descriptions carried over, structured data present, internal links on the new URLs, and speed at least as good as before. Keep staging out of search with password protection rather than only a noindex that can ride along to production. Staging sites: testing changes before they go live covers the setup.
Phase 4: launch
Switch the site and the redirects at the same moment. Remove the staging protection and any noindex, publish the new robots.txt and sitemap, and submit the sitemap in Search Console. For a domain move, start the Change of Address in Search Console. Then verify every old URL on the live site the same day.
Phase 5: monitor and fix
Watch Search Console's page indexing report, 404s in your server logs, rankings and traffic on your key pages, and the report on your templates. Check the old URL list again a week after launch, when caches and CDNs have caught up. Google says most pages of a small to medium site move within a few weeks. Keep the redirects for at least one year, as Google's guidance says, and preferably for good.
For the full list of tasks in each phase in a printable format, use the site migration checklist for domain, https and CMS moves. It has the before, launch-day and after steps, the three classic failures and the platform notes for WordPress and Shopify.
The redirect map: the heart of every migration
A redirect map, or 301 redirect map, is a list that pairs every old URL with the new URL it should redirect to. Your developer turns it into server rules, and you use it again to verify that each rule works.
Build it from every source of old URLs, not only the sitemap: a crawl, Search Console, analytics landing pages, backlinks, server logs and the redirect rules left from earlier migrations. Match each old URL to its closest equivalent, by slug or ID where the platform kept them and by hand for the rest, starting with the pages that have the most traffic and links. Pages with no equivalent and no value can answer 404 or 410; none of them should go to the home page. Then check the map itself for chains, loops and duplicates, and point redirects from earlier migrations at the newest addresses.
The guide to redirect mapping for a site migration covers each step in detail: the spreadsheet columns worth having, cleaning and matching the list, when pattern rules are safe, and testing the map three times.
Two tools do the mechanical parts. The redirect rule generator turns the two columns into exact-match rules for Apache, nginx, Cloudflare Bulk Redirects, Netlify, Vercel or Caddy, and collapses chains and removes loops before a rule is written. After deploying, the validator checks the live result:
Paste the same map, up to 1,000 pairs per run. The validator requests each old URL, follows every redirect and gives each pair one verdict: correct, wrong target, not redirected or gone, chain, temporary redirect, or a target that is broken or set to noindex. Each run keeps its own link for 30 days, filterable by verdict, with a CSV for your developer.
The redirect mapping guide also covers the other angle: running a plain list of old URLs, such as an old sitemap, through the bulk URL checker and reading its final status, hops, canonical and noindex columns.
Types of migration and what each needs
Changing domain name
A domain change moves every URL, so it needs the full redirect map, path to path, from the old domain to the new one. Keep the old domain registered and its redirects running for years; links from other sites and old bookmarks keep arriving.
Google's Change of Address tool in Search Console tells Google the move is intentional. According to Google's help page, you need to be a verified owner of both properties with the same Google account, the 301 redirects must already be in place, the tool works for domain-level properties only, and its signals last 180 days. Keep the redirects for at least 180 days, and longer while Google still sends traffic to old URLs. The tool is not meant for http to https moves or for switching between www and non-www. Google's site move guidance, updated in June 2026, adds that you should submit Change of Address for every variant of the old domain, www, non-www and subdomains, and verify each one first.
The guide to changing domain name without losing SEO puts the whole move in order, from checking the new domain's history to updating business listings, structured data and email, and explains what to expect in search in the weeks after. The redirect setups themselves are in how to redirect a domain to another domain.
Moving from http to https
The lowest-risk URL change: one site-wide rule redirects every http:// address to the same path on https://, in one hop, combined with your www and trailing-slash rules so no chain forms. Update canonicals, hreflang, the sitemap and internal links to https, and fix any image, script or stylesheet still loaded over http, which browsers block or flag as mixed content. Mixed content after https covers finding those, and trailing slashes, www and https: pick one shows how to fold all the variants into one rule. Add the https property in Search Console; no Change of Address is needed.
The https migration guide puts those steps in order: test the https site before redirecting, update every self-reference, turn on the combined 301, set up Search Console, and add HSTS last, with a short max-age first, because it is hard to undo.
Changing CMS or platform
A platform change, for example from WordPress to Shopify or from a custom system to a headless setup, usually changes paths even when nobody intends it: Shopify puts products under /products/ and categories under /collections/, and other platforms have their own fixed prefixes. Beyond the redirect map, check that titles, meta descriptions, headings, image alt text, structured data and hreflang come across, since import tools often drop them. If the new front end is built with a JavaScript framework, check that it renders content on the server; the JavaScript SEO guide explains why that matters.
The CMS migration SEO guide goes through a platform change template by template: which URL patterns Shopify, Webflow and Wix fix for you, how to inventory the SEO fields that import tools skip, where redirects live on each platform, and how to check that a headless front end renders for Google.
Moving WordPress to a new host or domain
WordPress stores its own address in the database and in serialized data, so a move needs a search-and-replace that understands serialized values, plus the settings, wp-config.php and caching layers that hold the old address. The WordPress site migration checklist covers the WordPress layer step by step, from the backup to the bulk URL check.
Changing host without changing URLs
A host move needs no redirects, but it can still cost rankings if the new server is slow or unreachable for Googlebot. Google's guidance is to test the new hosting first, lower the DNS time to live to a few hours at least a week before the switch, and keep the old host running until its traffic falls to zero. Expect Google's crawl rate to dip briefly after the switch and recover over several days. Compare server response time before and after; TTFB: what a slow server looks like explains what to measure.
Redesigning on the same URLs
A redesign keeps addresses but can change everything search engines read: headings, text, internal links, structured data and speed. Most traffic drops after a redesign trace back to content removed from templates or links dropped from navigation. Benchmark first, test every template on staging and compare afterwards, as the before-and-after redesign guide describes.
How to verify a migration
Verification is where most migrations are won, because the common mistakes are all visible within minutes of launch if someone looks.
Every old URL, not a sample. Run the full redirect map through the validator on staging (with the staging host), again on launch day and again a week later. Every pair should be one 301 or 308 to a page that answers 200 and can be indexed.
Key templates on the new site. Run the full getReport report on the home page, a product or post, a category and a deep page. These findings catch the classic launch-day failures:
Search Console. Submit the new sitemap, watch the page indexing report for rising "Not found (404)" and "Page with redirect" counts, and inspect a few key URLs with URL Inspection. For single redirects you are unsure about, the redirect checker shows every hop and the final canonical.
Chains from earlier moves. Old redirects from previous relaunches are the usual source of chains after a migration. Redirect chains after a migration shows how to find every hop and rewrite the old rules to point at final URLs. The pillar guide on 301 redirects explains the redirect types, and why a 302 for a permanent move costs time.
What to expect after launch
Rankings and traffic usually move for a while after a migration with URL changes, even when everything is right, because Google has to recrawl every old URL to discover its redirect. Popular pages are recrawled within days; rarely visited ones can take much longer. Google says most pages of a small to medium site move within a few weeks, and that rankings may fluctuate while it recrawls and reindexes.
A drop that keeps getting worse after the first weeks, or that is concentrated in certain page types, is a sign of a problem rather than the process. Compare your key pages against the baseline, then check the redirect verdicts and the report findings for those pages. The cause is almost always one of the four in "Why do migrations lose traffic?" above, and each has a specific fix.
Common mistakes
- Staging
noindexorDisallow: /shipped to production. The most expensive single-line mistake in SEO. Check on launch day, within the hour. - Everything redirected to the home page. Fast to set up, and it throws away the rankings of every deeper page.
- Redirects that go live after the new site. Even a day of 404s on popular URLs is visible in search and to visitors.
- Chains from earlier migrations. Old rules still point at URLs that now redirect again.
- Temporary redirects for a permanent move. Some platforms and plugins default to 302; check the status code.
- Canonicals, hreflang or the sitemap still on old URLs. They contradict the redirects and slow the move down.
- Old domain or redirects removed after a few months. Links from other sites and bookmarks keep arriving for years.
- Changing everything at once, then guessing. Domain, platform, design and content in one launch leaves no way to tell which change caused a drop.
Questions people ask
What is site migration in SEO?
Site migration in SEO is any change to a site that affects how search engines find and index it: a new domain, a switch to https, a new CMS or platform, a new URL structure, or a new host. Moves that change URLs need a permanent redirect from every old address to its new equivalent, so rankings and links carry over to the new pages.
What is an SEO migration strategy?
It is the plan for moving a site while keeping its search traffic. The core is to change as few URLs as possible, map every old URL that has traffic or links to its closest new page with a one-hop 301, carry over content and metadata, launch redirects together with the new site, and verify every old URL on staging, launch day and a week later.
What does a realistic website migration timeline look like?
For a small site, a few weeks from inventory to launch; for a large shop or publisher, several months. The phases are the same: inventory and baseline, redirect map, build and test on staging, launch, then monitoring. After launch, Google says most pages of a small to medium site move within a few weeks, and redirects should stay for at least a year.
Should I move the whole site at once or in sections?
Move everything at once if your site is small or medium. Google's site move guidance recommends moving all URLs at the same time for such sites, because it is simpler and gives Google one clear signal. Very large sites can move section by section, starting with a small, representative section to learn from before moving the rest.
Do I need to tell Google about a website migration?
Only for a domain change, and then through the Change of Address tool in Search Console, after the 301 redirects are live. For every migration, submit the new XML sitemap in Search Console. An http to https move, a www change or a host move needs no notification: the redirects and the sitemap are the signal.
Can I change web host without affecting SEO?
Yes, if the URLs stay the same and the new server is at least as fast and reliable. Test the site on the new host before switching, lower the DNS time to live a week before the move, and keep the old host running until traffic to it stops. Google's crawl rate may dip briefly after the switch and recover within days.
Is it safe to redesign and migrate at the same time?
It is possible but riskier, because two changes make any traffic drop harder to diagnose. If you can, move the URLs first on the old design, or redesign first on the old URLs. If both must happen together, record a detailed baseline, keep as many URLs as possible, test every template on staging and verify every redirect after launch.