How to move your website to a new host without losing your Google rankings

Two different jobs get called "moving the website", and confusing them is how businesses lose years of accumulated ranking overnight.

What you are doing	Risk	Why
Same domain, same URLs, new server	Low	Google sees the same addresses. Only speed and uptime change.
Same domain, new platform, URLs change	High	Every old address becomes a dead end unless redirected.
New domain entirely	High	Authority has to be transferred deliberately and takes weeks to settle.

If you are only changing where the files are hosted, most of this article is precaution. If your URLs are changing, all of it matters.

Before you touch anything: inventory the current site

You cannot redirect what you have not listed. This is the step that gets skipped when a project runs late, and it is the one that costs the most.

1. Export every indexed URL from Google Search Console. The Pages report under Indexing lists what Google actually knows about, which is usually more than anybody remembers.
2. Crawl the live site with a crawler and export the list.
3. Search site:yourdomain.com and scan for anything neither method caught — old landing pages, PDFs, image pages.
4. Note which pages get traffic and which have backlinks. These are the ones that must not break.
5. Save a full backup of files and database before anything changes.

Put all of it in one spreadsheet with two columns: old URL, new URL. That spreadsheet is the whole project.

Map old to new, one to one

Each old URL points at its closest new equivalent. Not the homepage.

Redirecting everything to the homepage is the shortcut people take when time runs out, and it is barely better than doing nothing. It tells Google the original page is simply gone, and the ranking value it held does not transfer anywhere useful.

If a page genuinely has no equivalent — a discontinued service, an old event — send it to the closest relevant category page. If nothing is relevant, let it 404 deliberately. A clean 404 on a genuinely dead page is fine; a 404 on a page that used to rank is not.

Use 301, never 302

A 301 means "permanently moved, transfer the value". A 302 means "temporary, keep the old one". Several content management systems and hosting panels default to 302, which parks your rankings on pages that no longer exist.

Check what yours is actually sending rather than what it says it is sending. Any redirect checker will tell you the status code in seconds.

Avoid redirect chains

Each old URL should reach its destination in one hop.

A common accident: the old URL redirects to the non-secure version, which redirects to the non-www version, which redirects to the final page. Three hops. Every hop leaks a little authority and adds latency, and across a whole site it adds up to something measurable.

Decide on one canonical form — https, with or without www, with or without a trailing slash — and make every redirect land there directly.

The DNS switch itself

1. Lower the TTL on your DNS records to 300 seconds at least 24 hours before the move. This means the change propagates in minutes rather than a day.
2. Get the new site fully working on the new host first, tested through a temporary address or hosts file, before pointing anything at it.
3. Move email settings deliberately. This is where real damage happens. If your email is on the same provider, changing the A record without preserving the MX records takes your email offline. Note every existing DNS record before you change anything.
4. Switch the A record, then confirm the new server is answering.
5. Install the SSL certificate on the new host and confirm https works before traffic arrives.
6. Keep the old host running for at least a week. Do not cancel it the same day.

Launch day checks

In this order, within the first hour:

• Is the noindex tag gone? Staging sites are built with search engines blocked. Forgetting to remove that on launch is more common than anyone admits and makes an otherwise perfect site invisible. Check the page source for noindex, and check robots.txt is not disallowing everything.
• Do the redirects fire? Test ten old URLs by hand, including ones with and without trailing slashes.
• Does the contact form send? Submit it yourself. Form settings frequently do not survive a move.
• Is https forced? Try the http version and confirm it redirects.
• Does the sitemap load and list the new URLs?

Afterwards, in Search Console

1. Submit the new sitemap.
2. Use URL Inspection on your most important old URLs. Google should report each as a redirect, not a 404. This is your confirmation that the move worked.
3. Watch the Pages report for two to four weeks. A short dip is normal while Google reprocesses. A sustained fall means something is broken.
4. Never use the Removals tool on old URLs. Removing them destroys exactly the value the redirects are recovering.

If it has already gone wrong

It is usually recoverable. Map the old URLs, put the 301s in, remove any noindex, restore content that was cut in the rebuild, resubmit the sitemap. Rankings often return within a few weeks, because they were never truly lost — the pages holding them were simply unreachable.

What does not work is reverting to the old site. That is a second migration with a second set of risks, and it usually makes the recovery longer rather than shorter.