How to Move Your Website Without Losing Google Rankings

You have a new host picked out, or a new builder, or a quote for a new site, and then you read a thread where someone's traffic fell off a cliff the week after launch. Now the move feels like it could undo years of search visibility in a single weekend. That worry is fair, and the risk is real, but it is also manageable. Whether you can move your website without losing Google rankings for long depends mostly on one question: will your page addresses change, or only the place the site lives? Google publishes its own ordered process for both kinds of move, and it names the mistakes that tend to cause lasting drops. Some movement after launch is normal, and Google says so. Your job is to make sure that movement is the settling kind, not the broken kind, and you can start on that today.

Does your move change your URLs, or only where the site lives?

Start here, because the answer decides which protections you need. Google treats these as two different jobs. A hosting move keeps every address exactly as visitors see it today: same domain, same paths, same pages. A move with URL changes alters at least some of those addresses, even if the pages look the same.

A hosting-only move is the lower-risk case. Google's page on changing your web hosting and SEO covers it, and it involves no redirects and no Change of Address request. You copy the site, test it, switch DNS and watch both servers until the new one carries all the traffic.

Everything else counts as a URL change. That includes a new domain, a new subdomain, a switch from HTTP to HTTPS, a switch between www and non-www, and a change in paths, such as a page moving from one folder structure to another. A new builder or CMS often changes paths without anyone announcing it, because each system has its own way of naming pages. Before you agree to a platform switch, ask one direct question: will any of my current page addresses stop working?

Google's Change of Address tool is only for moves between domains or subdomains. It is not for hosting moves, path changes, HTTPS switches or www changes, and it comes after your redirects are working, not before. If your move sits in the last row of that table, Google's own advice is to split it up where you can, because the more that changes at once, the more Google has to work out again.

What steps does Google give for a site move, and in what order?

Google's site move guide for URL changes sets out the work in a clear sequence. The order matters, because each step protects the next one. Skipping ahead, such as switching on the new site before the URL map exists, is how pages go missing. The steps below follow that guide, with the hosting-only version at the end.

Know what to expect before you start

Google expects some ranking and traffic movement while it recrawls and processes a significant change. A careful move keeps that movement small and temporary. It cannot promise that nothing moves. Google's advice at this stage is plain: "Change only one thing at a time." If a new domain, a redesign, a CMS switch and a content rewrite can happen separately, do them separately.

Prepare and test the new site

Build the new site somewhere private, then test it thoroughly before anyone can reach it. Carry over your content, images and downloads, and verify both the old and new sites in Search Console so you can watch each one. Keep the staging copy out of search while you work, and plan to remove those temporary blocks the moment the site goes live.

Map every old URL to its new home

List every current address and write down the new address each one will go to. Google suggests pulling old URLs from your sitemaps, analytics or server logs, the links report in Search Console, and your CMS. Each old page should point to the closest matching new page. Sending a pile of unrelated old pages to the homepage is something Google specifically warns against, because those URLs can end up treated as errors.

Turn on permanent redirects

Once the map is done, set up server-side redirects from each old URL to its mapped new one. Google's page on redirects and Google Search says a permanent server-side redirect is the preferred way to show that a page has moved for good, and it names 301 and 308 as permanent. Both codes are defined in the web standard RFC 9110. Google also says permanent redirects do not cause a loss of PageRank, so use one for every changed address.

Update everything that still points to old addresses

Redirects catch visitors and crawlers, but your own site should stop sending them the long way round. Update canonical tags, internal links, hreflang tags if you have them, and your XML sitemap so they all name the new URLs. Then submit the new sitemap in Search Console. For a domain or subdomain move, this is the point where you use the Change of Address tool.

Watch old and new traffic

After launch, track traffic to both the old URLs and the new ones. Traffic should shift from one to the other as Google processes the redirects. Pages that lose traffic without a matching gain on their new address are the ones to check first.

If only your host is changing

