Migrations without traffic loss: a site-move runbook built on Google's and Bing's documentation

Google's own site-move guide lists the common migration mistakes, and they are boring ones: a migration-only noindex or robots.txt block left in place, and redirects pointing at URLs that don't exist on the new site. It separately warns against sending many old URLs to the homepage. All of these are preventable. This article turns that documentation, plus Bing's, into a runbook you can follow.

"Without traffic loss" is the goal, not a promise. Google says rankings may fluctuate while it recrawls a moved site, and no checklist removes that. What a careful migration does is keep the move from adding damage of its own.

Every claim below carries one of four labels: official guidance (a platform documenting its own product), research finding, our observation, or hypothesis. Register ids (MG-01 and so on) point to the source notes in our evidence register. The Google and Bing pages were checked on 2026-10-06. Re-check them before you rely on this after early 2027.

First, which kind of move is it?

Google documents two different procedures, and the steps differ (official guidance, MG-01, MG-02):

Move	Examples	Google guide	Change of Address tool?
URLs change	New domain, merging domains, HTTP to HTTPS, new URL paths	Site moves with URL changes	Only for domain or subdomain changes
URLs stay the same	New host, new CDN	Changing your hosting	No

Google's Change of Address tool is for moving from one domain or subdomain to another. Google says not to use it for HTTP to HTTPS, for www to non-www on the same domain, for moving paths within a site, or for hosting changes (official guidance, MG-07).

Two of Google's general rules shape the whole plan (official guidance, MG-01, MG-07):

• Change one thing at a time. If you plan a new domain, a new CMS and a new design, Google suggests doing them one after another. Its Change of Address page says combining a move with a redesign of content and URL structure will probably cost some traffic while Google reassesses the pages.
• Don't chain or pile up moves. You can't file a change of address from A to B and then straight away from B to C. Moving several sites into one at the same time can cause confusion and traffic loss. Google suggests moving them one at a time and waiting for traffic to settle between moves.

If your stakeholders want everything in one launch, that's a business decision. Write down that it goes against Google's guidance, so nobody is surprised later.

1. Inventory and baseline (before you change anything)

You can't map or measure URLs you never listed. Google's guide suggests several sources for the old URL list (official guidance, MG-01):

• your XML sitemaps,
• server logs and analytics for the URLs that get traffic,
• the Links report in Search Console for pages with internal and external links,
• your CMS's own list of content URLs,
• server logs for URLs visited at least once recently, over a period long enough to cover seasonal patterns,
• embedded files: images, videos, PDFs, JavaScript and CSS. Google says these move the same way pages do.

Bing's migration guide adds a useful check: look in your logs for URLs that crawlers have requested but that are missing from your sitemaps and internal links, and include them (official guidance, Bing Webmaster blog, 2020-12-17, MG-13).

Then record a baseline you can compare against later (our method, hypothesis, MG-17):

• Search Console Performance by page, for a window long enough to show your normal weekly cycle. If your traffic is seasonal, also keep the same period from last year. Export it. The table shows at most 1,000 rows, so on a big site export in slices, for example by folder (row cap: official guidance, M1-15).
• Indexed counts from the Page indexing report and from each sitemap in the Sitemaps report.
• Crawl stats: requests per day, response codes and host status (official guidance, MG-11).
• Conversions by landing page from analytics or your CRM. Traffic is the means, not the goal.
• Top linked URLs from the Links report. These are the redirects you most need to get right.

Also check settings that don't move on their own (official guidance, MG-01): verify every variant of both old and new sites (www and non-www, HTTP and HTTPS); make sure verification still works after the move; set crawl rate to let Googlebot decide on both sites; re-upload any disavow file to the new property. If the new domain was bought, check it for manual actions and leftover URL removals from the previous owner.

2. The redirect map

Map each old URL to the new URL that best replaces it. The map is the migration. The rules in Google's documentation are clear:

