How to migrate a website without losing SEO: what Google and Bing document

Rankings are lost in a move when addresses change and nothing tells search engines where each one went, or when a page's content does not arrive. Redirect every old address to its nearest equivalent with a 301, carry the content across, and expect a dip while the site is recrawled.

By: WP Ministry
Published: October 8, 2026

In short

List every address the old site answers at before anything is built, and record what each page says about itself. That list is what you test against afterward.
Give each old address one new address, the nearest equivalent page, with a 301. Many addresses sent to the home page may be treated as a soft 404.
Before the switch, check that no noindex and no robots.txt block is left from staging, and that canonical tags name the new addresses.
Test every old address after launch. Each should answer 301 once and land on a page that answers 200.
A dip while Google recrawls is what its own documentation describes. It gives a few weeks for most pages of a small or medium site.
Keep the redirects for at least a year, and change one thing at a time where you have the choice.

A search engine knows your site as a set of addresses. Rankings are lost in a move for two reasons: an address changes and nothing tells the engine where it went, or the address is forwarded and what was on the page does not arrive. Both are preventable.

What you cannot prevent is a dip while the site is recrawled. Google's documentation says to expect ranking fluctuation during a move, and that for a small or medium-sized site it can take a few weeks for most pages to move. It also says that 301 and other permanent redirects do not cause a loss in PageRank.

This page follows what Google and Bing document, and says where they are silent. It covers moves that change addresses: a new platform, a redesign with new addresses, a new domain. A move to a new host that keeps every address needs none of the redirect work, and the website migration checklist has the order for both kinds, DNS and email included.

Before: list every address that matters

Google describes a move as happening one address at a time, and counts it complete once its crawler has visited every old and every new address at least once. So the first job is a list. Google's guide to moving a site names where to find the addresses:

The sitemap. Your most important addresses are likely in it. WordPress has built one at /wp-sitemap.xml since version 5.5.
Analytics or the server's logs, for the addresses that get the most visits. Pick a period long enough to cover a seasonal page.
The Links report in Google Search Console, for the pages that other sites and your own pages link to.
The old platform itself, which can usually list everything it publishes.
Images, videos and downloads such as PDFs. Google says these move the same way as pages, because they may already get visits from search or from links.

Two more are worth adding. The Performance report in Search Console has a Pages tab that lists the addresses searchers saw and clicked, and it can be exported. A crawler, a program that follows the site's own links the way a search engine does, finds linked pages that appear in no report.

For each address, record its title, meta description, main heading and canonical tag, whether it carries structured data, and which pages link to it. The table further down says why each matters. Keep the list: it is what you test against after launch.

If the site is not in Search Console yet, verify it now. When the domain is changing, Google asks you to verify the old and the new site in every variant: with and without www, on http and on https.

Map each old address to one new address

Give every row of the list one of three outcomes.

It stays where it is. Nothing to do. Bing's guidelines say to avoid unnecessary address changes.
It moves. Redirect it to the page that replaces it: the nearest equivalent, not the home page.
It goes, with nothing to replace it. Let it answer 404 or 410. Google's guide says deleted content should return one of those, and Google removes an address that does from its index.

Google's guide is direct about the shortcut. Do not redirect many old addresses to one irrelevant destination such as the home page: it can confuse visitors and might be treated as a soft 404, which Google excludes from Search. The exception is real consolidation. If several old pages were merged into one, redirect them all to it.

Three more rules come from the same documentation:

Use a permanent, server-side redirect. Google recommends a 301 or a 308, and treats a 302 as a weak signal that leaves the old address in results. Bing's guidelines say to use a 301 for a permanent change, a 302 only for a change of less than two days, and a redirect instead of a canonical tag when content moves.
Go straight to the final address. Google's crawler follows up to 10 hops, and Google still advises redirecting to the final destination directly. Where a chain cannot be avoided, keep it short: ideally no more than 3 hops and fewer than 5.
A redirect made inside the page is a fallback. Google supports meta refresh and JavaScript redirects and recommends them only when a server-side redirect is not possible.

The redirect map builder turns the two columns into redirect rules and points out chains, loops and duplicates. Where the rules go on a WordPress site is covered in how to set up redirects in WordPress. Which addresses a platform lets you keep is in the guides for Wix, Squarespace and Shopify.

