Google loves me - OK to change hosts?

[Tonearm]

Google is loving my site right now so I don't want to upset anything. Am I OK to change hosts and IP addresses?

[aakk9999]

I am presuming you have done basic checks that the host you want to move to will result in your site still being in a good neighbourhood and that the response times from the new host are equal or better than the current host. So that taken care of, then:

If the host is in the same country as the current one, and there are no technical issues during the host move, you will be fine.

If the host is not in the same country, you are not geotargeting via WMT and you have gTLD, then Google may change how it sees your domain being geotargeted - which in some cases may affect the SERPs.

[Tonearm]

The country is the same and the response times will be better, but how can I check on the neighborhood? The host is a very well-known and respected one.

[aakk9999]

If it is well known and respected host, then I think you have nothing to worry about.

[ken_b]

but how can I check on the neighborhood?

I'd also like to know that.

[aakk9999]

If you know the IP range of the hosting provider, you can do reverse IP lookup and see the type of sites hosted there.

[scooterdude]

Is this shared hosting you're moving to?

[Tonearm]

It's a dedicated machine with Soft Layer.

[Pjman]

I just changed hosts about a month ago to a new VPS with an SSD Drive. Ranks got better. Load time down 53% since switching to an ssd drive.

[JD_Toims]

If I was going to move this would be critical:

...and there are no technical issues during the host move...

