Skip to content
HomeAboutProjectsBlogContactHire Me
Back to Blog
WordPress11 min read

WordPress Hosting Alternatives: 7 Errors [Solved]

Migrating to a new WordPress host? Learn how to diagnose and fix the seven most common errors that break sites after switching providers.

Written by Abdul AbrorTechnical Hosting Support Engineer
WordPress Hosting Alternatives: 7 Errors [Solved]
On this page

Switching WordPress hosts looks simple until the site goes live and nothing works. I've fixed hundreds of post-migration failures in support tickets, and the same seven errors show up again and again.

Most broken migrations aren't the new host's fault—they're caused by mismatched configurations, incomplete file transfers, or DNS timing issues that look like hosting problems but aren't. The good news? Each error has a signature symptom and a direct fix.

Error 1: Database Connection Failed

Symptoms

You see "Error establishing a database connection" on every page. The site was working on the old host five minutes ago.

Root Cause

WordPress still has the old database credentials in wp-config.php. When you moved files to the new host, the database name, username, password, or hostname changed—but the config file still points to the old values.

The Fix

  1. Log into your new hosting control panel (cPanel, Plesk, or custom dashboard).
  2. Find the database section and note the exact database name, username, and host. The host is usually localhost but some providers use 127.0.0.1 or a remote hostname like mysql.example.com.
  3. Connect to your site via SFTP or the file manager.
  4. Open wp-config.php in the WordPress root directory.
  5. Update these four lines:
define( 'DB_NAME', 'new_database_name' );
define( 'DB_USER', 'new_database_user' );
define( 'DB_PASSWORD', 'new_password_here' );
define( 'DB_HOST', 'localhost' );
  1. Save and refresh your site.

If the error persists, check that the database user has privileges on the database. In cPanel, go to MySQL Databases → Add User to Database and grant ALL PRIVILEGES.

Error 2: White Screen of Death

Symptoms

Blank white page, no error message. Sometimes the admin panel loads but the front-end is blank.

Root Cause

A PHP fatal error is firing but error display is turned off. Usually it's a memory limit hit, a plugin conflict, or incompatible PHP version between old and new host.

The Fix

First, enable error logging. Add this to wp-config.php right before the "stop editing" comment:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Refresh the site. Now check /wp-content/debug.log for the actual error.

Common fixes:

  • Memory exhausted: Increase PHP memory in wp-config.php with define( 'WP_MEMORY_LIMIT', '256M' ); or ask the host to raise memory_limit in php.ini.
  • Plugin conflict: Rename /wp-content/plugins/ to /wp-content/plugins-off/ via SFTP. If the site loads, rename it back and disable plugins one by one through the file system (rename individual plugin folders).
  • Theme issue: Switch to a default theme by renaming /wp-content/themes/your-theme/ to force WordPress to fall back to Twenty Twenty-Four or similar.
  • PHP version mismatch: Check the old host's PHP version in their control panel, then set the new host to match. Many hosts let you pick per-domain PHP versions in cPanel → Select PHP Version or MultiPHP Manager.

Error 3: Missing Images and Broken Assets

Symptoms

Pages load but images show broken icons. CSS and JavaScript might be missing too, leaving unstyled text.

Root Cause

The /wp-content/uploads/ directory didn't transfer completely, or file permissions are wrong on the new host.

The Fix

Check if the uploads folder exists and has content:

ls -lh /home/username/public_html/wp-content/uploads/

If it's empty or missing subfolders, re-transfer it from the old host. Use an FTP client in binary mode or rsync if you have SSH on both ends:

rsync -avz old-host:/path/to/uploads/ /new/path/to/uploads/

After transfer, fix permissions. WordPress needs to write to uploads, so set:

chmod 755 /home/username/public_html/wp-content/uploads/ -R
chown username:username /home/username/public_html/wp-content/uploads/ -R

Replace username with your actual cPanel or system user.