• Use server-side permanent redirects: 301 or 308. Google treats these as a strong signal that the target should be canonical. 302, 303 and 307 are temporary: Google follows them but doesn't use them as that signal, so the old URL may stay in results (official guidance, redirects, page dated 2026-04-14, MG-03; HTTP status codes, MG-04). An instant meta refresh counts as permanent. JavaScript redirects are a last resort, because Google might never see one if rendering fails (MG-03).
• Permanent redirects don't cost PageRank. Google says this directly in its site-move guide (official guidance, MG-01). Some practitioners argue that every redirect loses a little equity and drags results for months. Google's documentation says otherwise on PageRank, though it still expects ranking fluctuation during a move. Treat the "redirect tax" as an untested claim.
• Redirect to the final URL. Googlebot follows up to 10 hops, but Google advises going straight to the destination. If you can't, keep chains short: ideally no more than 3, and fewer than 5 (official guidance, MG-01, MG-04). Old redirects from past migrations count. Update them to point at the new final URLs, or you've built a chain without meaning to.
• Don't send many old URLs to one unrelated page, such as the new homepage. Google says this can confuse users and may be treated as a soft 404 (official guidance, MG-01). If several old pages were merged into one new page, redirecting them all to that page is fine.
• Removed content should return 404 or 410. If a page has no equivalent on the new site, let it go. Google drops URLs that return 4xx from the index over time (official guidance, MG-01, MG-04).
• Simple domain moves can use a pattern. If paths don't change, a wildcard rule from old host to new host may be all you need (official guidance, MG-01).

A map row needs more than two columns. A layout that works (our method, hypothesis):

Old URL	Status	New URL	Match type	Priority signal	Tested
/pricing.html	301	/pricing	one-to-one	top-20 by clicks; 14 linking domains	live 200, 1 hop
/blog/old-guide	301	/guides/setup	merged (3 into 1)	links from docs	live 200, 1 hop
/promo-2023	410	—	removed, no equivalent	none	410

The priority column tells you what to test first and what to watch after launch.

3. Staging checks

Build and test the new site before any redirect goes live. Google's guides cover this (official guidance, MG-01, MG-02):

• Keep staging out of the index. Restrict access by IP or login, or add noindex. Some teams block all crawling in robots.txt during development. If you do, write down what the production robots.txt must say, and list every URL whose noindex you'll remove at launch.
• Check that Googlebot can reach the new infrastructure. Use URL Inspection on a verified test hostname, and check that firewall or DDoS protection isn't blocking Googlebot.
• Update what points at URLs. Each new page should have a self-referencing rel="canonical". Update hreflang annotations to the new URLs. Change internal links to the new URLs directly, so they don't depend on redirects.
• Prepare a new sitemap listing only the new canonical URLs, with absolute URLs (official guidance, sitemaps, MG-06). Keep the old sitemap file too: you'll use it for monitoring.
• Plan for heavier crawling. Google says it crawls a moved site more heavily than usual for a while, because redirected crawls of the old site add to normal crawling. Make sure the new server can take it, and warn your host if the site is large.
• For domain moves, keep the old domain's verification and Search Console access. You'll need them for the Change of Address tool and for monitoring.

Don't send mixed signals about the canonical. Redirects and rel="canonical" are strong signals and a sitemap is a weak one. Google says they work best when they agree, and warns against pointing them at different URLs. It also says not to use robots.txt or noindex to choose a canonical (official guidance, canonicalization, page dated 2026-07-10, MG-05).

Then crawl staging with a crawler of your choice and run the full redirect map against it with a script. For each row, check: the status code matches the map, there's one hop, and the destination returns 200 with a self-canonical and no noindex (our method). Google's guide recommends command-line tools or scripts for testing redirects in bulk (MG-01).

4. Launch day

Google suggests launching at a time when traffic is usually low, if your traffic has regular dips (official guidance, MG-01). For large sites, it suggests trying the move on one section first. That section should be one that changes rarely, and Google warns that a test section won't show every problem a full move will. For small and medium sites, Google recommends moving everything at once, which helps it detect the move faster.

For a hosting change with no URL change, Google suggests lowering DNS TTL to a few hours at least a week before the move (official guidance, MG-02).

The launch-day order, from Google's guides (official guidance, MG-01, MG-02, MG-07):

1. Remove migration-only robots.txt blocks and noindex rules on the new site.
2. Turn on the redirects (or switch DNS for a hosting change).
3. Check that canonicals on the new site point at new URLs.
4. Test redirects: URL Inspection for key URLs, a script for the full map. Note that Google's inspection tools don't follow redirects, so inspect old and new URLs separately (MG-04, MG-10).
5. For a domain or subdomain change, file the Change of Address request from the old property, for every verified variant of the old domain, including www, non-www and subdomains you don't use. The tool requires the homepage to redirect with a 301, and Google also recommends 301s for the other canonical pages. It checks a few pages for 301s before accepting the request (MG-07).
6. Submit the new sitemap in Search Console. Google says you can remove the old sitemap at this point. If you want to watch the old URLs drain, the site-move guide suggests submitting both sitemaps you saved. Warnings that old-sitemap URLs redirect are expected (MG-01).
7. Start updating links: internal links first, then the most valuable external links from your saved list, social profiles and ad landing pages (MG-01).

