Website Migration: Keep the Redirects at Least a Year
Google publishes the retention period, the chain limit and which moves its change of address tool covers. Most migration checklists get the last one wrong.
Keep the redirects at least a year. That is not a convention, it is the published guidance, and it is the single figure most migration checklists either omit or shorten.
The rest of the documentation is similarly specific: a named chain limit, an explicit statement that permanent redirects do not cost ranking credit, and a precise list of the moves for which the Search Console change of address tool is and is not required. That last list is where most published checklists are simply wrong.
This page gives each documented rule with its figure, and what to do when your case is not a URL change at all.
The redirect rules, with their numbers
Four items, each quotable.
Which redirect to use, verbatim. Use server side permanent redirects if technically possible. Although the crawler supports several kinds, the recommendation is HTTP permanent redirects if possible, such as 301 and 308.
Whether you lose credit, verbatim. Do not worry about link credit. 301 and other permanent redirects do not cause a loss in PageRank.
How long to keep them, verbatim. Keep the redirects for as long as possible, generally at least 1 year. That timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs. From users’ perspective, consider keeping redirects indefinitely.
The chain limit, verbatim. Avoid chaining redirects. The crawler can follow up to 10 hops in a chain, but the advice is to redirect to the final destination directly. If that is not possible, keep the number low, ideally no more than 3 and fewer than 5.
Why the retention figure matters most. Redirects get removed for mundane reasons: a hosting renewal, a server cleanup, a new team inheriting a configuration nobody documented. Doing that at nine months is inside the window Google names as necessary for signals to transfer.
The practical instruction that follows. Put a dated note in whatever system your team actually reads, saying which redirects exist, why, and the earliest date they may be reconsidered. Not a wiki page nobody opens.
What the tool covers, and what it does not
This is the section most migration guides get wrong, and the documentation is unambiguous.
When you need it, verbatim. If you are changing domain names or subdomains, submit a change of address in Search Console for the old site. You only need this tool when moving from one domain or subdomain to another, such as example.com to example.net, or a.example.com to b.example.com.
When you do not need it, verbatim. You do not need it for HTTP to HTTPS moves, for switching between www and non-www on the same domain, or for moving paths within the same domain.
Note what is on the covered list. Subdomain to subdomain. A common claim in migration guides is that the tool does not handle subdomains. It does, and the documentation gives it as an example.
What that leaves uncovered. Protocol changes, www normalisation, and path restructuring, all of which are handled by redirects alone.
Why the distinction is practical. Teams sometimes delay a protocol migration waiting for a tool step that does not exist for it, or expect the tool to smooth a path restructure it has no bearing on.
And what the tool never does. Substitute for the redirects. It is a notification, not a mechanism.
Sequencing, and the fluctuation nobody warns clients about
Two more documented points, both of which change how you brief stakeholders.
On sequencing, verbatim. Small or medium sites: move all URLs simultaneously instead of one section at a time, because this helps users interact with the site better in its new form and helps the algorithms detect the site move and update the index faster.
For large sites. You can move one section at a time, which makes it easier to monitor, detect and fix problems faster. And separately: if your site is large and it is technically possible, consider moving just a piece first to test the effects on traffic and indexing.
On fluctuation, verbatim. Expect temporary fluctuation in site ranking during the move. As a general rule, for medium-sized websites it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones, and for larger sites, even longer.
And the reassurance, verbatim. That visibility may fluctuate temporarily during the move, that this is normal, and that a site’s rankings will settle down over time.
Why this belongs in the brief, not the post-mortem. A traffic dip in week two of a migration is documented, expected behaviour. If nobody told the business that in advance, it becomes an emergency, and emergencies produce the worst decision available: reverting the migration halfway.
The number to commit to instead. Tell stakeholders that the comparison point is the same month next quarter, not next week. Then hold to it.
A dip in week two is documented, expected behaviour. Unbriefed, it becomes an emergency and produces a half-revert. Source : Google Search Central, site move guidance (2026)
When your move is not a URL change
A separate case with separate guidance, frequently conflated with the first.
What it covers. Switching hosting providers, or moving to a content delivery network. Guidance that explicitly applies only to migrations that do not affect the user-visible URL.
The steps. Prepare the new infrastructure, change the DNS, monitor traffic, then decommission the old infrastructure.
Which step is the move. The documentation identifies the DNS change as the actual site move step.
What is absent from this guidance. Redirects. There are none, because the addresses do not change.
Why people get this wrong. They apply the URL-change checklist to a hosting change, which produces a lot of unnecessary anxiety and occasionally a set of redirects pointing a URL at itself.
One thing that does still matter here. Server response time changes with hosting, and that is a real performance variable even when nothing about your addresses moved.
Not from documentation, from what actually goes wrong.
Removing the redirects early. At a hosting renewal, a cleanup, or a handover. Inside the one-year window, this undoes the migration.
Chaining onto an earlier migration. Old URL to previous URL to current URL. Two migrations produce a two-hop chain, three produce three. The documented ceiling arrives faster than teams expect.
Redirecting everything to the homepage. Convenient, and it destroys the mapping. A page that no longer exists should return a 404 or 410, or redirect to its genuine equivalent, not to the front door.
Losing the old URL inventory. Once the old site is gone you cannot enumerate what it had. Export the full URL list and the Search Console performance data before you switch anything.
Forgetting non-page assets. PDFs, images referenced from other sites, feed URLs, and any address someone else hard-coded into an integration. These carry links and they break silently.
And the one governance failure behind most of them. Nobody owns the redirect map after launch week. Assign it, with the earliest review date being at least a year out.
Eight steps, ordered, with the documented figures attached where they exist.
Export everything first. The full URL list, the Search Console performance data by page and by query, and the current index coverage. Do this before touching anything, because it cannot be recovered later.
Build the mapping page by page. Old URL to its genuine equivalent. Where there is no equivalent, decide deliberately between a 410 and a redirect to the nearest real page, and record the decision.
Test the new site thoroughly before switching. The documentation puts this first for a reason: a migration onto a broken site compounds two problems.
Move all at once if you are small or medium. That is the documented recommendation, and it helps the index update faster.
Use 301 or 308, server-side. Not a JavaScript redirect, not a meta refresh.
Submit the change of address only if you are changing domain or subdomain. Not for protocol, not for www, not for paths.
Brief the business on the timeline before, not after. A few weeks or more for medium sites, longer for large ones, with the real comparison being the same period next quarter.
Then set the review date twelve months out. And write down who owns it.
Keep redirects at least one year. That is the documented period for signals to transfer, and considering indefinitely is the stated user-facing advice.
Use server-side permanent redirects, 301 or 308, and note that permanent redirects do not cause a loss in PageRank.
Chain limit: 10 supported, 3 or fewer advised, with fewer than 5 as the outer bound.
The change of address tool covers domain and subdomain moves. It is not needed for HTTP to HTTPS, www to non-www, or path changes.
Small and medium sites should move everything at once, which helps the index update faster.
Expect a few weeks or more of fluctuation on a medium site, longer on a large one. Brief that before launch.
A hosting change with no URL change is different guidance entirely, where the DNS change is the move and there are no redirects.
The commonest failure is removing redirects early, at a renewal or handover, inside the documented year.
Google says to keep them for as long as possible, generally at least one year, because that allows all signals to transfer including recrawling and the reassignment of links on other sites. It suggests keeping them indefinitely for users.
Do 301 redirects lose ranking credit?
Google states that 301 and other permanent redirects do not cause a loss in PageRank. Its recommendation is to use server-side permanent redirects where technically possible, naming 301 and 308.
How many redirects can I chain?
Googlebot can follow up to 10 hops, but the guidance is to redirect directly to the final destination, and where that is not possible to keep the chain ideally to no more than 3 and fewer than 5.
How long will traffic take to settle?
For medium-sized websites, a few weeks or more for Google to gradually start showing the new URLs instead of the old ones, and longer for larger sites. No upper bound is published.
When do I need the Change of Address tool?
Only when moving from one domain or subdomain to another. It is explicitly not needed for HTTP to HTTPS moves, for switching between www and non-www on the same domain, or for moving paths within the same domain.
Should I migrate everything at once?
Google recommends that small and medium sites move all URLs simultaneously, which helps its algorithms detect the move and update the index faster. Large sites may move one section at a time to make problems easier to isolate.
What about a hosting change with no URL changes?
Different guidance applies. That covers switching hosting providers or moving to a content delivery network, where the DNS change is described as the actual move step, and no redirects are involved because addresses do not change.
What is the most common migration mistake?
Removing the redirects too early, usually at the next hosting renewal or site cleanup, well inside the one-year period Google names. The second is chaining redirects from an earlier migration onto the new ones.