Website Migration SEO Checklist: Move a Site Without Losing Visibility

A website migration is any change that moves your site to new addresses or a new setup: a new domain, a switch from HTTP to HTTPS, a new URL structure, a new platform or a redesign that renames pages. Each of these changes the addresses that search engines, bookmarks and other sites already know. If the old addresses stop working or the new ones are blocked, visitors and crawlers hit dead ends.

This website migration SEO checklist follows Google's published site move process and adds the practical details a team needs on the day. It is for site owners, project managers and developers who are planning a move. By the end you will have a URL map, a redirect plan, a crawl-safety review, a launch-day sequence and a monitoring routine.

A careful migration protects what you have. It cannot promise that traffic stays the same. Google notes that after a move you should expect fluctuation, and that medium-sized sites can take a few weeks or more to show the new URLs, with larger sites taking longer.

Before you begin

You will need:

A project owner and a list of everyone who touches the site: developers, content editors, the hosting provider and whoever manages DNS.
Access to Google Search Console for the old and new sites, with every variant (www and non-www, HTTP and HTTPS) verified.
A full list of current URLs. Plan for several days of preparation, and more for large sites.
A rollback plan. Know how to turn off the redirects and restore the old site if something breaks.

Google's general advice is to change one thing at a time and to time the move for a lower-traffic period if you can. If you are changing the domain and redesigning the site, do them separately. For large sites, move one section first to test the process. Choose a section that changes less often, since moving more pages raises the chance of new problems.

If your move changes the domain name only, see Change Domain Name SEO. If it is only HTTP to HTTPS, see HTTP to HTTPS Migration. If the URLs do not change at all, such as a move to new hosting, most of this list does not apply.

Step-by-step instructions

Step 1: Record the starting point

Before changing anything, capture how the site performs so that you can compare afterwards.

Export the current XML sitemap and a crawl of the live site.
Save Search Console data: the Performance report for the main pages and queries, and the page indexing numbers.
Record analytics traffic by page, and check how seasonal the period is.
Save the existing redirects, robots.txt and any server configuration.
Note the pages that bring in the most visitors and the pages with the most external links. Google's Links report is one source.

What success looks like: you have dated exports of crawl, sitemap, Search Console and analytics data stored outside the site.

Step 2: List every old URL

Build a complete list of old addresses. Google suggests gathering them from your sitemaps, your high-traffic pages, the Links report, your CMS and your server logs, choosing a log period that reflects seasonal traffic. Include images, videos, PDFs, JavaScript and CSS files if they have their own addresses and bring traffic or links.

Remove duplicates and normalise the list so each address appears once. Group it by type: pages, media, downloads and feeds.

What success looks like: a single de-duplicated list of old URLs with a note of where each came from.

Step 3: Map each old URL to a new one

For each old address, decide where it goes. Use a spreadsheet or database with three columns: old URL, new URL and action. For most pages the action is a permanent redirect to the page that now holds the same content. If several old pages merged, send them all to the new merged page. If a page has no equivalent and no value, plan to return 404 or 410. Google's guidance says to return a 404 or 410 for deleted or merged content on the new site and to avoid irrelevant redirects, such as sending many pages to the home page.

Check that every target exists and returns 200. A redirect to a missing page is a common migration error.

What success looks like: every old URL has a mapped target or a reasoned decision to retire it.

Step 4: Prepare the new site

On the new site, before launch:

Set up the pages, images and downloads, and make sure the content is complete.
For HTTPS, obtain and install the certificates. See HTTP to HTTPS Migration.
Add a self-referencing canonical tag to each new page, update hreflang annotations to the new URLs and update internal links to point at the new addresses.
Prepare the new XML sitemap with the new URLs only; see How to Create a Valid XML Sitemap.
Prepare robots.txt for launch. Google lists development blocks left in place as a common migration mistake. Make sure staging rules are lifted when the move starts, and prepare a list of URLs whose noindex rules must be removed. See Preventing Staging Site Indexing.
Make sure the server can handle more load. Google notes that Googlebot crawls more heavily after a migration.

Keep the staging site private while you build it. Block it with a login, not only with robots.txt. Google explains that a robots.txt block hides the noindex tag from crawlers and does not reliably keep a page out of results.

What success looks like: the staging site passes a full crawl with correct canonicals, internal links and no leftover blocks that would carry over to production.

Step 5: Set up Search Console and analytics

Verify both the old and new sites in Search Console, including all variants. Confirm that your verification method still works on the new site, whether it is a file, a meta tag or an analytics-based method. Review settings on the old property, such as crawl rate, and re-upload any disavow file to the new property if you use one. Set up analytics for both sites so you can compare.

If you bought the new domain, check that it has no manual action and no leftover URL removals from a previous owner. Google lists this among its preparation steps.

What success looks like: both properties are verified and reachable by the right people.

