Skip to content
Taking 2 projects at a timeBook a 20-min call
Book a 20-min callhello@theweb0.com

Moving a website without losing search traffic: the order I work in

Short answer

List every old address before anything is designed, give each one a permanent redirect to its closest new page, change one thing at a time, and watch the numbers for ninety days. Nobody can promise rankings. Anyone can account for every URL.

Contents 8 sections

The common ways a move loses search traffic are dull. An old address that used to bring in customers now returns an error. A page title did not come across. Or the new platform, a new design and new addresses all went live on the same night, rankings dipped, and nobody can say which of the three did it.

None of that is bad luck. It is a missing list, or the right steps done in the wrong order. Here is the order I work in, with Google’s own guidance next to each step where it has some.

What does Google say about moving a site?

Google publishes a guide for exactly this case: a site move where the addresses change.11Google Search Central, “Site moves with URL changes”. Every quote from Google in this note is from this page unless another footnote says otherwise. developers.google.com, checked 11 November 2026. Four lines in it matter more than the rest.

Google saysWhat it means for you
“301 and other permanent redirects don’t cause a loss in PageRank.”A redirect done properly carries the old page’s standing to the new one.
“Expect temporary fluctuation in site ranking during the move.”A dip in the first weeks is normal. Judge the move at day 30 and day 90, not day 2.
“a small to medium-sized website can take a few weeks for most pages to move”Google needs time to visit every old address and find where it went.
“Keep the redirects for as long as possible, generally at least 1 year.”The redirects are part of the site, not scaffolding you take down after launch.

Notice what the guide does not say. It never promises that rankings come back. Nobody honest can, so I don’t either. What anyone can promise is that every old address is accounted for.

In what order do I work?

  1. List every address the old site has. Before anything is designed. A crawl finds the pages that link to each other. The sitemap, Search Console and analytics find the ones that don’t: old campaign pages, PDFs, a post someone linked to from a forum years ago. Each row gets its visits and its incoming links, so you can see what losing it would cost.
  2. Give each address a decision. Kept as it is, redirected to its closest new page, merged into a page that now covers it, or retired. You sign the list before launch, because some of those calls are business calls, not technical ones.
  3. Keep addresses the same wherever you can. The best redirect is the one you never need. A new platform does not require new URLs.
  4. Carry over what search engines read. Titles, descriptions, headings, canonical tags, structured data, and the dates and bylines on articles. Google asks you to “add a user-visible date to the page and feature it prominently”.2
  5. Test every redirect before launch. On a staging copy, by script, one address at a time. Each old address should answer with one permanent, server-side redirect3 to a page that loads, not a chain of three hops.
  6. Switch at a quiet hour, with the old site as the way back. It stays up, untouched, until the new one has passed the checklist. Then submit the new sitemap in Search Console, as Google’s guide says.
  7. Watch, and fix the same day. Day 1, 7, 30 and 90. More on that below.
  8. Leave the redirects in place. At least a year, Google says. I see no reason to take them down after that either.

Why not send every old page to the home page?

Because it looks like a fix and isn’t. It is the shortcut people take when the inventory was never made: anything they cannot place goes to /. Google’s guide names it directly: “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site.” It adds that this “might be treated as a soft 404 error.”1

A visitor feels it too. They clicked a link about your pricing and landed on your home page. Most will not go looking.

If an old page has a real successor, redirect to it. If it has none, let it go with a 404 or a 410, which tells both people and crawlers the truth.

Old addressNew address/web-design//2019/prices//about-us//news//promo-2018//websites/pricing/about/blog410 Gone/ (home page)301301301301retired
Fig.
A redirect map for a made-up site. Every old address gets one decision. The orange line is the shortcut not to take.

Should you redesign and move in one go?

Google’s guide puts the answer in a heading, “Change only one thing at a time”, and the line under it reads “Plan your changes to your site one after the other, not everything at the same time.” Its own example is a new domain, a new CMS and a new layout, and it says to do them one at a time.1

I agree, and the reason is diagnosis, not caution. Move the site as it is first, on the same addresses where possible. Redesign second. If the numbers move after the first release, it was the move. If they move after the second, it was the design. Launch both on one night and you are left guessing, usually in a meeting.

