What to Do When Your Website Crashes After Changing Hosts

Quick answer: If your site stops working after moving to a new host, first check that the domain points to the new server, then confirm all files and databases were copied correctly, test the site on a temporary URL, and restore a backup if needed. Contact the new host’s support if you cannot locate the problem.↗ Share on X

1. Find the First Point of Failure

When a website disappears after a host change, the first thing to do is to locate the exact step where the process broke. Most migrations involve three core actions: updating DNS, moving files, and moving the database. If any one of these fails, the site can show a 404 error, a blank page, or a server error message.

A quick way to test the DNS change is to use the `nslookup` or `dig` command on your computer. Type `nslookup yourdomain.com` and note the IP address that appears. Compare it with the IP address shown in the control panel of the new host. If the numbers do not match, the domain is still pointing to the old server.

In my own experience, I once switched a small business blog from HostX to HostY. I updated the nameserver records but forgot to delete the old A‑record. The result was a half‑hour of downtime because visitors were sent to a server that no longer had the site files. A simple DNS check would have caught the mistake.

If the IP address is correct, move on to the next step. If it is not, you have two options: wait for the DNS to finish propagating, or force the change by editing the hosts file on your own computer. The hosts file method lets you see the new site before the world does, which is useful for testing.

2. Check DNS Propagation and Records

DNS changes are not instant. The internet is made of many caching servers, and each one decides how long to keep a record. Most providers set a default TTL (time‑to‑live) of 4 hours, but some keep the old record for up to 48 hours. During that window, some visitors will see the old site while others see the new one.

To monitor propagation, use a free tool like whatsmydns.net. Enter your domain and look at the list of locations. When the majority of locations show the new IP, you can be confident that the DNS switch is complete.

While you wait, keep the old host active. Turning it off too early can cause a gap where the domain resolves to nowhere. A common mistake is to cancel the old account immediately after changing the nameservers. This creates a period where the domain points to an empty server, resulting in the dreaded "Server not found" page.

If you need the site to stay online during the switch, consider using a temporary subdomain (e.g., `staging.yourdomain.com`). Point the subdomain to the new host, test everything there, and only change the main domain once you are sure the new server works.

3. Verify File and Database Transfer

Even with a correct DNS entry, a site can crash if files or database tables are missing or corrupted. Most content management systems store the core files on the server and the content in a database. If one part is out of sync, the site will throw errors.

Start by checking the file structure. Log into the new host via FTP or the file manager and compare the number of files with the old host. A quick way to do this is to download a zip of the whole site from the old server and unzip it locally. Then compare the folder sizes. A difference of more than a few megabytes usually means something was left behind.

For the database, export a full dump from the old host (usually a `.sql` file) and import it into the new host’s database manager. After the import, run a simple query like `SELECT COUNT(*) FROM wp_posts;` (for WordPress) to see if the row count matches the old site. If the numbers differ, you may have missed a table or encountered a timeout during the export.

During my migration of an e‑commerce store, I discovered that the product images folder was not included in the zip file. The site loaded, but every product image was broken. Adding the missing folder fixed the problem in minutes.

If the site uses a specific PHP version, make sure the new host supports it. Some hosts default to a newer version that can break older plugins. Check the host’s control panel for a "PHP Selector" and set the version to match the old environment.

4. Test Server Settings and Compatibility

After files and database are in place, the next step is to test the server configuration. Common culprits are missing modules, wrong file permissions, and mismatched .htaccess rules.

File permissions should generally be 644 for files and 755 for directories. If a file is set to 777, the server may refuse to serve it for security reasons. Use the file manager to correct any permissions that look unusual.

Modules such as `mod_rewrite` are needed for friendly URLs in many CMS platforms. If the new host does not have this module enabled, URLs will return 404 errors. You can usually enable it in the control panel under "Apache Settings" or ask support to turn it on.

The `.htaccess` file often contains redirects, caching rules, and security headers. Copy the exact file from the old host; do not recreate it from memory. A missing line that forces HTTPS can cause browsers to block the site if the certificate is not yet installed.

Another practical test is to use a temporary URL provided by the new host (often something like `yourname.hostingprovider.com`). Load the site there and see if it works. If it does, the problem is likely DNS‑related. If it does not, you have a server‑side issue.

5. Restore Backups and Reach Out for Help

If the steps above do not bring the site back, it is time to use a backup. Most hosts offer daily snapshots or you may have your own backup stored on cloud storage. Restore the most recent backup to the new server and repeat the DNS check.

When you restore a backup, do not overwrite the entire database if you have already added new content on the new host. Instead, import only the missing tables or use a tool that merges data safely.

If you are still stuck, contact the new host’s support team. Provide them with the exact error messages you see, the steps you have already taken, and any logs you can access (error logs are usually found in the control panel). A clear, concise ticket speeds up the resolution.

Remember that a migration is a process, not a single click. Patience and systematic testing will keep your site online and your visitors happy.

Frequently Asked Questions

1. Why does my site show a blank page after moving hosts?

A blank page often means a PHP error or a missing file. Check the error log, verify file permissions, and make sure the correct PHP version is selected.

2. Can I move my site without any downtime?

Zero downtime is possible with careful planning. Keep the old host active, use a temporary subdomain for testing, and switch DNS only after confirming the new server works.

3. What if my DNS records are still pointing to the old server after 24 hours?

Verify the TTL value, clear local DNS cache, and use a public DNS resolver like Google (8.8.8.8) to see if the change propagated.

4. My e‑commerce checkout fails after migration. What should I check?

Look for SSL certificate issues, payment gateway callbacks, and database connection strings. A missing SSL can block secure transactions.

5. Is it safe to edit the .htaccess file myself?

Yes, but back up the original first. A single typo can break the whole site, so always test changes on a staging URL before applying them to the live domain.

Frequently asked questions

Why does my site show a blank page after moving hosts?

A blank page often means a PHP error or a missing file. Check the error log, verify file permissions, and make sure the correct PHP version is selected.

Can I move my site without any downtime?

Zero downtime is possible with careful planning. Keep the old host active, use a temporary subdomain for testing, and switch DNS only after confirming the new server works.

What if my DNS records are still pointing to the old server after 24 hours?

Verify the TTL value, clear local DNS cache, and use a public DNS resolver like Google (8.8.8.8) to see if the change propagated.

My e‑commerce checkout fails after migration. What should I check?

Look for SSL certificate issues, payment gateway callbacks, and database connection strings. A missing SSL can block secure transactions.

Is it safe to edit the .htaccess file myself?

Yes, but back up the original first. A single typo can break the whole site, so always test changes on a staging URL before applying them to the live domain.