A migration changes what search has already learned about your site.

Google's site move guidance puts the URL mapping at the centre of the plan. In a simple move, such as a domain change, a wildcard redirect may be enough. In a more complex one you need a list of old URLs and a decided destination for each. Google suggests starting with the URLs that matter most: those in your sitemaps, those with the most traffic in server logs or analytics, and those with links shown in Search Console. It also says to include images, videos, JavaScript and CSS, which have to be moved like any other content.

The redirect type matters. Google's redirects documentation explains that a permanent redirect is used as a signal that the target should be canonical, while a temporary redirect is not. For a move, Google recommends server-side permanent redirects.

Planning also covers the new pages themselves. Google advises changing one thing at a time rather than combining a domain move, a CMS change and a new layout in one launch.

We cover planning and redirect mapping as part of our migrations work in Technical SEO.

• Use server-side permanent redirects (301 or 308) where possible.
• Redirect straight to the final destination. Googlebot can follow up to 10 hops, but Google advises keeping chains short, ideally no more than 3.
• Do not send many old URLs to one irrelevant page such as the new home page. Google says it can confuse users and may be treated as a soft 404.
• Give each new URL a self-referencing canonical, update hreflang annotations to the new URLs, and update internal links.

Google tells site owners to prepare the new site and test it thoroughly before the move starts. Several of its preparation items are things that can only be checked before launch. Some teams block all crawling or add noindex rules while a site is in development. Google says to prepare what the live robots.txt should look like once the move starts, and to keep a list of the URLs from which noindex must be removed. Content that is not coming across should return a proper 404 or 410 on the new site.

Search Console needs attention too. Google advises verifying both the old and new sites, including every variant such as www and non-www, and HTTP and HTTPS. It also notes that verification methods can break when the URL changes, so check they still work on the new site.

Capacity is easy to overlook. Google warns that it will temporarily crawl the new site more heavily than usual after a migration, because requests for old URLs are redirected to it on top of normal crawling.

To test the redirects, Google points to the URL Inspection tool for individual URLs and to command-line tools or scripts for large numbers of them. Our Web Development page states the same principle for builds: redirects mapped before launch and tested after.

We cover pre-launch testing as part of our migrations work in Technical SEO.

Google says to monitor traffic on both the old and the new site once the move starts. Ideally traffic falls on the old site and rises on the new one. In Search Console, it suggests submitting a sitemap of the new URLs alongside one of the old URLs: indexing of the old set should fall as indexing of the new set rises. Search Console may warn that URLs in the old sitemap redirect, which Google says is normal during a move.

Server access and error logs show what Googlebot is actually doing. Google recommends looking for crawling by Googlebot and for URLs that unexpectedly return error status codes.

The Crawl Stats report adds a view of how Google is crawling the site. Its host status shows whether Google met availability problems, including with robots.txt, DNS resolution and server connectivity. The report explains that if robots.txt does not return a valid file or a 404, Google will slow or stop crawling until it gets an acceptable response. The same report notes that each step of a redirect chain is counted as a separate request.

For a domain or subdomain change, Google also asks for a Change of Address request in Search Console for the old site. It says this tool is not needed for HTTP to HTTPS moves, www changes, or path changes within a domain.

We cover launch-day monitoring as part of our migrations work in Technical SEO.

Google says to expect temporary fluctuation in rankings after a significant change. For medium-sized sites it can take a few weeks or more before the new URLs gradually replace the old ones in results, and longer for larger sites. Recovery is therefore partly waiting, and partly finding the faults that stop the move completing.

Google lists the common mistakes that stop a new site being fully indexed: leftover noindex or robots.txt blocks, redirects pointing at URLs that do not exist, spikes in other crawl errors, insufficient server capacity, and sitemaps that still hold old URLs. For pages missing from Google on the new site, it suggests the URL Inspection tool.

Once the move is under way, Google recommends updating internal links, and asking sites that link to you to update theirs, prioritising by inbound visits. It advises keeping the redirects for as long as possible, generally at least a year, so Google can transfer signals to the new URLs.

We cover post-launch recovery as part of our migrations work in Technical SEO, for single sites and multi-market structures. For the international side, see International.