Website migration: the redirect map is the easy part

The redirects are not usually what goes wrong

Almost every migration checklist on the web is the same checklist: crawl the old site, map old URLs to new, use 301s, resubmit the sitemap. That part is real, and it is also the part your developers already know. Migrations still go wrong, and they go wrong for less obvious reasons. Four changes ship on the same weekend so nobody can tell which one cost the traffic. The staging robots.txt goes live with the site. A new firewall or CDN rule blocks a crawler nobody thought to test. The redirects are correct but they point through two hops to a page that no longer holds the content the old URL ranked for. Or the old site is decommissioned on schedule ninety days later, which is inside the window Google says it still needs.

None of those are redirect problems. They are sequencing, access and evidence problems, and they are what the rest of this guide is about.

Permanent means canonical. Temporary means nothing.

Google's redirect documentation, last updated 14 April 2026, draws the distinction in two sentences that are worth reading slowly. For a permanent redirect, Googlebot follows it and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical. For a temporary redirect, Googlebot follows it, but the indexing pipeline does not use the redirect as a signal that the target should be canonical. A 302 left in place after launch is not a slightly weaker 301. For the purpose you care about, consolidating the old URL's signals onto the new one, it is doing nothing at all.

The same page orders the ways of implementing a redirect by how likely Google is able to interpret them correctly, and puts server-side HTTP redirects at the top, ahead of meta refresh and ahead of JavaScript location redirects. If your platform only offers a client-side option, that is a constraint to raise before launch, not after.

Now the uncomfortable part. That documentation does not state a limit on how many hops Googlebot will follow, despite the number of checklists that confidently quote one. We still refuse to ship a chain, because pointing every old URL directly at its final destination costs nothing and does not depend on undocumented behaviour. But the rule is engineering discipline, not a published Google threshold, and it is worth knowing which of the two you are being sold.

Google's own pages do not agree on how long to keep them

This is the question every client asks and it has three published answers. Google's site move guide says to keep the redirects for as long as possible, generally at least 1 year, and gives the reason: that timeframe allows Google to transfer all signals to the new URLs. Google's Change of Address help page says to maintain the redirects for at least 180 days, longer if you still see any traffic to them from Google Search, and says the Search Console forwarding action itself continues for 180 days after you start the migration. Bing's own migration guidance asks for at least one to two years, preferably longer.

The reconciliation is that the 180 days describes how long the Search Console tool keeps acting, not how long the signals take to move, and the site move guide is the one talking about signals. So the operating answer is the longest of the three, and the honest version of the answer is that a calendar is the wrong instrument anyway. Keep the redirects until your own server logs show the crawlers have stopped asking for the old URLs. That is evidence. Ninety days because the hosting invoice renews is not.

The practical consequence is a budget line most teams forget. Somebody has to pay to keep the old domain registered and the old host answering requests for a year or more after nobody is looking at it. Decide that at planning, because the alternative decision gets made accidentally by whoever cancels the invoice.

The Change of Address tool covers less than its name suggests

Use it when you move from one domain or subdomain to another, and know its edges before you rely on it. It works at domain level, so you can move example.com or m.example.com, and you cannot use it on a path such as example.com/petstore/. It does not move any subdomains below the domain you specify, and that includes www. You have to be a verified owner of both the old and the new property, managed from the same Google account. And it is the wrong tool for two of the moves people most often reach for it: Google says you do not need it when you are moving from HTTP to HTTPS, and it is not for moving between www and non-www on the same domain.

One detail here is newer than most published advice, and it is the kind of thing that quietly costs a migration weeks. Google updated its site move guide on 17 June 2026 to say that you should submit Change of Address requests for all subdomains and the www and non-www variants of the old domain name, even where you are not actively using those variants. Read that as a verification job that happens before launch, not on the day. Moving example.com to example.net now means having example.com, www.example.com, example.net and www.example.net all verified in Search Console before you begin, and most migration plans written before last June do not say that.

Change one thing at a time, and Google means it literally

The site move guide's instruction is to plan your changes to your site one after the other, not everything at the same time, and to split the move into smaller steps where that makes sense. On scale, it recommends moving all URLs simultaneously for a small to medium site, and allows moving one section at a time for a larger one.

Teams read this as caution and override it, because a redesign, a replatform and a domain change on one weekend is one outage instead of three. The reason to follow it anyway is diagnostic, not superstitious. If four things change together and organic traffic falls fifteen percent, you have no way to attribute it, which means no way to fix it and no way to know whether it would have recovered on its own. Sequencing is what keeps a diagnosis available to you later. That is also the first thing we look for when somebody arrives after the fact asking why their traffic is down, and the answer is often that nobody can say, which is a worse position than a fixable fault.

On timing, Google's stated expectation is that a small to medium-sized website can take a few weeks for most pages to move, and that larger sites take longer. Set that expectation with whoever is watching the dashboard before launch, because a recovery curve looks like a disaster on day three if nobody was told what normal looks like. Our guide to how long SEO takes makes the same point about the wider work.

