Website Migration: How to Move a Site Without Losing Rankings

A website migration is the week the address, the host, or the platform changes and you find out whether anyone can still find you. Customers bookmark the old pages. Google has already indexed them. If the new site goes live without a map from each old URL to the right new one, those visits land on errors and the rankings take longer to settle. This is the owner-level version of that move: what to change, what to leave alone, and what to watch afterward.

What counts as a website migration?

Google treats two jobs as different projects. One is a change people can see in the address bar: a new domain, a switch from http to https, or a new path such as /services instead of /page.php?id=4. That is a site move with URL changes, and it needs a redirect for every old address [1]. The other is a change nobody should notice in the URL: a new hosting company or a content delivery network, with the same links as yesterday. That one is a hosting move, and the work is copying the site, testing it, then pointing DNS at the new server [4]. Mixing those up is how a simple host change turns into a broken bookmark list.

Will rankings drop while the move is underway?

Expect a wobble, not a permanent penalty. Google says any significant change can make rankings fluctuate while it recrawls the site, and a medium-sized site often takes a few weeks before the new URLs replace the old ones in results. Larger sites take longer. The same guide is explicit that a 301 and other permanent redirects do not cause a loss in PageRank [1]. What does cause a lasting drop is a bad map: old pages sent to the homepage, a test site left blocked, or a redesign launched on the same morning as the new domain. The fluctuation is normal. A hole where your best page used to be is not.

Should the domain, the design, and the platform all change on the same day?

No. Google's own instruction is to change one thing at a time. If you want a new domain, a new content system, and a new layout, do the domain first, then the layout, not all three in one launch [1]. Search Console's Change of Address notes say the same thing from the other side: keeping the same structure helps signals pass to the new site, and combining a move with a redesign makes Google relearn each page, which usually means some traffic loss [3]. If the real problem is that the current site looks dated, settle whether you need a redesign before you also change the address.

What is different about moving host when the address stays the same?

If the URLs do not change, you do not need a redirect plan or the Change of Address tool. You copy the site to the new host, test pages, images, forms, and downloads, then update DNS so the domain points at the new server [4]. A week beforehand, lower the DNS time-to-live to a few hours so internet providers pick up the new server faster. Google also notes that its crawl rate often dips right after a host change, then climbs again over the following days, sometimes higher than before, as long as the new server is not slow or blocking the crawler. Shut the old host down only after its logs show the traffic has actually moved. Our hosting guide covers what to ask a host before you are in the middle of that cutover.

How do you map old pages to new ones?

Start with the URLs that already earn visits, not with a guess. Google's move guide says to pull them from your sitemap, from analytics, from Search Console's link report, and from the content system itself, and to include images, PDFs, and other files people already link to [1]. Each old URL gets one destination. A domain-only change can be a single rule that keeps the path and swaps the hostname. A platform change usually cannot: /about-us and /company are different pages, and someone has to write that pair down. Do not send dozens of unrelated old URLs to the new homepage. Google says that pattern confuses people and can be treated as a soft 404.

• Same path, new domain — example.com/pricing can redirect to the same path on the new domain with one rule.
• Renamed page — write a one-to-one redirect from the old path to the page that replaced it.
• Several old pages merged — those URLs may share one new page, because the content really did move there.
• Page removed on purpose — return a 404 or 410 on the new site instead of pretending it still exists.
• File people download — PDFs and images need a new address too, or old links serve a missing file.

Which redirect should you use, and how long do you keep it?

Use a permanent server-side redirect, an HTTP 301 or 308, when the page has actually moved and you are not planning to move it back. Google treats those as a signal that the new URL should be the one in search results. A 302, 303, or 307 is temporary: Googlebot will follow it, but it does not treat the target as the new canonical, so the old URL can stay in results [2]. JavaScript redirects are a last resort, because Google only sees them if it successfully renders the page. Point each redirect at the final URL. Googlebot can follow a chain of up to 10 hops, but the advice is to go direct, or at least stay under three to five hops [1]. Keep those redirects for at least a year. From a visitor's point of view, longer is better, because old emails and old ads do not update themselves.

When do you use the Change of Address tool?

Only when the site moves from one domain or subdomain to another, and only after the redirects are already in place. You must own both properties in Search Console with the same Google account. The tool then tells Google to crawl the new site in preference to the old one and to forward signals for 180 days [3]. Do not use it for http to https, for www versus non-www on the same domain, for a path change inside one domain, or for a hosting move where the URL never changed. Run it for each variant you actually verified, including www and non-www, because a request on example.com does not move www.example.com. Google recommends keeping the redirects at least 180 days and continuing to pay for the old domain for at least a year so someone else cannot buy it.

What has to come off the new site before it goes live?

Whatever you used to hide the unfinished copy. A staging site is often blocked with a noindex tag or a robots.txt rule that disallows the whole site. Both have to come off when the move starts, or Google cannot index the new pages [1]. A robots.txt disallow is the wrong tool for hiding a page anyway. Google's robots.txt guide says it manages crawling, and a disallowed URL can still appear in results if other sites link to it. To keep a page out of results you use noindex or a password, not a disallow [6]. Also check that each new page's canonical tag points at the new URL, not the staging hostname, and that Search Console verification still works on the copy you are about to launch.

What should you watch in the weeks after launch?

Traffic on the old host should fall while traffic on the new one rises. In Search Console, submit a sitemap of the new URLs. A sitemap helps Google discover those addresses faster, but it does not guarantee every URL will be crawled or indexed [5]. During the move, the old sitemap's indexed count should drop and the new one's should rise. Warnings that the old URLs are redirecting are expected [1]. Check the index report for a spike in not-found errors, and check server logs for Googlebot hitting the new host. If you use analytics, the real-time view on launch day is the fastest way to see whether people are arriving on the new site or still hitting the old one.

Which mistakes leave the new pages out of search?

Google's troubleshooting list for URL moves is short and repetitive, which is a hint that the same failures keep shipping. The new site is still noindexed or blocked in robots.txt. Redirects point at URLs that do not exist. The new server cannot handle the extra crawl, because Google fetches the old URL and the new URL in the same period. The sitemap still lists the old addresses [1]. A quieter one: the old URL keeps showing up for a while even when the redirect is correct. Google says that can happen after a domain change, because the old address is still an alternate name people recognize, and it fades as people get used to the new one [2]. That is not a reason to delete the redirect.

Who should do the move, and what does it cost to get wrong?

A domain-only change on a small brochure site is a redirect rule, a DNS check, and a Search Console pass. A platform change, especially off a builder that will not export clean URLs, is a content move plus that redirect map, and it is easy to under-quote if nobody lists the pages first. If you are leaving a builder for a site you own, the builder-versus-custom guide is the decision. The build itself sits with website development, and the ongoing cost of keeping redirects and updates in place sits with maintenance. Pricing is where the scope of a move should show up before launch week, not after the old host has already been cancelled.