The hosting-only version is shorter. Copy the site to the new host and test it, remove any temporary crawl blocks, change your DNS, and monitor both the old and new hosts. Keep the old host running until the new one is serving all of the traffic, then retire it. If you are choosing where the site will live next, our web hosting page describes what we look after on that side.

What makes traffic drop after a website migration?

Google's documentation names the usual causes directly. Each one stops Google from connecting an old page to its new version, or stops it from reaching the new site at all. These are the failure modes worth checking, listed by the kind of problem rather than by how often each one happens:

• Missing or many-to-one redirects: Old URLs with no redirect, or dozens of unrelated pages sent to the homepage, can turn into errors or soft 404s.
• A leftover noindex or robots.txt block: Settings that kept the staging site private can go live by accident and stop Google from crawling or indexing the new site.
• Old signals left in place: Canonical tags, internal links, hreflang tags and sitemaps that still name the old URLs keep pointing Google backward.
• A redesign bundled into the move: When the content and structure change along with the address, Google may need to "relearn and reassess" the pages, which is less predictable than a straight move.
• Access problems on the new server: Firewalls, DoS protection, a slow server, failed DNS propagation or too little capacity can all keep Googlebot out.

Google does not publish a ranked list of which of these happens most, or how much traffic each one costs. Check all of them rather than guessing which one applies to you. The good news is that most of them are fixable once found, though the size of the fix varies a lot.

That last row is the reason Google keeps saying one change at a time. A missing redirect is a clear mistake with a clear fix. A page that changed its address, its words and its structure all at once gives you no clean way to tell which change caused a drop.

How long does Google take to settle after a site move?

Google does not promise a fixed settling period. Its URL-change guide says a medium-sized site can take "a few weeks or more" before Google gradually shows the new URLs, and larger sites can take longer. The move happens page by page, and it is only finished when Googlebot has visited every old and every new URL at least once. Google names three things that control the pace: how many URLs you have, how fast your server responds, and how easy the site is to crawl.

Ranking and visibility can go up and down during that time, and Google treats that as normal. For a hosting-only move, Google says the crawl rate can dip right after launch and then climb steadily over the next few days. You may also see old URLs show up in results now and then, even after the new ones are indexed.

What is not normal is a decline that keeps going while Search Console shows crawl errors, blocked pages or missing redirects. That is a problem to fix, not a phase to wait out. Keep your redirects in place for at least a year, which is Google's general guidance, and longer does no harm.

Submitting a sitemap helps Google find the new URLs, but it does not guarantee indexing or improve rankings. Google's page on asking Google to recrawl also says that requesting a recrawl over and over will not make it happen faster, so use those requests on your most important pages and then let the process run.

What can you do in one hour before the move?

You can protect yourself this week, before any contract is signed or any switch is flipped. One focused hour gives you a record of where you stand and a way to check the work later.

1. Save your baseline: In Search Console, export the Performance data by page and by query for a period before the move. Once the site changes, you cannot go back and pull the old numbers in the same form.
2. Build your URL list: Download your XML sitemap, then add URLs from analytics, server logs, your CMS and the Search Console links report. Mark the pages that bring in the most traffic and the ones other sites link to.
3. Add two columns: Next to each URL, add the new destination address and the redirect status. Every address that changes needs an entry.
4. Check the staging site: Open the new site's page source and HTTP responses and look for a noindex tag, then check its robots.txt. Test a sample of pages, forms, images, downloads, canonical tags and the analytics setup.

Do not make the staging site public just to test it. Check it privately, and confirm the blocks come off at launch.

That hour also gives you better questions for whoever handles the move. Ask them to show you the staging site, the crawl settings, the analytics and Search Console setup, the redirect test results and the rollback plan. A person who has done this work will have answers, and a vague promise turns into something you can check. If you want a second set of eyes on the testing itself, our quality assurance work covers exactly those launch checks.

What should you check in the first week and the first month?