A hosting move is a different job with a different list

If the URLs are not changing and you are switching hosting provider or moving to a CDN, most of the above does not apply and a different set of details does. Google's guidance here, last updated 10 December 2025, is short and specific: lower your DNS TTL to a conservative low value, a few hours for example, at least a week before the move, so DNS caches refresh faster when you cut over. Monitor server logs on both the old and the new host while traffic shifts, because for a period both are serving real requests.

Expect a temporary drop in Googlebot's crawl rate immediately after launch, followed by a steady increase over the next few days. That dip is documented and normal, and knowing it is documented is what stops a team from panicking into a second change on day two. The other thing worth checking before you cut over is dull and catches people constantly: make sure your Search Console verification survives the move, because a verification file or meta tag that lives on the old host disappears with it, and losing access to your own reporting during a migration is a self-inflicted blindfold.

What a move does to your AI citations: nobody has published an answer

We looked for a primary source on this and there is not one. No AI engine documents how quickly a permanent redirect propagates into its citation layer, whether a cited URL is refreshed on the next crawl or held until the underlying index is rebuilt, or how a domain change affects a brand's entity record inside a model. Anyone quoting you a recovery window for AI citations after a migration is estimating. That includes us, which is why we do not quote one.

What you can control is access and evidence, and both are cheap.

• Keep the old URLs resolving. An AI answer cites a URL captured when the page was crawled, and those answers keep circulating after your launch date. A 301 keeps that citation working for the reader. A 404 turns it into a dead link with your brand next to it.
• Verify crawler access on the new host on day one. The most common self-inflicted wound in a migration is a new WAF, CDN rule or robots file that blocks agents the old host allowed. Test it rather than assume it, using the list in our guide to the AI crawlers and how to let them in.
• Freeze a prompt set before launch. Run it, log who gets cited, then run the same set after. Without that pre-move sample you have no way to tell a migration effect from ordinary model drift, and drift is large. The method is in measuring AI visibility.

Bing's migration guidance is blunt in a way that is worth borrowing for this whole section: even the best planned migration will result in fluctuations and likely a temporary decline in organic search visibility. That post also asks for daily server log monitoring for at least three months after the move and a follow-up audit six to twelve months later, and notes that Bing accepts up to 10,000 URL submissions a day to speed up indexing of the new site. It dates from December 2020 and Bing has not replaced it, so treat the tooling details as worth re-checking and the expectation setting as still sound.

The one thing you cannot recreate afterwards

Everything above can be fixed late, at a cost. The baseline cannot. Once the old site is gone, there is no way to go back and record what it looked like, and every subsequent argument about whether the migration worked becomes an argument about memory.

A usable baseline is a full crawl of the old site with status codes, titles, canonicals and indexation state for every URL; the top URLs by clicks and impressions exported out of Search Console rather than left in the interface, because that history is finite; a note of which pages held which rankings; and, in 2026, the frozen prompt set described above. Take it while the old site is live and store it somewhere that is not the server you are about to decommission.

This is the single reason migration work is bought before a launch and not after. Turning up afterwards with a traffic drop and no baseline means the recovery starts by rebuilding, from archives and guesswork, information that would have taken an afternoon to capture.

Launch week, in the order it actually happens

• Before launch. Baseline captured. Redirect map built one to one, no chains, no blanket redirect to the homepage. Every domain variant verified in Search Console. Staging robots.txt and any noindex tags accounted for line by line. Rollback triggers agreed in writing while everyone is calm.
• Day zero. Redirects live, robots.txt correct on the live host, sitemaps swapped to the new URLs, Change of Address filed if it is a domain move, caches purged. Then crawl your own site immediately and compare against the map.
• Day one. Server logs, not dashboards. Are the crawlers arriving, what status codes are they getting, and is anything being refused. Check AI crawler access separately, because it fails separately.
• Day seven. Indexation of the new URLs against the baseline list. Search Console coverage. Any redirect returning something other than a permanent status.
• Day thirty. Positions and clicks against baseline, old URL requests still arriving in the logs, and the first honest read on whether the curve is recovering or flat. Google's few weeks expectation means day thirty is a checkpoint, not a verdict.

Sources

This page is built from primary documentation rather than other people's checklists. Google's site moves with URL changes guide, last updated 17 June 2026, is the source for the redirect lifetime, sequencing, scale and Change of Address instructions. Google's Change of Address tool help page supplies the 180 day figure and the tool's limits. Google's redirects documentation, last updated 14 April 2026, is the source for permanent versus temporary canonicalization and the ranking of redirect methods. Google's guidance on changing web hosting, last updated 10 December 2025, covers TTL and the crawl rate dip. The June 2026 change to the subdomain and www instruction was reported by PPC Land on 23 June 2026. The Bing material comes from the Bing Webmaster Blog post Website Migration with Bing, dated 17 December 2020.

Common questions