Google rankings are lost in a migration when page URLs change without 301 redirects, or when the new site accidentally blocks indexing. Emails are lost when the MX records change before the mailboxes exist on the new server, or when old messages are left behind on the hosting that gets shut down. If you're only moving the hosting and page URLs stay the same, the SEO risk is low. If you're changing the domain, the platform or the URL structure, you need a page-by-page redirect map. Below is the complete list, in the order you work through it.
In short
- Know what kind of migration you're doing: just the hosting, the platform or the domain. Everything starts from there.
- Take inventory first: pages, email addresses, the DNS zone, a full backup.
- One-to-one 301 redirects, from each old URL to its new equivalent. Not everything to the homepage.
- Mailboxes first, MX second: new emails need somewhere to land the moment you switch.
- After the move, watch Search Console for a few weeks and keep the redirects for at least a year.
First: what kind of migration is it?
| What changes | Example | SEO risk | What else you need |
|---|---|---|---|
| Hosting only | same site, same URLs, different server | Low | Keeping the site online during the move |
| Platform or structure | site rebuilt in WordPress, new page URLs | Medium | 301 redirect map |
| Domain | from firma.com to firma.ro | Higher | 301 redirects + “Change of Address” in Search Console |
The technical side of a hosting-only move, including testing on the new server and the DNS TTL, is covered in how to move your site without downtime. Here we add what concerns Google and email.
Before the move: the inventory
Pages
- A list of every URL on the old site: from
sitemap.xml, from the “Pages” report in Google Search Console and, for large sites, from a crawler tool. - The pages that bring in visitors: in Search Console, the “Performance” report shows which pages appear in search and for what queries. Check these first after the move.
- Files with their own URLs: PDFs, images used on other websites, pages linked from ads or from your email signature.
If the site isn't in Search Console yet, add it now, before the move: see the Google Search Console guide.
- every address on the domain, including the ones nobody reads anymore but that still receive messages;
- forwarders, autoresponders and distribution lists;
- where your email lives now: with your host, Google or Microsoft. The MX records tell you this.
The DNS zone
Copy every record on the domain, not just the website's: A, CNAME, MX and especially TXT — SPF, DKIM, DMARC and the verifications for Google, Microsoft, Facebook or other services. A forgotten TXT verification can break a service you weren't thinking about after the move.
The full backup
Files, database and emails, saved outside the old hosting. If something goes wrong, this is what you rebuild from. Why a single copy isn't enough: the 3-2-1 rule.
301 redirect map
If page URLs are changing, make a two-column table: the old URL and its new equivalent. Each old URL gets a 301 (permanent) redirect to the new page that replaces it.
Rules that matter:
- one to one: a page about a service redirects to the new page about the same service. Google recommends not sending many old URLs to a single unrelated page, such as the homepage: it may be treated as a page that doesn't exist;
- no chains: the old URL points straight to the final one, not through a third;
- 301, not 302, for permanent moves;
- at least a year: Google recommends keeping redirects for as long as possible, generally at least a year.
On NBT Host hosting, you set up redirects in Enhance or in .htaccess: see the 301 and 302 redirects guide.
What to keep unchanged
A migration isn't the time for other big changes. If you can, keep:
- page titles and descriptions;
- the text of important pages and their headings;
- internal links, updated to the new URLs rather than left to go through redirects;
- each page's canonical URL, which must point to the new URL;
- image file names, if your images show up in image search.
The most common mistake: the new site is built on a test address with indexing turned off (noindex or Disallow: / in robots.txt), and the block stays in place after launch. Check this on the day of the move: see the sitemap.xml and robots.txt guide.
Email during the move
The order is what matters:
- Create the mailboxes on the new server, with the same addresses, before changing the DNS.
- Copy the old messages over IMAP, from the old server to the new one: see the moving your messages guide.
- Change the DNS. During propagation, some messages may still arrive on the old server.
- Copy once more after propagation, to catch those messages too.
- Check SPF, DKIM and DMARC on the new server, and update the settings on phones and in Outlook if the mail server has changed.
If your email is with Google or Microsoft and stays there, there's nothing to move: just copy the MX, SPF and DKIM records exactly into the new DNS zone. Business email options, explained: business email on your own domain.
Switchover day
- change the nameservers or the A record at a time of low traffic;
- check that the SSL certificate has been issued on the new server;
- send a message through every form and, for online stores, place a test order;
- open a few old URLs and check that the redirects go where they should;
- take one more look at
robots.txtand thenoindextag.
After the move
- Submit the new sitemap in Search Console.
- If you changed the domain, add the new domain to Search Console as well and use the “Change of Address” tool for the old one.
- Watch the “Pages” report for 404 errors and broken redirects during the first few weeks.
- Expect fluctuations. Google says that for a medium-sized site, it can take a few weeks or more for the new URLs to replace the old ones in search results.
- Keep the old hosting for a few days, until you're sure all messages have been moved.
- Keep the old domain and renew it if you changed domains: the redirects only work as long as the old domain exists.
The checklist at a glance
- I know what's changing: the hosting, the platform or the domain.
- I have the list of pages, including the ones that bring in visitors.
- I have the list of email addresses, forwarders and autoresponders.
- I've copied the entire DNS zone, including the TXT records.
- I have a full backup outside the old hosting.
- The 301 redirect map is done and tested.
- The mailboxes exist on the new server and the old messages have been copied.
- The new site has neither
noindexnorDisallow: /. - The new sitemap has been submitted in Search Console.
- The old hosting stays active for a few days, and the old domain stays renewed.
Frequently asked questions
Will I lose my Google rankings if I only change hosting?
No, as long as page URLs stay the same and the site doesn't go down during the move. Google sees the same content at the same URLs, served by a different server.
How long does it take for a site to recover in Google after a domain change?
There's no fixed timeline. Google says that for a medium-sized site it can take a few weeks or more, and even longer for large sites. Correct redirects and a new sitemap help.
Can I redirect all old pages to the homepage?
It's not recommended. Google may treat that kind of redirect as a page that doesn't exist, and visitors won't find what they were looking for. Send each page to its equivalent.
Do you move email too?
Yes, as part of the free migration at the start of your contract. From a cPanel account, we bring over the addresses along with their messages; from other control panels, we recreate the addresses and you save the old messages from your old account. The terms are on the Free migration page.
Do I have to transfer my domain to move my site?
No. The domain can stay with the company you bought it from; you only change the nameservers or the DNS records. If you'd still like your domain and hosting in one place, see Domains.