The weeks after launch are when small mistakes are cheapest to fix. Most of the checking happens in Search Console, your analytics and your server logs. Split it into two passes: a close look in the first week, then a steady watch through the first month. If something does go wrong, Google's documentation also covers how to recover.

In the first week

Use URL Inspection on your most important pages and confirm each old address redirects to the right new one. Check the indexing and sitemap reports in Search Console, and compare search and analytics traffic for old URLs against new ones. Look at your server logs for errors. For a hosting move, Google says to watch the logs on both the old and new servers, check that DNS has updated around the world, and keep an eye on index coverage. For a URL move, submit the new sitemap and use indexing requests sparingly on the pages that changed and matter most.

Through the first month

Keep watching coverage, crawl errors and traffic. Check whether your own internal links, and the most important links from other sites, still point to old addresses. Where they do, update your own links, and consider asking the owners of key outside links to update theirs.

If something goes wrong

Recovery means finding the specific fault and fixing it: a broken redirect map, a leftover block, a DNS or server problem, a wrong canonical, a stale sitemap or missing content. Then give Google time to recrawl. If a domain move has to be undone, Google documents the steps: remove the old directives, redirect the new site back to the old one, and cancel the Change of Address request.

Is it ever better not to move at all?

Yes. If your current site already holds steady search visibility and the move is optional, postponing it is a legitimate choice. That is especially true when the move cannot keep your URLs, content, redirects and analytics intact, or has no tested way to roll back.

This has nothing to do with which platform is better. It is about what the move is meant to fix. If the real need is a fresh design, a maintenance problem, better support or one slow page, fixing that in place can carry far less risk than moving everything. Google's own guide says that combining a site move with a redesign of content and URL structure will probably cause some traffic loss while it relearns the site. If you are still deciding what kind of work your site needs, our post on website redesign versus rebuild walks through that choice.

When the move is worth it, do it with the map, the tests and the monitoring in place. When those are not possible yet, waiting until they are is the safer path.

Frequently Asked Questions About move website without losing google rankings

Will moving my website hurt my Google rankings?

It can cause temporary ups and downs while Google recrawls. You keep the risk low by preserving your important pages, redirecting every changed URL to its closest match, removing staging blocks and watching Search Console after launch.

Do I need 301 redirects when I switch website platforms?

Only if your page addresses change. Many platform switches do change them, so check. Any URL that changes should get a permanent 301 or 308 redirect to its new address.

Can I change web hosts without losing SEO?

A hosting move that keeps every URL the same needs no redirects. Copy and test the site, remove temporary blocks, change DNS, and watch both hosts until the new one carries all the traffic.

Should I use Google's Change of Address tool?

Only when you move to a new domain or subdomain, and only after your redirects are working. It is not for hosting moves, path changes, HTTPS switches or www changes.

How long should I keep redirects after a site move?

Google's general guidance is at least one year.

Why did my traffic drop after my new website launched?

Check the redirects, any noindex or robots.txt blocks, canonicals, the sitemap, server access and any content that changed. A steady decline with crawl errors or missing redirects is a problem to fix, not normal settling.

Wrapping Up

The risk of a website move comes down to one question: do your page addresses change, or only where the site lives? A hosting-only move needs careful testing and a DNS switch. A move with URL changes needs Google's full sequence: test the new site, map every old URL to its closest new page, turn on permanent redirects, update your signals and watch the traffic shift. Some movement afterward is normal, and it tends to settle when redirects, crawl access and content are intact.

With a saved baseline, a complete URL map and a checklist for the first week and month, you will know whether a dip is settling or broken, and you will know what to fix if it is broken. That turns a nervous launch weekend into a process you can watch and check.

If you would like help with the move, Web Leveling can build the URL map with you, test the redirects before launch and watch Search Console afterward. Our web design work includes planning launches so your existing pages keep a clear path to their new addresses, and if staying put is the better call for now, we will say so. We work with small and medium businesses across the country and overseas. Tell us what you are planning to move and why, and we will help you work out the safest order.

Terms