How to Handle SEO During a Website Migration

A migration’s organic risk is governed almost entirely by how much your URLs change. If the URLs move, signals have to be carried across to the new addresses; if they do not, the risk is small.

So the discipline of migration SEO reduces to one central deliverable and a few supporting moves: a complete 1:1 redirect map from every old URL to its closest new equivalent, using permanent redirects and never bulk-redirecting everything to the homepage; preserving on-page signals so the new pages look the same to Google as the old ones did; executing the Search Console Change of Address where the domain itself changes; and monitoring crawl, index, and rankings through the transitional dip that a real move produces. The work that preserves rankings happens before launch. Cleanup after the fact recovers far less than preparation prevents.

This post owns the at-launch execution and monitoring of a planned move where the decision to migrate is already made. The redesign-specific layer (staging swaps, template changes, the agency-pushback politics) is a separate concern, the post-launch signal-consolidation forensics when things go wrong is another, and the keep-versus-merge-versus-redirect decision after an acquisition is decided upstream. Here the decision is settled and the job is to ship the move cleanly.

Migration types and how much risk each carries

Not all migrations are equally dangerous, and the risk tracks how much URLs and signals move.

An HTTP-to-HTTPS migration is low risk: the protocol changes but the paths usually do not, and Google has long treated this as a routine, expected move. A platform change that preserves the same URLs is medium risk: the back end changes but the addresses do not, so the exposure is mostly in accidentally altering on-page elements or breaking things during the cutover. A domain change, a platform change that also changes the URL structure, a site restructure, or a consolidation of multiple sites is high to very high risk, because the URLs move wholesale and every signal attached to every old URL has to be carried across by redirects. Knowing which category you are in tells you how much redirect and monitoring work the move actually requires.

Pre-migration preparation

Almost all of the value is created before launch. Build a complete URL inventory by combining sources, because no single source is complete: crawl the current site, pull the indexed and ranking URLs from Search Console, add the URLs that drive traffic from analytics, and check server logs for what Google actually requests. The union of these is the set of URLs that must be accounted for.

Benchmark the current state before you touch anything: record current rankings, organic traffic, and indexed-page counts so you have a baseline to measure the move against and can tell a normal transitional dip from a genuine problem.

Then build the redirect map (covered below) and plan to preserve on-page signals: carry over titles, meta descriptions, heading structure, body content, and structured data so the new pages present the same relevance signals as the old ones. A page that is redirected correctly but stripped of its content and markup has still lost much of what made it rank. Plan the internal-link updates too, so the new site links to the new URLs directly rather than routing every internal click through a redirect.

The redirect discipline

The redirect map is the whole game. Map each old URL to the closest relevant new URL, one-to-one wherever a true equivalent exists. The cardinal error is bulk-redirecting everything to the homepage: Google treats a redirect to an irrelevant destination much like a 404, so mass redirects to the homepage throw away the equity and relevance of every page you point that way. When no exact equivalent exists, redirect to the most relevant remaining page (the parent category, the closest replacement), not the homepage.

Use permanent redirects. A 301 signals a permanent move and tells Google to transfer signals to the new URL and update the index; a 302 signals a temporary move and does not carry the same consolidation, so it is the wrong tool for a migration. Avoid redirect chains and loops, where one URL redirects to another that redirects again; redirect each old URL straight to its final destination. Google can follow a short chain, but every hop adds latency and risk, so keep chains as short as possible and ideally eliminate them.

Timing matters as much as accuracy. Keep the redirects live for a long time, not weeks. Google needs to re-crawl and reprocess every moved URL, which takes months, and external links to the old URLs persist for years; removing the redirects too early strands all of that. Plan to keep them for at least a year, and there is rarely a good reason to remove them at all.

Search Console handling

How you use Search Console depends on what moved. For a domain change, set up and verify the new domain as a property, then use the Change of Address tool in the old property to tell Google the site has moved; this helps Google transfer signals faster than relying on redirects alone. Submit updated XML sitemaps for the new property, and it can help to keep the old sitemap available temporarily so Google re-crawls the old URLs and discovers the redirects.

The host-only case is simpler. For an HTTPS or host change that stays on the same registered domain, verify the property for the new host or protocol and submit the new sitemaps; the Change of Address tool is specifically for moves between different domains.

Launch and monitor

At launch, the single most important check is that you did not accidentally ship a sitewide block. The classic migration catastrophe is the new site going live carrying the staging environment’s noindex tag or a Disallow: / in robots.txt that was meant to keep the staging site out of the index. Verify immediately that the live site is indexable and crawlable, before anything else. Then confirm the redirects actually fire, that old URLs return the right permanent redirect to the right new URL rather than 404ing or chaining.

Once live, monitor deliberately against your baseline. Watch crawl activity in the Crawl Stats report to confirm Google is picking up the new URLs and processing the redirects. Watch the Page Indexing report for the new URLs getting indexed and for spikes in error and exclusion states such as “Not found (404)” or pages caught by “Page with redirect” that should not be. Watch rankings and traffic against the benchmark you recorded.

Expect a transitional dip: even a well-executed migration usually sees a temporary drop as Google re-crawls, re-evaluates, and re-consolidates signals onto the new URLs, and it typically recovers over weeks to a couple of months. The dip is normal and not a reason to panic or to start reversing decisions; a dip that keeps deepening or does not recover is the signal to diagnose. Have a rollback or diagnosis plan ready so a genuine problem (missing redirects, a shipped noindex, a broken section) is caught and fixed rather than waited out.

If the migration touches international targeting or hreflang, those annotations have to be updated to point at the new URLs as well, but that is a cross-reference rather than something to re-teach here.

Sources

• Google Search Central, Site moves with URL changes: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
• Google Search Central, Redirects and Google Search: https://developers.google.com/search/docs/crawling-indexing/301-redirects