Website migration checklist: how to move a site without losing rankings

A website migration is any change that forces Google to relearn your URLs or your content: moving to a new domain, switching to a CMS with a different URL structure, going from HTTP to HTTPS, or merging two sites into one. Moving to a new server, or a redesign that keeps every URL, is still a migration, just a lower-risk one.

Rankings usually drop for the same handful of reasons. Old URLs return a 404 because nobody built the redirects. The new site still carries a noindex tag or a robots.txt block left over from staging. Content that used to bring in traffic simply disappeared. Internal linking changed, and important pages are now buried deep in the structure. Or the server can’t keep up, because after a move Google crawls the site more heavily than usual for a while.

According to Google, a medium-sized site can take a few weeks or more before the new URLs replace the old ones in search results, and larger sites take longer. Some movement during that window is normal. A drop that sticks often points to a redirect or indexing problem, removed content, or too many changes at once. You will find the cause faster if you saved a baseline before the move. The table shows what each type of migration requires.

A complete list of old URLs

Start with an inventory. Google suggests pulling old URLs from several places: your sitemaps, server logs, analytics, the CMS, and the Links report in Search Console. Add a full crawl with an SEO tool. Don’t skip images, videos, PDFs, JavaScript and CSS files. They have URLs too, and downloadable files often earn backlinks. If only the domain changes and every path stays the same, one wildcard redirect rule can cover the move, but you still need the URL list for testing.

A baseline from Search Console and GA4

Export the pages with the most clicks and the queries you rank for from the Performance report in Search Console. Save the number of indexed pages from the Pages report, plus organic traffic and key events (conversions) from GA4. Pick 20–50 priority URLs: you will test them on launch day, and they will show problems first. Also save a list of sites that link to your old URLs.

A redirect map

Every old URL gets exactly one destination: the closest match in content, with a 301 or 308 status code. If you merge several pages into one, all of their old URLs can point to that new page. Don’t send everything to the home page. Google advises against irrelevant redirects like that and may treat them as soft 404s. If content is gone with no replacement, return a 404 or 410. You will find a redirect map template with an example in the next section.

A staging site Google can’t index

Build the new version on a staging site protected by a password or limited to specific IP addresses. A noindex tag works too. A robots.txt Disallow rule on its own is not enough: Google can still index a blocked URL if other pages link to it, and a crawler that is blocked never sees the noindex tag. Write down exactly what blocks indexing, because you will need to remove it on launch day. In WordPress, that is usually the “Discourage search engines from indexing this site” box under Settings → Reading. Crawl the whole staging site and test redirects, page speed and forms.

Canonical tags, hreflang, internal links and analytics

Every new URL should carry a self-referencing canonical tag. Point hreflang annotations to the new URLs in every language version at once: each version lists itself and all the others, or Google ignores the tags. You can add x-default for unmatched languages. Change internal links in the menu, footer and body copy to the new URLs before launch, so they don’t run through redirects. Carry over structured data, title tags and meta descriptions. Set up GA4 and Google Tag Manager so key events fire from day one. Prepare a new XML sitemap that lists only final destination URLs, and keep the old one for monitoring.

Search Console, server and page speed

Verify both the old and the new site in Search Console in every variant: www and non-www, HTTP and HTTPS. Make sure verification survives the move: the HTML file or meta tag has to be on the new site too. If you use a disavow file, upload it to the new property as well. Bought a previously used domain? Check it for manual actions and URL removal requests left by the previous owner. Make sure your server has headroom, because Google crawls the site more heavily than usual for a while after launch. On a large site, give your hosting provider a heads-up. On staging, measure speed in Lighthouse and compare it with the old version. After launch, check Core Web Vitals from real-user data: good values are LCP within 2.5 s, INP of 200 ms or less and CLS of 0.1 or less. For a deeper technical pass, use our technical SEO audit checklist.

All at once or in sections

Google recommends that small and medium sites move all their URLs at the same time. A large site can move one section at a time, starting with a part that rarely changes. That makes problems easier to spot and fix. Pick a date outside your peak season, and make sure your developer is available for the whole launch day.