What has to arrive on each new page

A redirect tells the engine where a page went. What it finds there still has to be the page it knew. Google's help for its Change of Address tool says that a move combined with a redesign of the content and the address structure will probably cost some traffic, because Google may need to relearn and reassess the individual pages.

What	What the documentation says	Check on the new page
The content	Google uses the canonical page as the main source for evaluating content and quality	The same text, not a shortened version
Title	Google uses the `<title>` element as a source for the title link in results, and asks for a distinct one on every page	Carried over, not replaced by the theme's default
Meta description	Google sometimes uses it for the snippet, when it describes the page better than the page's own text	Present and specific to the page
Headings	Google also reads the main visual title and heading elements such as `<h1>` when it picks a title link. Bing asks for a logical heading hierarchy	One clear main heading that matches the old one
Canonical tag	Google says each new address should carry a canonical tag that names itself, and treats the tag as a strong signal	It names the page's own new address, not a staging or an old one
Structured data	It describes the page's content and can enable rich results. It must match what the visitor sees	Rebuilt on the new platform, then run through Google's Rich Results Test
Images and alt text	Google calls alt text the most important attribute for telling it about an image, and says image addresses move the same way as page addresses	Files moved, old image addresses redirected, alt text carried over
Internal links	Google says to change internal links from the old addresses to the new ones	Menus and links in the text point at final addresses, not at redirects
hreflang, if the site has languages	Google says to update the annotations to the new addresses. Each version lists itself and every other version, and a pair that does not point both ways is ignored	Every language version updated together
Robots rules	Google says the new site's robots.txt should reflect what you want blocked from crawling	Pages that were kept out of search on purpose still are, and nothing else is

For a store, WordPress vs Shopify for SEO sets out how much of this list each platform lets you control.

Launch day, in order

The new site is built somewhere private, hidden from search engines. Launch is the moment that block comes off and the old addresses start to forward. The commands below run in a terminal on macOS or Linux. Replace example.com with your domain.

1
Step 1: Take the staging block off the new site
Google's guide names this first among the common mistakes: a noindex or a robots.txt block that was only needed during the build and is still there after it. In WordPress, the block is the box "Discourage search engines from indexing this site" under Settings, then Reading. Untick it, then check what a page serves. The first command prints a line only if the server sends an X-Robots-Tag header. The second prints the page's robots tag if it has one. Neither line should contain the word noindex.
bash
```
curl -sI https://example.com/ | grep -i "x-robots-tag"
curl -s https://example.com/ | grep -i -o "<meta[^>]*robots[^>]*>"
```
2
Step 2: Read robots.txt
A line that says Disallow: / under User-agent: * asks every crawler to stay out of the whole site. Google's guide says it is fine to have no robots.txt at all, provided the address then answers 404. A robots.txt that answers with a server error is different: Google slows or stops crawling until it gets an acceptable answer.
bash
```
curl -s https://example.com/robots.txt
```
3
Step 3: Check that canonical tags name the new addresses
A site built at a temporary address can carry that address into every canonical tag. Once the new site is set to its real domain, run this on a few pages of each kind. The address in href should be the page's own final address.
bash
```
curl -s https://example.com/new-page/ | grep -i -o "<link[^>]*canonical[^>]*>"
```
4
Step 4: Test the redirects on the new server
When the domain stays the same, the redirects live on the new site, so they can be tested before any visitor arrives. This is the full form of the command from the note above. A certificate error usually means the new server has no certificate for the domain yet, which has to be fixed before the switch.
bash
```
curl -sI --resolve example.com:443:203.0.113.10 https://example.com/old-page/
```
5
Step 5: Switch, then ask one old address what it answers
Change the DNS or publish the new site, as the checklist describes. Then ask an old address for its headers. -I fetches the headers only, and curl does not follow a redirect unless told to, so you see the first answer on its own. The first line should say 301. The location line should hold the new address exactly as the site serves it: https, the right host name, the final slash as your pages have it.
bash
```
curl -sI https://example.com/old-page/
```
6
Step 6: Count the hops
-L follows the redirects to the end, and -w prints what happened. You want one redirect and a status of 200. Two or more redirects is a chain. A final status of 404 means the map points at a page that is not there.
bash
```
curl -sIL -o /dev/null -w "redirects: %{num_redirects}  final: %{url_effective}  status: %{http_code}\n" https://example.com/old-page/
```
7
Step 7: Test the whole list
Save the old addresses from your list in a file named old-urls.txt, one full address to a line. This prints each one's status and where it sends you. Every line should start with 301, apart from the addresses you chose to retire, which should start with 404 or 410. It needs curl 7.75 or later.
bash
```
xargs -n 1 curl -s -o /dev/null -w "%{http_code} %{url} -> %{redirect_url}\n" < old-urls.txt
```
Step 8: Submit the new sitemap
Submit a sitemap of the new addresses in Search Console's Sitemaps report. Google says a sitemap helps it discover the new addresses faster. On the old sitemap, Google's guide says two things. You can remove it at this point, since Google will use the new one. Or you can leave it submitted to watch the move: its count of indexed pages falls toward zero while the new one's rises, and the warnings it shows about redirecting addresses are normal and can be ignored.
Step 9: If the domain changed, file a Change of Address
Search Console's Change of Address tool is only for a move from one domain or subdomain to another. Google says not to use it for a move from http to https, between www and no www, or between paths on the same domain. Use it after the redirects are in place, from the old site's property, and for every variant of the old domain. It tells Google to favor crawling and indexing the new site and forwards signals to it for 180 days.
Step 10: Tell Bing
Bing's list of webmaster tools has no change-of-address tool. Its guidelines ask for 301 redirects, and for sitemaps that list only current addresses, with redirected ones removed promptly. Submit the new sitemap in Bing Webmaster Tools. Bing also learns of changed addresses through IndexNow, whose documentation says redirected addresses should be submitted, and that submitting every address is acceptable after a migration.
Step 11: Update the links you control
Google's guide lists them: internal links, your profiles on other sites, and your ad campaigns. It also suggests asking the sites that link to you to update their links, starting with the ones that send the most visitors.