Make *sure* after you upload your site to the new host and switch all canonicalization [via .htaccess, etc.] to your new IP address from the new server/host [so RewriteCond %{HTTP_HOST} !^(www.example.com)?$ becomes: RewriteCond %{HTTP_HOST} !^(your-site's-new\.ip\.addr\.here)?$]. Also, block everyone from your site's new IP except your IP address.

[In .htaccess it's easy:

RewriteEngine on
RewriteCond %{REMOTE_ADDR} !^your\.ip\.addr\.here$
RewriteRule .? - [F]

# Any other *redirects* here

RewriteCond %{HTTP_HOST} !^(your-site's-new\.ip\.addr\.here)?$
RewriteRule .? http://your-site's-new.ip.addr.here${REQUEST_URI} [R=301,L]

should do it]

Then make sure *everything* works the way it should via IP Address [I mean everything!] -- After you're sure everything is working, change the DNServers to point your new host, edit the canonicalization to be !^(www.example.com)?$ again and remove the REMOTE_ADDR condition + rule below it from the .htaccess file.

Top 10 Things You Don't Want During a Hosting Change:
#1 = Technical Difficulties

The other 9 are just details.

[Tonearm]

#1 = Technical Difficulties

Is this for customer-facing reasons or does Google punish that sort of thing?

Any more advice for checking out the neighborhood?

[FranticFish]

I can tell you that you *definitely* should check out the neighbourhood.

There are no new IP addresses so whenever you take out hosting you are being assigned a used IP.

I was ignorant of this when I moved to a new server taken out by a family member and found that mail sent by the server was blacklisted due to the activities of the people who had used it before.

An agency I work with took out a new server for a hobby site only to find it deluged with spam traffic due to thousands of links built to the IP address by the spammers who had owned the server before.

These were both reputable hosting providers (or so I would have thought). If I ever take out a server myself I will not go with a company that doesn't issue a guarantee that the IP has a clean bill of health.

[Robert Charlton]

Tonearm - As you've laid it out, if you've vetted your new IP, a hosting change done properly shouldn't hurt your rankings at all.

JD_Toims is correct that it's absolutely important to have the site up and running on the new IP before moving, and also to keep an operating copy of the site on your old server during DNS propagation (and I suggest for a while after). Complexity of doing this depends on whether the site is dynamic or static and how frequently the data changes.

Assuming there are no problems keeping the site copies synced... if you are not changing domain name servers, then visitors and bots will see one version of the site or the other as DNS propagates, and the transition should be seamless.

If you are changing name servers along with your hosting, which is often the case, then TTL (Time To Live) settings for your DNS enter into it as well.

A "standard reference" that we've posted on and off here for many years is Matt Cutts' article on changing your web host while keeping the same domain name. It's generally been up in our "Hot Topics" area, which we haven't displayed for a while. Here's a direct link...

Moving to a new web host
[mattcutts.com...]

I don't know the nature of your site and how important 24/7 operation is... but, IMO, it's much better to keep your hosting and your DNS servers separated, so if your hosting company has a problem, then you can easily get control of your DNS and switch to a backup copy of your site. This also allows the seamless propagation of DNS, as I note above.

You can either use your registrar for your A-records, which in some cases is adequate, or you might consider a dedicated DNS management service.

DNS fail-over to a backup site is also an option to consider. If you are needing to change the location of your domain name servers with this hosting change, this is a good time to consider your DNS management as well.

[Tonearm]

I don't think keeping two copies of the site running simultaneously is a good option for me. The site is database-driven and I don't think it's possible to keep two copies of the database in sync without opening a can of worms. Am I asking for trouble with Google if I shut down the old site when I update my DNS? People will be unable to reach the site until their DNS is updated but I don't think there is another good option for me.

As for vetting the IP address, it's easy to check for blacklists, but is there a good technique to check for other types of spam such as that which FranticFish's agency ran into? That seems tricky.

[aakk9999]

I don't think keeping two copies of the site running simultaneously is a good option for me. The site is database-driven and I don't think it's possible to keep two copies of the database in sync without opening a can of worms.

I agree it may not be worth to go there just for DNS propagation period. I would however then add a static HTML page to the old host explaining the site is moving hosting, please come back in a day when the new hosting is up. I would also return HTTP 503 on the old host together with this page.

So anyone whose DNS still resolves to old domain will get a friendly invitation to come back and if Google resolves to the old domain, Google will get the 503 response indicating the site is temporary down for "maintenance".

[FranticFish]

Tonearm, I think there are a number of different ways to find out the hostnames that have used the IP address(es) you're going to be assigned. Searching on those should let you know what sort of business activities have taken place.

Also check that those hostnames resolve to a new IP address. A client who bought his own name as a .com domain was shocked to get hatemail from people who insisted he was spamming them. It turned out that a previous host for the domain he bought had not deleted the reverse DNS entry (or PTR record) for the domain, so it was implicated in spam being sent from a completely different server to the one he was hosted on. He was 'named and shamed' on at least one busy anti-spam forum despite being completely innocent.

[Tonearm]

Many thanks to all, I will get started on this.

[engine]

I'd also add, it's worth choosing the quietest time to change over to minimise user issues.

Googlebot is unlikely to have a problem with a short delay.

[ckilgs]

Majestic SEO has a Neighbourhood Checker(I am also in no way affiliated with Majestic). Seems to be pretty useful.

[bwnbwn]

Tonearm I see one issue with your move. I strongly advise that for a least a week you keep the old site running. This prevents some servers that have a longer TTL from keeping the old IP cached thus sending the user to the dead site.
[support.google.com...]
[mattcutts.com...]
Matt says 24-48 hours I always keep the site live for a week. Just my preference.
It was recommended above to do the redirect by JD_Toims and this is a good option I just prefer to be safe and avoid any technical issues.

[JD_Toims]

The site is database-driven and I don't think it's possible to keep two copies of the database in sync without opening a can of worms.

Don't keep two copies -- Move the DB to the new host and allow access to it from the old host's IP Address until the DNS propagation is complete.

Addition: If you connect from the old host to the DB at the new host it will need to be via IP rather than domain name.

[bwnbwn]

All of ours are DB driven and I have moved them (100) websites 3 times over 10 years never had an issue leaving them both up until I could see all activity stopped at the old host.

8 years ago it was suggested 30 days, this has improved but as I said I keep them up on the old host for a least a week. Last move was from a colo host to a cloud host Nov 2013.

[Awarn]

What are you looking for in the neighborhood that might have a negative effect on your site? Do sites with sexual content reflect negatively on your site?

[JD_Toims]

Is this for customer-facing reasons or does Google punish that sort of thing?

It's for both reasons, even though the "fear" is not really "punishment" from Google, but rather a glitch you can't find right away being able to cause huge issues for visitors, search results and even possibly site security.

A short list of the many things that can go wrong just from a PHP perspective:

Your site is written in php and uses short tags <?= $variable ?>, but it's not turned on in the ini file at your new host, so as soon as you upload your PHP source is exposed to search engines and visitors as if it were HTML -- Yup, that would include database usernames, passwords and connection info if it's hard-coded on a page inside an unrecognized short-tag.

Your previous host used a different version or sub-version of PHP and one of the functions you use was available in it, but it's not available in the version the new host is running, so your script breaks.

Your previous host had Register Globals set to on, so you didn't have to declare a variable explicitly to use the array keys from $_GET, $_POST, etc. as a named variable but your new host has it set to off, so none of the information that should be received and used is present for PHP and your site breaks.

[Example of the preceding: with register globals on $_GET['variable'] is "automatically" available as $variable, but with register globals turned off you have to explicitly declare $variable=$_GET['variable'];]

And the list keeps going way farther than just PHP...

Just a couple of the many possible "little" .htaccess issues.

The old host had an AllowOverride setting inclusive of FileInfo and Limit, but the new host doesn't include Limit and you have Order, Allow, Deny to block bad bots/ip ranges in your .htaccess == 500 Server Error site-wide.

The old host had mod_expires loaded and available, but the new host doesn't, so the ExpiresActive on in the .htaccess causes a site-wide 500 Server Error.

[edited by: JD_Toims at 8:08 pm (utc) on Sep 17, 2013]

[FranticFish]

Do sites with sexual content reflect negatively on your site?

At the hosting and development business I used to work for we had one customer who sold adult satellite subscriptions and had a couple of sites streaming 100% hardcore previews on the same servers as bricks and mortar SMEs that we actively promoted to the UK market. It never did their rankings any harm.

Possible factors:
- it was 5 years ago, maybe things are different
- it was a small percentage of total sites hosted
- there were no spammy activities like hacking, mailshots, link blasts etc going on, it was just that the content was adult, there was no marketing (dodgy or otherwise) back to the server

[dkap]

Most DNS propagation completes in an hour or less these days. So, unless you have a major site with a huge user base, which probably isn't the case given the nature of the discussion, just make the switch overnight and very few people are likely to notice. Trying to maintain two copies of the site seems like major overkill.

Dan

[creative craig]

I wont rattle through my list of check points when moving a site as most have been covered off, but one thing I will say is once you have your "to do list" and have triple checked it don't second guess yourself - follow the list in military fashion and you'll come through it fine :)