Step 6: Launch the redirects

Launch day has an order. Google's site move process puts redirects at the centre.

Turn on the server-side permanent redirects from the URL map. Use 301 or 308. Google treats client-side redirects as a last resort.
Check that canonical tags and robots meta rules point to the new URLs, and that no noindex was carried over.
Test a sample of redirects with the URL Inspection tool and with scripts.
If the move changes the domain or a subdomain, submit the Change of Address in Search Console for the old site. Google says not to use it for HTTP to HTTPS, www to non-www on the same domain or path changes.
Submit the new sitemap and remove the old one.
Update links you control: internal links, profiles, ads and email templates.

For a small or medium site, Google suggests moving all URLs at once. For a large site, it suggests moving in sections, which makes problems easier to find.

Aim for one hop. Googlebot can follow up to 10 hops in a redirect chain, but Google's guidance is to aim for ideally no more than three and fewer than five. Fewer is better; see Redirect Chains, Loops, and Incorrect HTTP Status Codes.

What success looks like: a sample of old URLs each reaches its mapped new page in one permanent redirect and ends in 200.

Step 7: Test the launch

Immediately after launch, check:

Old URLs from the map return the expected redirect.
The new pages return 200 with the right canonical, title and content.
robots.txt on the new site allows crawling, and key pages are not noindex.
The new sitemap loads and lists only live canonical pages.
Images, scripts and stylesheets load, with no mixed content or broken links.
Forms, search, checkout and other functions work.
Error pages return a real 404 status. See HTTP 500 and 503 Errors if the server struggles.

Run a crawl of the new site and compare it with the pre-launch crawl.

What success looks like: the crawl shows no broken internal links, no loops and no accidental blocks.

Step 8: Monitor for weeks, not days

Google recommends watching several reports after a move.

Sitemaps report. Expect some redirect warnings for the old sitemap at first. Indexed pages should move over time from old URLs to new ones.
Page indexing report. Look for a fall in old-site indexing, a rise in new-site indexing and new errors.
Performance report. New URLs should start to get impressions and clicks.
Server logs and analytics. Check Googlebot activity, unexpected error codes and traffic shifting from old to new.

Expect fluctuation. Googlebot has to visit every old and new URL at least once, and there is no fixed crawl frequency, so patience is part of the process. Fix issues you find, such as leftover noindex, redirects to nonexistent URLs, crawl errors and outdated sitemaps, which Google names as common mistakes.

What success looks like: reports trend towards the new site, and problems are fixed within days of showing up.

Step 9: Keep the redirects

Google advises keeping redirects for at least one year and considering keeping them indefinitely. For a domain change that uses the Change of Address tool, the tool's help page says to keep them at least 180 days. Keep the old domain registered so that you control it and the redirects can work.

What success looks like: the redirects are scheduled for review in a year, not removed after a month.

Final verification checklist

Dated exports of the old site's sitemap, crawl, Search Console data and analytics are saved.
Every old URL is mapped to a new URL or a planned 404 or 410.
The new site has self-referencing canonicals, updated hreflang and updated internal links.
No staging noindex or robots.txt block carried over to production.
Old and new sites are verified in Search Console, with all variants.
Server-side permanent redirects work and reach the target in one hop.
The new sitemap is submitted and the old one removed.
Change of Address was used only for a domain or subdomain move.
Reports are reviewed over several weeks, with problems logged and fixed.
Redirects stay in place for at least a year.

Common mistakes to avoid

Changing everything at once. Change one thing at a time so you can find the cause of problems.
No URL map. Without a map, redirects get missed or sent to irrelevant pages.
Sending all old URLs to the home page. Redirect each page to its closest equivalent.
Leaving noindex or a robots.txt block on the new site. Check these first when pages vanish.
Redirecting to pages that do not exist. Test every target.
Long chains. Point old addresses directly at the final one.
Outdated sitemaps. Replace the old sitemap with the new one.
Removing redirects early. Keep them at least a year.
Using Change of Address for the wrong move. It is for domain or subdomain changes only.

Frequently asked questions

How long does a migration take to settle?

Google says medium-sized sites can take a few weeks or more to show the new URLs, and larger sites take longer. There is no fixed time.

Will I lose traffic?

Some fluctuation is normal. Google notes that permanent redirects do not cause a loss in PageRank, but a poor migration with broken redirects, blocks or missing pages can lose visibility. A careful process reduces that risk and does not remove it.

Do I need to use the Change of Address tool?

Only when the domain or subdomain changes, such as example.com to example.net. Google says not to use it for HTTP to HTTPS, www to non-www or path changes.

Should I keep the old site online?

Keep the old domain registered and the redirects live. The old site's content should not remain accessible as a duplicate once the redirects are in place.

Can I do a migration in stages?

Yes. Google suggests moving a section first as a test, then the rest. Large sites often move in sections.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.