Without a terminal, the redirect checker shows each hop and its status code for an address you paste in.

After: what to watch, and for how long

Google's guide says to watch both sets of addresses: the old ones falling out and the new ones coming in.

The Sitemaps report shows how many submitted addresses are indexed. The new sitemap starts at zero and climbs.
The Page indexing report lists old addresses under "Page with redirect", which is the expected result. Check it regularly for errors you did not expect: "Not found (404)", "Soft 404", "Redirect error", "Server error (5xx)" and "URL marked ‘noindex’".
The Performance report shows the new addresses starting to collect impressions and clicks.
The Crawl Stats report and the server's logs show the crawling. Google says it crawls a moved site more heavily than usual for a while, because every crawl of an old address lands on the new site as well. The new server needs the capacity for that.

How long is not a fixed number. Google says there are no fixed crawl frequencies, and that speed depends on the number of addresses and how fast the server answers. Its general rule is a few weeks for most pages of a small or medium-sized site, and longer for a large one. After a change of domain, old addresses may still show in results now and then even when the new ones are indexed. Google calls this normal and says it fades without action.

Keep the redirects. Google's guide says to keep them as long as possible, generally at least 1 year, and to consider keeping them indefinitely for visitors' sake. Its help for the Change of Address tool sets a floor of 180 days and recommends paying for the old domain for at least a year, so that nobody else can buy it. Bing's guidelines give no period.

The mistakes that cost the most

The cause	What it looks like in Search Console	The fix
The staging `noindex` is still on	Indexed pages fall with no matching errors, and pages are listed under "URL marked ‘noindex’"	Remove the tag or header. Inspect a page and select "Request indexing"
robots.txt still blocks the site	"URL blocked by robots.txt", or "Indexed, though blocked by robots.txt"	Remove the rule. A block here also hides a `noindex` from Google
Old addresses not redirected, or redirected to addresses that do not exist	An unusually high count under "Not found (404)"	Add a 301 to the right page. See 404 errors on pages that exist when the page is there and WordPress cannot find it
Many addresses redirected to the home page	"Soft 404"	Redirect each to its own equivalent, or let it answer 404
Chains and loops	"Redirect error"	Point each old address straight at its final one. A loop that visitors also see is covered in ERR_TOO_MANY_REDIRECTS
302 where 301 was meant	Crawl Stats shows "Moved temporarily (302)", and the old addresses stay in results	Change the redirects to 301
Canonical tags name staging or old addresses	In URL Inspection, "User-declared canonical" shows an address that is not the page's own	Correct the tag so each page names itself
Images and downloads left behind	Crawl Stats shows "Not found (404)" answers for image and file addresses	Move the files and redirect their old addresses
The new server cannot keep up	"Server error (5xx)", and a host status in Crawl Stats that is not green	Add capacity. Google slows its crawling when it meets server errors