If images still 404, check the site URL. WordPress stores absolute URLs in the database (https://oldhost.com/wp-content/uploads/image.jpg). If the domain changed or you moved from HTTP to HTTPS, you need a search-replace on the database. Use WP-CLI if available:

wp search-replace 'http://oldsite.com' 'https://newsite.com' --dry-run

Remove --dry-run when ready.

Error 4: DNS Propagation Showing Old Site

Symptoms

You updated DNS hours ago, but visitors (or you) still see the old host's version of the site.

Root Cause

DNS changes take time to propagate. Your ISP or browser might be caching the old IP address. This isn't a hosting error—it's how DNS works.

The Fix

First, confirm the new host actually has the site ready. Check the new IP directly by editing your local hosts file:

On Linux/Mac, edit /etc/hosts:

192.0.2.50  yoursite.com www.yoursite.com

Replace 192.0.2.50 with the new host's IP. Visit the site in a private/incognito window.

On Windows, edit C:\Windows\System32\drivers\etc\hosts the same way (run Notepad as Administrator).

If the site works via the hosts file, DNS is the only issue. Wait up to 48 hours or flush your local DNS cache:

  • Linux: sudo systemd-resolve --flush-caches or sudo service nscd restart
  • Mac: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  • Windows: ipconfig /flushdns

To speed propagation for future visitors, lower the TTL on your DNS records before migrating (set it to 300 seconds a day in advance).

Error 5: 403 Forbidden on Entire Site

Symptoms

"403 Forbidden" or "You don't have permission to access this resource" on the homepage and every page.

Root Cause

File permissions are too restrictive, the web server can't read index.php, or .htaccess has a misconfigured access rule.

The Fix

Reset standard WordPress permissions:

find /home/username/public_html/ -type d -exec chmod 755 {} \;
find /home/username/public_html/ -type f -exec chmod 644 {} \;

Make sure wp-config.php is readable:

chmod 644 /home/username/public_html/wp-config.php

If the 403 persists, check .htaccess. Rename it temporarily:

mv .htaccess .htaccess.old

Refresh the site. If it loads, the .htaccess file had a bad rule. Regenerate it by going to WordPress admin → Settings → Permalinks and clicking Save (even without changing anything).

Sometimes the 403 comes from Apache or LiteSpeed configuration. Check the error log:

tail -n 50 /home/username/logs/error_log

Look for "client denied by server configuration" or "Options directive" errors. If you see a mod_security block, ask the host to whitelist the rule ID shown in the log.

Error 6: Mixed Content Warnings After HTTPS

So you moved from HTTP to HTTPS on the new host and now the browser shows "Not Secure" with a broken padlock?

Symptoms

SSL is installed, the site loads over HTTPS, but the browser console shows "Mixed Content" errors. Some images, scripts, or stylesheets are still loading over HTTP.

Root Cause

WordPress hardcoded HTTP URLs in the database or theme files. Browsers block mixed content (HTTPS page loading HTTP resources) for security.

The Fix

First, update the site URL in WordPress admin → Settings → General. Both "WordPress Address" and "Site Address" should start with https://.

Next, search-replace HTTP URLs in the database:

wp search-replace 'http://yoursite.com' 'https://yoursite.com' --all-tables

If you don't have WP-CLI, use the Better Search Replace plugin from the WordPress dashboard (Tools → Better Search Replace).

Finally, force HTTPS in .htaccess by adding this at the top:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Clear your browser cache and check the padlock again.

Error 7: Email Stops Working

Symptoms

Contact forms don't send. WordPress password reset emails never arrive. Your site's transactional mail is dead.

Root Cause

The old host was handling email, and you either didn't migrate email accounts or DNS MX records still point to the old server.

The Fix

Decide where email should live. Three options:

  1. Same server as the site: Create email accounts in the new host's control panel (cPanel → Email Accounts), then update MX records to point to the new host's mail server.
  2. Keep email on old host: Leave MX records pointing to the old host. Your website is on the new host, email stays behind. This is common and totally fine.
  3. Use external mail (Google Workspace, Zoho, etc.): Set MX records to the external provider's values.

Check current MX records:

dig MX yoursite.com +short

If they point to the old host and you want mail on the new one, log into your domain registrar or DNS provider and update the MX records. Typical values for cPanel hosting:

yoursite.com.  MX  0  mail.yoursite.com.

For WordPress forms specifically, install WP Mail SMTP plugin and configure it to use an external SMTP service (SendGrid, Mailgun, Amazon SES). PHP mail() is unreliable on many shared hosts.

What to check first

Before you panic about a broken migration, verify the basics. Is the new host actually serving your domain (check via hosts file)? Did all files transfer, including hidden ones like .htaccess? Did you import the entire database?

Most post-migration errors resolve in under ten minutes once you know what broke. Keep a checklist: database credentials, file permissions, DNS propagation, URL search-replace, and email routing. Work through them methodically.

If you're still stuck after trying these fixes, check the host's error logs—they tell you exactly what failed and when. The real problem is almost never the one you think it is.

Quick questions

How long should I wait for DNS to propagate?
Typically 4-24 hours. If you lowered the TTL beforehand, it's faster. Use a hosts file edit to bypass DNS entirely and test the new host immediately.

Can I keep email on the old host after moving the site?
Yes. Just point your website's A record to the new host and leave MX records pointing to the old one. The two services are independent.

Why does the site work for me but not for others?
Your DNS updated locally, but their ISP's DNS cache hasn't refreshed yet. They'll see the new site once their cache expires or they flush it manually.

Should I migrate myself or use a plugin?
For small sites, a plugin like Duplicator or All-in-One WP Migration works fine. For larger databases or custom server configs, manual migration gives you more control and fewer surprises.

The migration didn't break your host—here's what did

Nine times out of ten, a failed migration is a config mismatch, not a hosting issue. The new environment has different paths, PHP versions, or database credentials, and WordPress is still pointing to the old ones.

Fix the errors in order: database connection first, then white screens (these block everything else). After that, tackle missing assets, DNS, permissions, HTTPS, and email. Each fix takes a few minutes once you know where to look.

Keep your old host active for a week after switching. If something breaks and you can't fix it immediately, roll back DNS and troubleshoot without pressure.

Related articles