For Bing, a 2020 Bing Webmaster blog post describes the same core steps: unblock crawling, add 301s, then tell Bing about the move with its Site Move tool (official guidance, MG-13). I couldn't confirm that the tool still exists. Its old help page now returns a 404. A forum user in 2021 posted what they said was Bing support's reply that the tool was removed and to rely on 301s. That's second-hand, so label it unverified (MG-14). Check your Bing Webmaster Tools account before you plan around it. Either way, the 301s do the work. Bing also lets you submit URLs and supports IndexNow for telling it about changed URLs (MG-13).

5. Monitoring

Google describes what a healthy move looks like in Search Console (official guidance, MG-01, MG-09):

• Sitemaps report: the new-URL sitemap starts near zero indexed and climbs. The old-URL sitemap starts high and falls toward zero.
• Page indexing report: indexed counts fall on the old property and rise on the new one. On the old property, "Page with redirect" is expected. That status means a non-canonical URL that redirects. Watch for spikes in "Not found (404)", "Soft 404" and "Redirect error". Redirect error covers chains that are too long, loops and bad redirect URLs.
• Performance report: impressions and clicks shift from old URLs to new URLs as pages get indexed.

Also watch:

• Server logs for Googlebot crawling, unexpected error codes, and normal user traffic. Google's most common mistake list includes redirects to wrong, non-existent URLs (MG-01). Bing's guide suggests watching logs often in the first days and daily for at least three months (MG-13).
• Crawl stats on the new property: Google says each redirect hop counts as a separate request, and expects 301 responses to be common during a move (official guidance, MG-11).
• URL Inspection for any important page that seems to be missing: check the Google-selected canonical. It only appears in the indexed data, not in a live test (official guidance, MG-10).
• Conversions by landing page. Map old landing pages to new ones, so you compare the same content before and after rather than raw URL lists (our method).

How long to watch? Google gives no fixed period. It says a move is complete for Googlebot only after it has visited every old and new URL at least once, which depends on site size and crawl speed (official guidance, MG-01). Some practitioners suggest a 6 to 12 month measurement plan. That's a reasonable planning window but not a documented one (hypothesis, MG-17). A practical rule: keep watching until the old sitemap's indexed count is near zero, Googlebot rarely requests old URLs, and the new site's clicks for mapped pages have held steady across a full business cycle.

What Google says normal fluctuation looks like

This is where migration advice most often makes things up. Here's what Google's documentation actually says, and nothing more (official guidance, MG-01, MG-02, MG-07, MG-12):

• Ranking may fluctuate temporarily while Google recrawls and reindexes. Google calls this normal and says rankings settle over time.
• For medium-sized sites, it can take a few weeks or more before Google mostly shows new URLs instead of old ones. Larger sites take longer. Speed depends mainly on the number of URLs and server speed. Submitting a sitemap can help.
• The move happens URL by URL. You'll see a mix of old and new URLs in results for a while. Google doesn't erase the old site from the index. Old URLs can keep showing if they're available and have no equivalent on the new site.
• Crawling of the new site goes up for a while.
• After a hosting change, a temporary drop in crawl rate right after launch is normal, followed by a steady rise over the next few days, possibly above previous levels.
• Change of Address effects last 180 days. For that period Google prioritizes crawling the new site, forwards signals and prefers the new site when choosing canonicals. After that, Google treats the old site as unrelated if it's still crawlable.
• Small position changes can happen any time, including recovery without you doing anything. Google's guide to traffic drops advises against radical changes to pages that already perform well. It also points to the Search Console data anomalies page, since a drop may be a reporting issue.

Notice what isn't there: no percentage of "expected" traffic loss, and no number of weeks for recovery. If someone gives you one, it's their estimate, not Google's.

Google also gives two different minimums for how long to keep redirects. The site-move guide says at least a year, and to consider keeping them indefinitely for users. The Change of Address page says at least 180 days, and longer while Google Search still sends traffic to the old URLs (MG-01, MG-07). Bing's 2020 guide says at least one to two years (MG-13). Use the longest of these. Keep paying for the old domain too: Google recommends at least a year, so nobody else can buy it and abuse it (MG-07).

Rollback criteria

None of the Google or Bing pages I checked gives rollback thresholds. What follows is our method, labeled hypothesis (MG-16). Agree on it before launch, so the decision on the day isn't made in a panic.

Roll back or fix forward immediately when the failure is technical and you can see it:

• The new site serves errors or times out for users or Googlebot.
• A large share of the redirect map is wrong: loops, chains, 404 destinations or the wrong targets.
• The new site is accidentally blocked by robots.txt or noindex, and you can't fix it within hours.
• Conversions on the new site fail, such as broken checkout, signup or forms.

