How to Migrate a Website Without Losing Your Rankings

Every year a chunk of the businesses we talk to have a version of the same story. They switched web providers, moved to a new platform, or rebranded onto a new domain, and traffic that took two years to build disappeared inside a month. Almost none of it was unavoidable. It happened because nobody mapped the old URLs to the new ones before flipping the switch.

A website migration is not a design project. It's a data-integrity project that happens to come with a new design attached. Treat it that way and you keep what you've earned. Treat it like a repaint and you'll be rebuilding rankings from close to zero, on a domain Google now trusts less than it did last month.

The short answer

You don't lose rankings during a migration because you changed platforms, changed domains, or redesigned the site. You lose them because you broke the paper trail Google uses to connect the old URL to the new one. Fix that, and a migration is close to a non-event for SEO. Skip it, and you're rebuilding trust you already had.

The honest answer is that the technical part of a safe migration isn't hard. It's tedious. Somebody has to sit down, pull every URL that currently gets traffic or has backlinks, and decide exactly where each one goes on the new site. Most migrations that go wrong skipped that step because it felt like busywork next to picking fonts and colors.

What actually matters here

The redirect map. Before anything else moves, you need a spreadsheet: every old URL in one column, its exact new-site destination in the other. Pull the list from your XML sitemap, your analytics' top-pages report, and your server logs, not from memory. Google's own migration guidance is built around this same idea: prepare the mapping first, test it, then cut over.

Same URL structure where you can. If your new site can keep the same URL paths as the old one (just a new domain, or a new platform behind the same paths) you don't need per-page redirect logic at all. That's the cheapest, lowest-risk migration there is. Most platform switches force at least some path changes, which is fine, as long as every changed path is in the map.

301s, not 302s, not meta refresh. A 301 tells Google the move is permanent and to transfer ranking signal. A 302 tells Google it's temporary and to keep the old URL in results. People use 302s by accident constantly, usually because it's the default in whatever platform or plugin they're using. Google is explicit that permanent, server-side redirects are the correct tool for a real move, and that they don't cost you PageRank the way people used to fear.

That gap matters more than it looks. A redirect chain (old URL → intermediate URL → final URL) works, technically, right up until it doesn't. Every extra hop is a place Googlebot can stall, and it's a place your actual visitors wait an extra few hundred milliseconds for a page to load. Redirect straight to the final destination. Don't chain a www redirect into an https redirect into a new-path redirect into the real page.

When you're changing platforms but keeping the same domain

This is the version most of the RankLoft "switch to us" conversations end up being: you keep yourourbusiness.com, but the old site was on Wix, Squarespace, or a stale WordPress build, and you're moving to something new. Google treats this as the low-risk case, as long as the visible URLs stay the same. Get the new site fully built and tested on a staging URL, lower your DNS TTL a day or two before the cutover so the switch propagates fast, then flip DNS and watch both the old host and the new one until traffic on the old server drops to zero.

Where this quietly goes wrong: the old platform used a different URL pattern than you realize. A WordPress site might have `/blog/post-title/`. The new platform might default to `/posts/post-title`. If you don't force the new build to match the old paths exactly, you've created a full migration's worth of redirect work while thinking you avoided it. Check every URL pattern (blog posts, service pages, category pages) before you assume "same domain" means "no redirects needed."

When you're changing domains entirely

This is the higher-stakes version: oldbusinessname.com to newbusinessname.com, or a full rebrand. Here you need the redirect map and the Change of Address tool in Search Console, filed under Settings once you've verified ownership of both properties in the same account. It only works domain-to-domain, not for path changes or www/https tweaks, so don't expect it to do more than it's built for.

Search Console keeps that domain relationship active for 180 days, weighting crawl priority toward your new site and forwarding ranking signals from the old one during that window. Your redirects need to outlast that window by a wide margin, though, because 180 days is how long Google actively manages the transition, not how long people keep clicking three-year-old backlinks and bookmarked pages. Plan on keeping the 301s live for at least a year.

One thing the Change of Address tool won't cover for you: www vs. non-www and http vs. https variants of both the old and new domain. Redirect all four combinations of your old domain, and all four of your new one, to the single canonical version you actually want indexed. Missing even one of those is a common way sites end up with duplicate, competing versions in Google's index after a move.

What to do the day you launch

Resubmit your sitemap the moment the new site is live, don't wait for Google to stumble onto it. Google's sitemap documentation is clear that submitting doesn't mean uploading a file to Google, it means pointing Search Console (or your robots.txt) at the new sitemap's URL so Googlebot knows where to look. If your domain changed, this is a separate step from the Change of Address filing.

