Redirects are how a site move actually happens. Whatever the plan says about design, content or platform, the old URLs have to end up somewhere, and the redirect is the instruction that tells browsers and Google where. Because it is a small piece of configuration, it is often treated as a detail. Google’s documentation treats it as the centre of the job.
This article collects what Google says about redirect types, chains, how long to keep redirects, and moving a site when URLs change. Where we give our own reading, we say so.
Permanent or temporary: what the redirect tells Google
Google’s page on redirects and Google Search explains that, while users generally cannot tell the types of redirect apart, Google Search uses certain types as a signal that the redirect target should be canonical. A permanent redirect shows the new target in search results. A temporary redirect shows the source page. Googlebot follows both, but only permanent redirects are used as a canonical signal.
The page lists the mechanisms in order of how likely Google is to interpret them correctly. Permanent ones include HTTP 301 and 308 on the server side, an instant meta refresh and JavaScript location changes, which Google says to use only if server-side or meta refresh redirects are not possible. Temporary ones include 302, 303 and 307, and delayed meta refreshes.
The practical rule is on the page itself: use a permanent redirect when you are sure it will not be reverted, and if you need to change the URL shown in search results, use a permanent server-side redirect whenever possible. A temporary redirect suits something like a service that is briefly unavailable, where the original URL should not be disturbed. Our reading is that a common error is leaving a temporary redirect in place after a move that was meant to be permanent.
How long Google says to keep redirects
The answer sits in Google’s site move guidance. It says to keep the redirects for as long as possible, generally at least one year, and explains that this allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to the old URLs. For users, it suggests considering keeping them indefinitely.
The caveat is that redirects are slow for users, so it advises updating your own links and any high-volume links from other sites to point to the new URLs.
What Google’s checklist for a move with URL changes covers
The same page covers moves that change URLs: HTTP to HTTPS, a domain change, or new paths. Its overview is a sequence: prepare the new site and test it thoroughly, prepare a URL mapping from current to new URLs, start the move by redirecting, and monitor traffic on both.
Several preparation items are specific. If you blocked crawling or used noindex rules during development, prepare the live robots.txt and a list of URLs from which noindex must be removed. Content that will not move should return a 404 or 410 on the new site. Both old and new sites, with all variants, should be verified in Search Console. Each new URL should have a self-referencing canonical, and hreflang annotations must be updated to the new URLs. The server needs capacity, because Google will temporarily crawl the new site more heavily than usual.
In the simplest move, such as a domain change, a wildcard server-side redirect may be enough. In a more complex one you need a list of old URLs, each mapped to a destination. Google suggests starting with the important ones: URLs in your sitemaps, those with the most traffic in server logs or analytics, and those with links in Search Console, and it says to include images, videos, JavaScript and CSS. It warns against redirecting many old URLs to one irrelevant destination such as the home page, which may be treated as a soft 404.
For sequencing, Google says that small and medium sites should move all URLs at once, which helps its systems detect the move, while large sites can move one section at a time to monitor and fix problems more easily. For a domain or subdomain change, it also asks for a Change of Address request in Search Console, which it says is not needed for HTTP to HTTPS moves, www changes or path changes within a domain.
Redirect chains and the Crawl Stats report
A chain is a redirect that leads to another redirect. Google’s move guidance says Googlebot can follow up to 10 hops, but advises redirecting to the final destination directly. If that is not possible, it says to keep the number of redirects low, ideally no more than three and fewer than five, because chaining adds latency for users and not all user agents and browsers support long chains.
The Crawl Stats report explains how a chain looks in your data. The URLs shown are the actual URLs Google requested, not canonical ones, and if a URL has a server-side redirect, each request in the chain is counted as a separate request. Its example: if page1 redirects to page2, which redirects to page3, a request for page1 appears as three requests, the last hopefully a 200. Client-side redirects are not counted.
Our reading of those two pages together: a chain is not one slightly slow redirect but several requests, each a fetch that Google and your server have to make. A mapping that sends each old URL directly to its final destination avoids the problem before it starts.
Changing one thing at a time, and moves that change no URLs
Google says to change only one thing at a time, and its example is a site that wants a new domain name, a new CMS and a new layout: do them one after another, moving to the new domain first and then changing the layout. It also says to expect temporary ranking fluctuation while Google reprocesses the site.
Google treats a change that leaves visible URLs alone as a separate case. Its page on changing your web hosting covers switching hosting providers or moving to a CDN, with no redirects involved. It includes testing on a temporary hostname with noindex, checking that a firewall does not block Googlebot, and shutting down the old hosting only when all users, including Googlebot, are being served by the new one.
Where this fits at Cultured Digital: moves, rebuilds and redirect maps
Migrations are part of the technical SEO work we do: planning and redirect mapping, pre-launch testing, launch-day monitoring and post-launch recovery, for single sites and multi-market structures. Our migrations guide sets out the sequence in more detail.
When the move is part of a rebuild, the same principle appears on our rebuilds and migrations page: redirects mapped before launch and tested after. We can lead the build, join your team, or specify the requirements and review the result. For a practical set of launch checks on a WordPress build, see our article on WordPress launch checks that protect rankings.