joined:July 19, 2013
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]