A redirect map is a spreadsheet where each row pairs an old URL with its new one. Your developer uses it to set up the server rules, and you use it on launch day to check off tests. Here is an example for a company moving from old-company.com to new-company.com and cleaning up its service URLs at the same time.

Five rules that save weeks of cleanup:

• One hop. Each old URL goes straight to its final destination. Google recommends avoiding redirect chains and, where you can’t, keeping them short, ideally no more than three hops. Zero chains is safest.
• Permanent redirects. A 301 or 308 tells Google the new URL should become canonical. A temporary 302 or 307 doesn’t send that signal.
• Server-side. JavaScript redirects are a last resort. Google may never see one if rendering fails.
• One URL format. Decide once: trailing slash or not, lowercase, HTTPS, www or non-www. Every mismatch adds another hop.
• Keep them for the long haul. Google recommends keeping redirects as long as possible, generally at least a year. Don’t let the old domain go, or the redirects go with it.

Pick a low-traffic day and time, and avoid Friday afternoons. Order matters:

1. Deploy the redirects from your map before the old version stops responding.
2. Remove staging blocks: the noindex tag, the password, and any Disallow rules that were only needed during the build.
3. Check robots.txt on the new site. It should block only what really needs to stay hidden from crawlers. Keep the rules for Googlebot, Bingbot and AI search crawlers such as OAI-SearchBot and PerplexityBot the same as on the old site, unless you are changing them on purpose.
4. Check canonical tags. They must point to the new URLs, not to staging or the old domain.
5. Test your priority URLs: status code, redirect target, title, content and forms. The URL Inspection tool in Search Console or a simple script will do. Our free SEO audit checks up to 25 pages of the new site, including error codes, redirect chains, noindex and robots.txt.
6. Submit the new sitemap in Search Console and list it in robots.txt. You can keep the old one in Search Console for a few weeks: its indexed count should fall while the new one rises.
7. Report the domain change if you are moving to a different domain or subdomain. Use the Change of Address tool after the site has been moved and redirected, from a single Google account with owner access to both properties. Submit it for every variant of the old domain, www and non-www, because a domain-level request doesn’t cover its subdomains, www included. You don’t need it for HTTP to HTTPS, www to non-www, or path changes within the same domain.
8. Add the new site to Bing Webmaster Tools if you use it, and submit the new sitemap there.
9. Check analytics: confirm GA4 is collecting page views and that key events, such as form submissions, are recorded.

The simplest migration is a move to a new server: the URLs stay the same, and only the hosting provider, server or CDN changes. You don’t need redirects or the Change of Address tool. Google still recommends a few steps:

• Copy and test before the DNS change. Move the site to the new server and check pages, images, forms and downloads. Protect a test version on a temporary hostname with a noindex tag or IP-restricted access.
• A shorter TTL. At least a week before the move, lower the TTL on your DNS records, for example to a few hours. The new settings will reach users faster.
• Access for Googlebot. Make sure the firewall or DoS protection on the new server doesn’t block Googlebot. The URL Inspection tool in Search Console will show it.
• Search Console verification. The HTML verification file or meta tag has to be on the new server too.
• Blocks removed. Remove any build-time noindex and Disallow rules before you update the DNS records.
• Old hosting last. Watch traffic on both the old and the new server. Shut the old one down only when nobody, Googlebot included, is still using it.

Do the rest of the checklist, meaning the baseline, priority URL tests and monitoring, the same way as for any other migration. The PDF template has a separate “New server only” box for this.

The first few days surface technical bugs. The following weeks show whether Google has moved your visibility to the new URLs. Within 48 hours of launch, run a comparison crawl of the live site against your staging crawl. For the first 4 weeks, crawl the new site and review Search Console errors every day. After that, once a week, ideally on the same day, check:

• 404s and indexing. The Pages report in Search Console lists URLs with errors, excluded URLs and blocked URLs. Every new 404 on an old URL is a missing row in your redirect map.
• Sitemaps. The new sitemap should show a growing number of indexed URLs, and the old one a falling number. Redirect warnings in the old sitemap are expected.
• Server logs. Check your logs or the Crawl stats report to confirm Googlebot is fetching the new URLs and not hitting server errors.
• Traffic and rankings. Compare clicks, impressions and positions for priority queries against your baseline. Traffic to old URLs should fall while traffic to new ones rises.
• Redirect chains. Chains often appear after launch, for example old URL → HTTP → HTTPS → new URL. Collapse them to a single hop.
• Links. Fix any internal links that still go through redirects. Ask the owners of your most valuable backlinks to update them. Change the website URL in your Google Business Profile, on social profiles and in ad campaigns.
• AI answers. Once a month, check whether Google’s AI Overviews, ChatGPT and Perplexity still name your business when they answer your customers’ key questions. Our AI visibility checker can check this for you.

If traffic hasn’t recovered to pre-migration levels after 8–12 weeks, check every old URL from your redirect map with a crawler in list mode or a script: status code and target. Run the new site through our free SEO audit. The cause is usually missing redirects, removed content or blocked indexing.

• A staging noindex tag left on production. The site looks fine, but Google can’t index it. Make this the first test on launch day.
• Redirecting everything to the home page. Hundreds of old URLs pointed at the home page don’t pass on what they were about, and Google may treat them as soft 404s. Find the closest match, or return a 404 or 410.
• 302s instead of 301s. A temporary redirect doesn’t tell Google the new URL should replace the old one, so the old URL may stay in search results.
• Forgotten files and images. PDFs, images and old campaign pages often have backlinks. Without redirects, those links lead nowhere.
• Too many changes at once. New domain, new URLs, new content and a new design on the same day. Google suggests making changes like these one after another, for example the domain first and the design later. It also says that combining a move with a redesign of content and URL structure will probably cost some traffic, because Google may need to relearn and reassess individual pages. And when traffic drops, you can’t tell which change caused it.
• A server with no headroom. After a migration, Googlebot crawls the site more heavily than usual. A slow server or 5xx errors will drag out the transfer of visibility.
• No baseline. Without a pre-migration export, you can’t compare results or find the pages that lost traffic.
• Letting the old domain expire. Google recommends paying for the old domain for at least a year, so nobody else can buy it and misuse it. Once it lapses, the redirects stop working and so do the links pointing to old URLs.

Planning a new site? Add this website migration checklist to the project plan on day one, because the migration is easiest to plan alongside the design. See how we approach web design. If you would like a second pair of eyes on your plan before launch, order an SEO audit (from €350 net).

The template has a migration card, a box for hosting-only moves, three task lists (before the move, launch day and after the move), a redirect map, a weekly tracker and a post-migration issue log. Work through it in this order:

1. Describe the migration. On the migration card, tick what is changing: domain, URLs, CMS, protocol, server, or design only. Fill in the old and new domain and the launch date. The type of move decides which checklist items apply to you. For a hosting change alone, the “New server only” box plus the baseline, testing and monitoring is enough.
2. Assign owners. Next to each task, write who owns it (developer, SEO, content owner) and the due date. Tasks without an owner are the ones that get skipped.
3. Collect URLs and a baseline. Export a complete list of old URLs plus pre-migration data from Search Console and GA4. Note the export date and pick 20–50 priority URLs for testing.
4. Fill in the redirect map. For every old URL, add the destination URL, the status code and a priority. Mark URLs with traffic or backlinks as high priority and test them first.
5. Work through launch day in order. Follow the list as written: redirects, removing staging blocks, robots.txt, canonical tags, priority URL tests, sitemap, Search Console, Bing, analytics. Record each test result next to the task.
6. Keep monitoring. Crawl the new site and check Search Console errors daily for the first 4 weeks. Until week 12, log clicks, impressions, 404 errors and the number of indexed URLs from the new and old sitemaps once a week. Add every new 404 to the redirect map.