Short answer: if the home page works but every inner page returns 404, WordPress is running but the server is not passing pretty URLs to it. The content is intact; the URL-rewriting layer moved badly.
Why the home page is the exception
The home page is served at the site root, which needs no rewriting. Every other URL — posts, pages, categories, archives — depends on a rewrite rule that hands the request to WordPress. When those rules are missing or ignored, only the root survives, which is exactly the pattern you see.
Fix it in the right order
- Confirm the Site and WordPress addresses in Settings › General match the new domain exactly, protocol included.
- Go to Settings › Permalinks and click Save without changing anything — this regenerates the rewrite rules and, on Apache, rewrites
.htaccess. - On Apache, confirm
AllowOverride Allis set so.htaccessis actually read; on Nginx, confirm thetry_files ... /index.php?$argsrule is present, since Nginx has no.htaccess. - Clear every cache layer, including the CDN, before re-testing.
Check for mixed old URLs too
A migration that broke permalinks often left absolute references to the old domain in the database. Those do not cause 404s alone, but they produce broken images, mixed-content warnings and odd redirects. Fix them with a search-and-replace that understands serialised data — WP-CLI’s wp search-replace 'oldurl' 'newurl' --skip-columns=guid — not a plain-text find and replace, which corrupts serialised arrays.
Verify
Test a post, a page, a category archive, a paginated listing and search. Then confirm the admin works and that no URL silently redirects back to the previous domain.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
When the home page works and inner routes 404, WordPress content is usually intact while the server rewrite layer or site base path is wrong.
- Confirm home/site URLs and the installation subdirectory after migration.
- Regenerate WordPress rewrite rules once.
- Verify Apache AllowOverride or the Nginx try_files rule actually used by this vhost.
- Test posts, pages, taxonomies, pagination, search and REST routes.
What must be verified
- Representative route types return their intended content.
- Old URLs redirect only where a valid replacement exists.
- No route silently returns to the previous domain or subdirectory.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
If my home page loads fine, does that rule out a serious problem?+
No, it's actually the telltale sign of this specific issue. The home page needs no URL rewriting because it's served at the site root, while every other URL depends on rewrite rules that hand the request to WordPress, so it working while everything else 404s points squarely at broken rewriting.
Will re-saving permalink settings work the same way on any host?+
The mechanism differs by server. On Apache, saving permalinks regenerates .htaccess, but that only takes effect if AllowOverride All is set so .htaccess is actually read. On Nginx there's no .htaccess at all, so you need the try_files ... /index.php?$args rule present in the server config instead.
I fixed the 404s, why do I still see broken images and mixed-content warnings?+
A migration that broke permalinks often also left absolute references to the old domain scattered in the database. These don't cause 404s by themselves, but they do produce broken images, mixed-content warnings, and odd redirects, and need a serialized-data-aware search and replace to fix.
Can I fix leftover old-domain URLs with a plain text find-and-replace in the database?+
No, that risks corrupting the site. WordPress stores some data as serialized arrays, where a plain text replace changes string lengths without updating the serialization metadata. Use a tool built for this, such as WP-CLI's wp search-replace with --skip-columns=guid.