Most of these are better fixed forward than reverted. Reverting is a second migration. Google says to use permanent redirects only when you're sure they won't be reversed (MG-03), and reversing a Change of Address has its own steps (MG-07): remove the 301s, add 301s from new back to old, then cancel the move in the tool within 180 days. If you need to undo a move, follow those steps fully rather than half-reverting.

Don't roll back just because rankings move in the first weeks while the technical checks pass. Google describes that as expected (above). Before you decide, check whether a Google update was announced in the same window, and compare the dip with your seasonal baseline.

Investigate before deciding when, after Google has had time to process the move, mapped pages on the new site keep getting far fewer clicks than the same pages before the move did, and the technical checks are clean. Look at the canonical Google chose, content and template changes made at the same time, and internal links. If you changed several things at once, you won't know which one caused it. That's why Google recommends changing one thing at a time.

Migration checklist

Phase	Check	Source
Plan	Move type identified (URLs change or hosting only); one change at a time	MG-01, MG-02, MG-07
Plan	Launch timed for a usual traffic dip; large sites piloted on a section	MG-01
Inventory	Old URL list from sitemaps, logs, analytics, Links report, CMS, including images, PDFs, JS and CSS	MG-01, MG-13
Baseline	Performance by page, indexed counts, crawl stats and conversions exported	MG-11, M1-15
Search Console	All variants of old and new sites verified; verification survives the move; crawl rate on default; disavow re-uploaded; new domain checked for manual actions and removals	MG-01
Redirect map	Every old URL mapped to its best equivalent, or marked 404/410	MG-01, MG-04
Redirect map	Server-side 301/308; no temporary redirects for a permanent move	MG-03
Redirect map	One hop to the final URL; old redirects updated; no loops	MG-01, MG-04
Redirect map	No mass redirects to the homepage	MG-01
Staging	Not indexable (IP, login or noindex); Googlebot can reach new infrastructure	MG-02
Staging	Self-canonicals, hreflang and internal links use new URLs	MG-01, MG-05
Staging	New sitemap with absolute canonical URLs; old sitemap saved	MG-01, MG-06
Staging	Server capacity for heavier crawling; firewall allows Googlebot	MG-01, MG-02
Staging	Full redirect map tested by script	MG-01
Launch	Migration-only robots.txt and noindex removed	MG-01, MG-02
Launch	Redirects live (or DNS switched, TTL lowered a week ahead)	MG-01, MG-02
Launch	Change of Address filed for every old domain variant (domain moves only)	MG-07
Launch	New sitemap submitted; Bing account checked for move tools; IndexNow if used	MG-01, MG-13, MG-14
Launch	Internal links, top external links, profiles and ads updated	MG-01
Monitor	Sitemaps and Page indexing on both properties; 404, soft 404 and redirect errors	MG-01, MG-09
Monitor	Logs and crawl stats; URL Inspection for missing key pages	MG-10, MG-11
Monitor	Clicks and conversions for mapped page pairs against the baseline	MG-17
Aftercare	Redirects kept at least a year (longer is better); old domain renewed	MG-01, MG-07, MG-13
Aftercare	Rollback criteria agreed before launch	MG-16

Measuring the result honestly

A migration changes everything at once for the whole site, so there's rarely a clean control group. A before/after comparison alone won't tell you the move caused a change. Seasonality, Google updates and demand all move at the same time. Three habits help (our method, hypothesis):

1. Compare mapped pairs, not totals. Add old-URL and new-URL clicks together for each mapped page, so URL churn doesn't look like loss.
2. Compare with last year for the same weeks if traffic is seasonal, and with branded search demand (for example in Google Trends), which a migration shouldn't change much.
3. Log everything that changed. Content edits, template changes, navigation, launches and announced Google updates, with dates. If the list is long, report what you saw as an observation, not a result.

If you'd rather not run this alone, RankPropel can scope a migration review as part of the audit and baseline sprint, which already covers redirects and indexing signals. The runbook works the same either way. For a worked example of repairing a broken homepage redirect, see our technical SEO case study.

Sources

Google Search Central: site moves with URL changes (page dated 2026-08-20), changing your hosting (2025-12-10), redirects and Google Search (2026-04-14), HTTP status codes and network errors (2026-02-04), canonicalization methods (2026-07-10), build and submit a sitemap (2026-07-08), debugging drops in Search traffic (2025-12-10). Search Console Help: Change of Address tool, Page indexing report, URL Inspection tool, Crawl stats report, Performance report. Bing Webmaster blog: Website migration with Bing (2020-12-17). All retrieved 2026-10-06.