It costs a second launch and a few weeks of patience. If a fixed date forces both at once, such as a rebrand that has to be live for an event, keep every address the same. That takes the redirect risk off the table, and leaves you two changes to tell apart instead of three.

Should you change the domain as well?

Only if you have to. A change of domain is the hard case, and the published numbers on it are sobering.

523 days

The average time it took organic traffic to come back after a move to a new domain, across 892 domain migrations. In 17% of them it had not come back after 1,000 days.

Source: Search Engine Journal, 2025

Read it with care. The traffic figures are estimates from third-party tools, and the sample is domain changes only, not platform moves on the same domain.44Dan Taylor, “How Long Should An SEO Migration Take?”, Search Engine Journal, 8 January 2025. 892 domain migrations, most from Ahrefs data. searchenginejournal.com, checked 11 November 2026. It says nothing about your site. It does say that a new domain is not a detail to add because the new design “deserves” one.

If you must change it, Google asks you to submit a Change of Address in Search Console for the old site.1 Keep the old domain registered and pointing at the redirects for as long as they need to run.

Does a move change how AI search sees you?

It can. In December 2024 Vercel looked at AI crawler traffic across its network and found that “none of the major AI crawlers currently render JavaScript”. The same study found that “ChatGPT spends 34.82% of its fetches on 404 pages”.55Vercel, “The rise of the AI crawler”, 17 December 2024. Claude’s crawler showed a similar share, 34.16%. vercel.com, checked 11 November 2026.

That study was not about migrations, but two things follow for one. A page that needs JavaScript to show its words is blank to those crawlers, so the new site should send its text from the server. And an old address that now returns a 404 is a wasted visit from them as well as from Google. The redirect map does double duty.

What do I measure, before and after?

The “before” has to be taken before launch. Afterwards it is gone.

  • Clicks and impressions per page in Search Console, for the weeks you will compare against.
  • How many pages are indexed.
  • The top landing pages from analytics.
  • Core Web Vitals from real visitors, where the site has enough of them.
  • The 404s the old site already has, so they are not blamed on the move.

After launch, the same numbers on a fixed calendar.

WhenWhat I check
Day 1Every redirect answers. No 404 on a page that had visits.
Day 7Indexed pages against the inventory. Errors in Search Console.
Day 30Clicks and impressions against the same weeks before. Core Web Vitals from real visitors.
Day 90A before-and-after report: traffic, speed, what moved and why.

I have not published a migration case of my own yet. When I do, its numbers go here, whatever they turn out to be.

If you want a “before” of your current site today, the site check reads a page the way a crawler without JavaScript does and lists what it finds.

What should you ask whoever does your move?

Whether it is me, an agency or your own team, these are fair questions before anyone switches anything.

  • Can I see the list of every old address, and what happens to each one?
  • Is every redirect permanent, and done on the server?
  • Does any old address hop more than once before it lands?
  • Is the old site still there if you have to switch back?
  • Is anything changing at the same time as the platform: the domain, the design, the addresses?
  • Who checks Search Console at day 7, 30 and 90, and what do they send me?
  • Will the redirects stay for at least a year?

The migrations page shows the inventory, the redirect map and the launch checklist I hand over, and what the move costs.

Notes and sources

  1. Google Search Central, “Site moves with URL changes”. Every quote from Google in this note is from this page unless another footnote says otherwise. developers.google.com, checked 11 November 2026. ↩︎ ↩︎ ↩︎ ↩︎

  2. Google Search Central, guidance on publication dates. It also asks you to label them with words like “Last updated”. developers.google.com, checked 11 November 2026. ↩︎

  3. Google’s redirects guide recommends “a permanent server-side redirect whenever possible”, and JavaScript redirects only as a last resort. developers.google.com, checked 11 November 2026. ↩︎

  4. Dan Taylor, “How Long Should An SEO Migration Take?”, Search Engine Journal, 8 January 2025. 892 domain migrations, most from Ahrefs data. searchenginejournal.com, checked 11 November 2026. ↩︎

  5. Vercel, “The rise of the AI crawler”, 17 December 2024. Claude’s crawler showed a similar share, 34.16%. vercel.com, checked 11 November 2026. ↩︎

Written by Dion Zeneli. AI helped with research and editing. Sources are linked where they are used. Read this note as markdown.