Then watch the Page Indexing report in Search Console daily for the first couple of weeks. You're watching for one thing specifically: is the indexed-page count on the new site climbing toward what the old site had, or is it stalled? A stalled count almost always means redirects aren't resolving cleanly, or the new site is blocking crawlers somewhere it shouldn't (a leftover staging robots.txt is the classic culprit).

That pattern is what a well-mapped migration tends to look like: a small dip in the first two to three weeks while Google re-crawls and re-evaluates every URL, then a recovery back to baseline by roughly week eight to twelve. A broken migration doesn't recover on its own. It flatlines at a fraction of prior traffic until someone finds and fixes the mapping gaps, which is usually a much more expensive fix after the fact than getting the map right before launch.

What most businesses get wrong

The single biggest mistake is redirecting every old URL to the new homepage because it's fast and it "technically works." It doesn't. Google reads a mass homepage redirect as a soft signal that none of those old pages have a real equivalent anymore, and the ranking usually just dies instead of transferring. Every page that gets real traffic needs its own specific destination, even if that's tedious to build.

Second: losing internal links in the process. If your old site linked from the homepage to every service page, and the new build's navigation only covers half of them, you've quietly told Google those pages matter less. A site that isn't generating leads often has this exact problem baked into a migration nobody audited afterward.

Third: forgetting the www/non-www and http/https variants. We covered this above, but it's worth repeating because it's invisible until you specifically go check for it. Four URLs (http://www, http://non-www, https://www, https://non-www) all need to resolve to one canonical version, on both the old domain and the new one.

Fourth: rewriting all the content at the same time as the URLs. Changing the design is fine. Changing the URLs is fine, if mapped. Rewriting the copy on a page that already ranks, at the exact same moment you're asking Google to re-evaluate its URL, adds a second variable you can't isolate if something goes wrong. If you're rebuilding content too, do it in a second pass a few weeks after the technical migration has settled, not simultaneously.

Notice how little of that pie is the part everyone assumes is the whole job. DNS and technical cutover is the easy afternoon. Redirect mapping and pre-launch QA are the parts that take real hours, and they're the parts that determine whether you keep your rankings or spend the next quarter rebuilding them.

The bottom line

Migrating without losing rankings isn't a mystery and it isn't luck. Build the complete URL map before you touch anything else. Use permanent 301 redirects straight to the final destination, not chains, not homepage dumps. File the Change of Address tool if the domain itself is changing. Resubmit your sitemap the day you launch, and watch your indexed-page count for the first two weeks like it's telling you something, because it is.

If you're weighing whether the move should also come with a full rebuild, settle whether you need a redesign or just a platform change before you start mapping URLs, since that decision changes how much of the old structure you're even trying to preserve. And if you haven't picked the new platform yet, weighing a custom build against a template is worth doing before the migration plan, not after.

Frequently asked questions

Will my rankings drop when I migrate my website?

Some fluctuation is normal for a few weeks even on a clean migration, because Google has to recrawl and re-evaluate every URL. A real drop that doesn't recover is almost always a mapping problem: pages that got redirected to the wrong destination, or not redirected at all. A migration built on a complete URL map rarely loses rankings for more than a month.

Do I need to use Google Search Console's Change of Address tool?

Only if you're moving to an entirely new domain, like switching from oldname.com to newname.com. If you're keeping the same domain and just changing platforms, hosting, or URL paths, the Change of Address tool isn't the right tool. Google routes that signal transfer separately through your 301 redirects and a resubmitted sitemap.

How long should I keep the old website's redirects live?

At least a year, and longer if you can manage it. Google needs repeated crawls of the redirect to transfer ranking signals fully, and people still click old links, bookmarks, and backlinks for years after a move. Killing redirects early is one of the most common ways businesses quietly lose traffic six months after a migration looked successful.

Can I just redirect everything to my new homepage?

No. A blanket homepage redirect is one of the fastest ways to lose rankings on a migration. Google treats it as a soft signal that the old page no longer has a real match on the new site, and the ranking usually just dies instead of transferring. Every URL that gets meaningful traffic or has backlinks needs its own specific destination.

How soon will I know if the migration went well?

Check the Search Console coverage numbers and your top query impressions within the first 2 weeks for early warning signs, but don't judge the full outcome until 6 to 8 weeks out. Google needs time to recrawl every redirected URL, and a small dip in the first couple of weeks is normal even on a well-planned move.

Still deciding on the new address itself? Choosing a domain name for your business and weighing a .com against a local extension are worth locking down before you build the redirect map, since the destination has to be final before the mapping does any good. And if you want a second set of eyes on what's actually live on your current site before you touch anything, running the same audit process we use on competitor sites works just as well pointed at your own.