If the homepage loads but existing post URLs return 404, check the content and permalink rules before changing every slug. A moved, private or deleted post has a different problem from a server that cannot route pretty URLs.
Confirm the scope
Open several affected URLs in a private window. Check whether pages, posts and archives are all affected or only one content type. In admin, confirm the post is published, inspect its current URL and use its View link.
If one post has a changed slug, identify the original and current URLs. A redirect should connect matching content. Redirecting missing posts to the homepage does not restore the original intent.
If all URLs, including the homepage, are unavailable, check hosting and domain access first; this guide addresses routing failures for content URLs.
Refresh the existing permalink rules
- Note the current permalink setting and take a backup before any configuration change.
- Open Settings → Permalinks.
- Keep the existing structure and select Save Changes to refresh the rules.
- Retest the same affected URLs.
- Clear the relevant cache if it continues to serve an old 404 response, then test again.
Do not select a new URL structure merely to refresh rules. Changing the structure can break established links and requires a separate redirect plan.
If refreshing does not help
Ask the host to check the web server's routing for your WordPress installation. Apache rewrite configuration and Nginx routing are different; copying an Apache .htaccess snippet into an Nginx setup will not supply the missing server rule.
Tell the host whether WordPress is installed in a subdirectory and give one working and one failing URL. If the host identifies a file edit, keep a copy and have it validate the syntax. Do not replace the entire .htaccess file without preserving host, security and other application rules.
On staging, investigate rewrite-related plugins or a theme/plugin that registers a custom content type. If only that type fails, verify that its owning component is active and configured correctly. Follow the conflict process.
Verify the recovery
Retest posts, pages, archives and a genuinely nonexistent address. Existing content should load; a nonexistent address should still return a useful 404. Removing all 404 behavior can hide broken links without solving them.
Check that URLs remained unchanged and that no redirect loop was introduced. Record the actual cause, especially if server configuration changed, so the next migration does not repeat it.
Sources & verification
Sources checked September 20, 2026. Documented behavior is distinct from hands-on testing.