WordPress Website Broken After Migration? How to Fix It

A WordPress migration can look fine for five seconds. The homepage loads. Then a post returns a 404. Images are broken. Login kicks back to the old domain. Or the whole site is a blank white screen.

Don't run the migration again right away. That usually makes it worse. Figure out what moved and what didn't. Keep the old site and backup untouched until the new one works.

Start With a Quick Diagnosis

Check these URLs: the homepage, an inner page, an image file, /wp-admin/, and a form or checkout. Write down the exact error. Is it a 404? A 500? ERR_TOO_MANY_REDIRECTS? A mixed content warning? A database connection error?

Also confirm DNS points to the right server. DNS changes can take time. Test from another connection or use a DNS checker before changing WordPress.

1. Verify WordPress and Site URLs

Go to Settings → General. Check WordPress Address (URL) and Site Address (URL). Look for the old domain, missing https://, typos, or the wrong subdirectory.

If the dashboard is unavailable, check wp-config.php or the database. With WP-CLI, run wp option get siteurl and wp option get home. The official WordPress migration guide covers the available methods.

Don't leave temporary hard-coded URLs in wp-config.php forever. They override the database and cause confusion later.

2. Replace Old URLs Safely

Page builders, widgets, menus, and media often keep old domain references. Use a WordPress-aware search-replace tool. Better Search Replace, WP-CLI wp search-replace, or Interconnect/it Search Replace DB all work. Run a dry run first. Back up the database.

Never do a raw SQL find-and-replace on serialized data unless you know exactly what you're doing. Changing string lengths breaks PHP serialization and can corrupt widgets, theme options, and builder settings.

3. Clear Every Cache Layer

Clear WordPress cache, hosting cache, CDN cache, object cache, and browser cache. Test in a private window afterward.

If the site works only with caching off, cached files probably contain the old domain—or dynamic pages are being cached when they shouldn't be.

4. Refresh Permalinks

Homepage works but posts and pages return 404? Go to Settings → Permalinks. Don't change anything. Just click Save Changes. That flushes rewrite rules.

On Apache, check .htaccess. On Nginx, use the correct try_files rule. Don't paste Apache .htaccess rules into Nginx. They do different jobs.

5. Confirm All Files Were Copied

Check wp-content. Uploads, themes, plugins, mu-plugins. Compare file counts or sizes with the source when possible.

Missing images usually mean the uploads folder was skipped, placed in the wrong path, or blocked by file permissions. It's rarely a database problem.

6. Review Database Credentials

Open wp-config.php. Verify DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, and the table prefix. A wrong prefix makes WordPress act like a fresh install even when the imported tables are present.

Keep credentials private. Don't paste them into public support forums or screenshots.

7. Check HTTPS and Redirect Rules

Make sure the SSL certificate covers the new domain. WordPress, the web server, the CDN, and any security plugin all need to agree on HTTPS. Conflicting redirects create loops. Mixed HTTP and HTTPS resources break CSS, images, and scripts.

Simplify redirect rules while testing. Save the original configuration so it can be restored.

8. Test Plugin, Theme, and PHP Compatibility

The new server may run a different PHP version, memory limit, or missing extension. Check Tools → Site Health and the hosting error log.

On a staging copy, deactivate plugins and switch to a default theme to isolate a conflict. If the problem started after a PHP change, select a version supported by the current WordPress installation, theme, and plugins.

9. Regenerate Builder and CSS Files

Page builders and optimization plugins may store generated CSS or asset files. After URLs and caches are correct, use the builder's official regeneration tool. Rebuilding too early can reproduce the old paths.

10. Test Before Changing DNS Permanently

When possible, test the migrated site using a temporary URL, preview feature, or local hosts-file entry. Check forms, email, search, scheduled tasks, user logins, payment flows, and mobile layouts.

Only direct the public domain to the new server after the important journeys work. Keep the old hosting available briefly in case logs or files are needed.

Final Thoughts

Most broken migrations come down to URLs, rewrite rules, caches, missing files, or a difference between the old and new server. Work through those areas in order. Change one variable at a time.

A calm diagnosis is faster than importing the site repeatedly—and far less likely to overwrite the last working copy.