Redirects and site migrations

Andy Bright

Director of Product and Technology

Sooner or later, most websites change their page addresses. A business moves to a new website platform, changes its name and domain, or reorganises its pages. Each time, search engines have to learn that the old addresses have been replaced. If they're told properly, a site's search traffic usually carries over to the new addresses. If they aren't, traffic can drop and take months to recover.

The tool that tells them is the redirect. This chapter explains what redirects are and which kind to use, then walks through a full move, step by step:

• what a redirect is, and the different types
• the rules that make redirects work well
• the different kinds of website move, and how risky each is
• a plan for before, during and after a move
• the extra steps that help AI assistants catch up

What a redirect is

A redirect is an instruction on your website that sends anyone who asks for one address to a different address instead. A person who clicks an old link lands on the new page without noticing. A crawler that asks for the old address is told where the page has gone.

A postal redirection service is a reasonable comparison. Post sent to your old home is forwarded to your new one. The comparison breaks down in one way, though. A postal service redirects everything sent to one address, but a website needs a redirect set up for each old page address, pointing to the right new one.

Fernhill Coffee, the example shop in this guide, is moving its online shop to a new platform. On the old platform, its Ethiopian coffee lived at:

https://www.example.com/shop/p/ethiopia-yirgacheffe

On the new platform, the same product lives at:

https://www.example.com/products/ethiopia-yirgacheffe

Fernhill sets up a redirect from the first address to the second. Anyone following an old link, including one in a Google result or in an AI answer, ends up on the new page.

Choosing the right type of redirect

Redirects come in two kinds. Google's redirect documentation⁠(opens in a new tab) explains the difference by what Google shows in its results:

• A permanent redirect tells Google to "show the new redirect target in search results".
• A temporary redirect tells Google to "show the source page in search results", meaning the old address.

If you use a temporary redirect for a move that's permanent, Google may keep showing the old address.

Redirects can also be set up in different places. A server-side redirect is set up on your web server or hosting platform, and it works before any page is sent. Other kinds are written into the page itself, as an HTML instruction or as JavaScript. This table shows how Google treats each one:

The numbers, such as 301 and 302, are HTTP status codes, the short codes a server sends back with every response. The first chapter introduces them.

Google's advice is to "use a permanent server-side redirect whenever possible" (Redirects and Google Search⁠(opens in a new tab)). AI search adds another reason to follow it. A JavaScript redirect only works for crawlers that run JavaScript, and the best available evidence is that most AI crawlers don't, as the JavaScript chapter explains. A server-side 301 or 308 works for every crawler.

The type of redirect also affects which address Google keeps in its index. Google's crawling documentation⁠(opens in a new tab) calls a 301 or 308 a strong signal that the new address should be used instead, and a 302 or 307 a weak one. A redirect is also the strongest of the signals Google uses to choose a canonical URL⁠(opens in a new tab), the address it treats as the main version of a page.

So, for a permanent move, use a server-side 301 or 308. Keep temporary redirects for moves that really are temporary, such as a page that's coming back after maintenance.

Rules for redirects that work

Send each old address to its closest match. Fernhill's old Ethiopian coffee page should go to the new Ethiopian coffee page, not to the shop's front page. If a product no longer exists, send it to the most similar product, or to its category. Redirecting everything to the home page gives visitors and search engines nothing useful. If there's no sensible replacement at all, let the old address return a 404 (not found) or a 410 (gone for good) instead.

Avoid redirect chains. A redirect chain is a redirect that leads to another redirect. Suppose Fernhill's Ethiopian coffee page has moved twice, so /coffee/ethiopia redirects to /shop/p/ethiopia-yirgacheffe, which now redirects to /products/ethiopia-yirgacheffe. Every step slows the page down. Google's crawling documentation⁠(opens in a new tab) says Googlebot follows up to 10 steps and gives up after that. Google's web.dev site lists multiple redirects as a common cause of a slow server response (Optimize LCP⁠(opens in a new tab)). Whenever you add a redirect, update older redirects so they point straight at the final address. Here, /coffee/ethiopia should go directly to /products/ethiopia-yirgacheffe.

Update the links on your own site. After a move, your menus and articles should link to the new addresses, so visitors and crawlers don't have to go through a redirect at all.

Keep redirects for a long time. Google's site move guide⁠(opens in a new tab) says to "keep the redirects for as long as possible, generally at least 1 year", and suggests keeping them indefinitely from your visitors' point of view. Google's Change of Address help page⁠(opens in a new tab) gives a shorter minimum of "at least 180 days". Treat a year as the minimum. Keep redirects indefinitely for any old address that other websites link to, because they cost almost nothing to maintain. A link from another website to one of your pages is called a backlink.

Keep all your redirects in one place. Ideally they live in one list on your server or hosting platform that your developer can check. Redirects spread across plugins, server files and website code are hard to check and easy to break.

Kinds of website move

A site migration is any change that alters a website's addresses or where it's hosted. Some are much riskier than others.

The more you change at once, the harder it is to work out what went wrong if traffic drops. If a launch combined a new domain, new addresses and a redesign, you won't know which of the three caused the problem. Where you can, make these changes one at a time.

A plan for moving your site

Google's site move guide⁠(opens in a new tab) breaks a move into four stages. Prepare and test the new site, make a list matching each old address to its new one, switch on the redirects, and then watch your traffic. The steps below follow those stages. Most of the steps before launch are things to ask your developer or agency to do.

Before launch

