When the WordPress homepage works but normal page URLs return 404, start with routing. The home request may reach index.php while pretty permalinks fail to reach WordPress. First confirm the pages still exist and are published; a routing repair cannot restore deleted content.
Separate missing content from missing routing
Choose one known published page and one invented path. Record their HTTP statuses and visible content in a logged-out session. Then check the known page in the WordPress editor, including its current slug and publication state. A private or draft page is not a reliable public test.
Where supported by the installation, compare the page's plain ID URL with its normal permalink. If WordPress redirects that request, follow and record the chain instead of assuming the ID test passed. The useful evidence is whether WordPress can resolve the record while the public path fails.
If all paths return 200 with a generic application screen, this is a different failure. Use the app-shell and real-404 checklist, not a blanket rewrite rule that sends nonexistent URLs to the homepage.
Refresh WordPress rewrite rules once
Back up the current server rules and record the selected permalink structure. In Settings, open Permalinks and save the existing choice. Do not change the public URL structure simply to see what happens. WordPress's common-error reference identifies rewrite configuration as a cause of pretty-permalink 404s.
Test the same known page immediately. If it works, check several content types and document which recent event invalidated the rules. If it fails, repeatedly saving Permalinks is unlikely to reveal a server-level restriction.
Explanatory worksheet for your own test evidence. No customer results are represented.
Identify the actual origin server
| Installation |
Evidence to request from the host |
Repair boundary |
| Apache |
Rewrite module, document root, and whether per-directory rules are read |
Preserve non-WordPress access and security directives |
| Nginx |
Active server block and fallback handling for WordPress requests |
Edit the correct virtual host, validate, then reload safely |
| Proxy in front of Apache |
Both proxy routing and origin rewrite behavior |
Do not infer the origin from one response header |
| WordPress in a subdirectory |
Public URL, application path, and routing base |
Avoid copying a root-installation snippet unchanged |
WordPress's Nginx documentation explains its server configuration approach. Nginx does not use .htaccess files. Editing one on an Nginx-only origin will not fix the active routing rules.
On Apache, do not replace an entire .htaccess file with a snippet from another site. It may also contain access restrictions, redirects, cache controls, or subdirectory-specific rules. Let the host restore the WordPress section while preserving unrelated configuration.
Check narrower exceptions
If standard pages work but a custom post type fails, inspect the plugin that registers it and any slug collision. If only old links fail after a redesign, you probably need a migration redirect map, not a global permalink reset. If media alone fails, inspect the upload URL and file delivery separately.
An edge cache can retain earlier 404 responses. Confirm the origin behavior first, then invalidate affected paths if the cache is demonstrably stale. Clearing every cache before collecting evidence can make an intermittent routing issue harder to trace.
The completion test
Verify a page, post, relevant custom content type, and nested path. Each should show its own content with the expected successful status. The invented URL must still return a genuine 404. Check the site's navigation and sitemap links as a logged-out visitor.
For a recent hosting migration, provide HandL WP the old and new routing setup, affected sample URLs, and status results through one-time repair support. A successful repair restores intended pages without disguising missing pages as successful responses.
References checked September 25, 2026. Illustrations and examples are explanatory, not customer case studies.