One caution about checking a redirect in Search Console. The help page for URL Inspection says its live test follows a redirect and tests the final page without saying it did so. Use curl or the redirect checker to see the hops themselves.

Changing platform, design and addresses all at once

Google's guidance is to change only one thing at a time. Its example is a site that wants a new domain, a new content management system and a new layout: do them one after the other, not together. Its guide even suggests setting the new site up on the same system as the old one where that is possible.

A change of platform rarely leaves that choice, so apply the principle to what is in your hands:

Keep every address the new platform lets you keep. An address that stays needs no redirect.
Keep the content and the structure as they were for the move. Rewrite and reorganize later, once the new addresses are indexed.
Leave a change of domain for another day if the platform is changing now.
Move a small or medium site in one go. Google recommends this over moving a section at a time, because it helps its systems detect the move. Moving in sections is its advice for large sites.
Pick a quiet period. Google suggests timing a move for when traffic is lowest, so fewer people meet any problem.

What the documentation does not say

Advice about migrations often goes further than the engines do. On these points the pages cited here are silent or say the opposite, so the claims are left out.

A percentage of ranking lost through each redirect. Google's guide says permanent redirects do not cause a loss in PageRank.
A date by which rankings return. Google gives a general rule for when pages are processed, and no promise about where they rank afterward.
Asking for each page to be indexed by hand. The help for URL Inspection says that for many pages the best choice is a sitemap.

When to get help

A missing redirect does not show on the site itself. It shows in a report, once the old address has been crawled again. Hand the move over when the list runs to more addresses than you can map by hand, when a store's product and category addresses all change, or when search is where most of your customers come from.

Our platform migrations redirect every old address to its new one and check the new site before the domain is changed. Each starts with a free migration assessment: a reply in writing with what moves by itself, what has to be rebuilt, and a fixed quote.

Common questions

How long does it take for rankings to settle after a migration?

Google gives no fixed period. Its guide says a small or medium-sized site can take a few weeks for most pages to move, that larger sites take longer, and that visibility may fluctuate during that time. The speed depends on how many addresses there are and how fast the server answers.

Do 301 redirects lose ranking power?

Not according to Google. Its guide to moving a site says that 301 and other permanent redirects do not cause a loss in PageRank. What can cost rankings is a redirect to the wrong page, or a new page that no longer holds what the old one did.

How long should I keep the redirects?

Google says as long as possible, generally at least a year, and suggests keeping them indefinitely for visitors who still follow old links. If the domain changed, keep paying for the old domain for at least a year as well, which is what Google recommends to stop someone else from buying it.

Do I need the Change of Address tool when I change platform?

Only if the domain or subdomain changes too. Google says the tool is not for moves within the same domain, such as new paths, http to https, or adding or dropping www. For those, the redirects and an updated sitemap are the whole notice.

Is there a way to tell Bing about a move?

Bing's guidelines ask for 301 redirects on moved addresses and a sitemap that lists only current ones. Submit the new sitemap in Bing Webmaster Tools. IndexNow is a further way to notify Bing that addresses changed, and its documentation says redirected addresses should be submitted.

How to migrate a website without losing SEO: what Google and Bing document

In short

Before: list every address that matters

Map each old address to one new address

What has to arrive on each new page

Launch day, in order

Step 1: Take the staging block off the new site

Step 2: Read robots.txt

Step 3: Check that canonical tags name the new addresses

Step 4: Test the redirects on the new server

Step 5: Switch, then ask one old address what it answers

Step 6: Count the hops

Step 7: Test the whole list

Step 8: Submit the new sitemap

Step 9: If the domain changed, file a Change of Address

Step 10: Tell Bing

Step 11: Update the links you control