1. Make a list of every address that matters. A site crawl, from a tool that follows every link on your site, isn't enough on its own, because it misses pages nothing links to. Combine:
   • a full crawl of the current site
   • your XML sitemaps, and a list of pages exported from your website platform
   • the pages in your analytics that people landed on in the last year
   • the pages that other websites link to
   • your server logs, including addresses that search engines and AI crawlers still ask for
2. Match every old address to a new one. Put the list in a spreadsheet with two columns, old address and new address. This list is called a redirect map. Match pages one to one where you can. Where there's no equivalent, decide on purpose to let the old address return a 404 or 410. Have someone check the map before launch.
3. Build and test the new site on a private test address. This is often called a staging site. Protect it with a login rather than with robots.txt or noindex. If the staging site's Disallow: / or noindex tags are copied to the live site at launch, crawlers are told to stay away from every page. With a login, there's nothing to copy across by mistake.
4. Test every redirect in the map before launch. Each old address should return a single 301 or 308 to the right new address.
5. Point everything on the new site at the new addresses. That includes canonical tags, language tags (hreflang), links between pages, XML sitemaps and structured data, including the url, @id and logo values. The indexing chapter, international SEO chapter and structured data chapter explain each of these.
6. Set up the new site in Google Search Console and Bing Webmaster Tools, and record where you're starting from. Note how many pages are indexed, your traffic for each landing page, your page speed scores and how often AI crawlers visit.

At launch

1. Switch on the redirects for the whole map on the first day.
2. Check that the new site's robots.txt allows crawling, and that no noindex tags came across from the staging site.
3. Submit the new sitemaps in Google Search Console and Bing Webmaster Tools.
4. If you're changing domain, use Search Console's Change of Address tool⁠(opens in a new tab). This tells Google that your whole site has moved to a new domain. The tool doesn't move subdomains, including www. Google's help page gives the example that "if you specify example.com in the tool, it will not move www.example.com⁠(opens in a new tab) or m.example.com". Since June 2026, Google's guidance, in that help page and in the site move guide⁠(opens in a new tab), is to submit a request for every version of the old domain that you've verified in Search Console. That includes subdomains, and both the www and non-www versions, "even if you're not actively using these variants currently". Bing Webmaster Tools has its own site move tool.
5. Notify IndexNow of the new addresses, so Bing and the other search engines that use it find them quickly. The sitemaps chapter explains IndexNow.

After launch

1. Check daily for the first few weeks. Look for errors and 404s in Search Console and your server logs, check that the new addresses are being indexed, compare traffic for each landing page with your starting point, and test a sample of old addresses to confirm they still redirect.
2. Watch the crawlers. Googlebot, Bingbot and the AI crawlers you allow should be asking for the new addresses, and any requests for old addresses should get a single redirect.
3. Keep the old domain registered, and keep its redirects working, for the long term.
4. Expect your rankings to move about for a few weeks while search engines process the change.

Changing hosting without changing addresses

If only your hosting company or server changes, and every page keeps its address, the move is simpler. It still involves the DNS, the system that turns your domain name into the numeric address of the server that hosts it. When you move hosts, your DNS settings change to point at the new server.

Google's guide to changing hosting⁠(opens in a new tab) gives these steps. Prepare and test the new hosting. Lower your DNS TTL ("time to live", the length of time other computers keep a copy of your DNS settings) "at least a week in advance", so the switch takes effect quickly. Then switch your DNS to the new server, check everything works, and only then shut down the old hosting. Google says to expect "a temporary drop in Googlebot's crawl rate immediately after the launch" while it checks the new server can cope.

Check your CDN and security settings on the new setup too. A CDN (content delivery network) is a service that delivers your pages from servers around the world. A new CDN or host can start blocking AI crawlers by default, without anyone deciding it should. The crawlability chapter shows how to check.

Helping AI assistants catch up

Most migration plans stop at Google. These extra steps help AI assistants learn about your new addresses and name.

Update the other places that describe your business. Your social media profiles, directory listings, review sites, Wikidata and Wikipedia entries, and partner websites should all point at the new domain. So should the sameAs links in your structured data, explained in the structured data chapter. If the rest of the web still uses your old address or old business name, AI answers can keep repeating it.

Keep redirects for addresses that AI answers cite. An assistant that has cited your old pages may keep linking to them for a while. A working redirect turns those links into visits instead of error pages.

Check your logs for AI crawlers asking for old addresses. According to Vercel and MERJ's crawler study⁠(opens in a new tab), AI crawlers already spend a large share of their requests on addresses that no longer exist. After a move, look for old addresses they keep coming back to, and make sure each one gets a single redirect.

Check that AI crawlers can still get in. A new CDN, firewall or hosting platform can block them by default. Confirm that the crawlers you've chosen to allow get a 200 response on the new site.

What to do next

1. Find out where your site's redirects are managed, and whether they're server-side 301s.
2. Look for redirect chains, and point each old address straight at its final destination.
3. Before any move, build a redirect map in a spreadsheet, matching every old address to its new one.
4. Protect any staging site with a login, not with robots.txt or noindex.
5. If you change domain, use the Change of Address tool for every verified version of the old domain, and keep renewing the old domain.
6. After a move, check Search Console and your logs daily for the first few weeks.

Further reading

• Redirects and Google Search⁠(opens in a new tab), Google's guide to every type of redirect.
• Site moves and migrations⁠(opens in a new tab), Google's plan for moves that change page addresses.
• Change of Address tool⁠(opens in a new tab), the rules for moving to a new domain, including subdomains and www.
• Changing your hosting⁠(opens in a new tab), the shorter process for moves that keep your addresses.
• How HTTP status codes affect Google Search⁠(opens in a new tab), including the 10-step limit on redirect chains.