After a staging site is moved to production, the home page and wp-adminwork but every post URL returns the web server’s 404 page. Saving the Permalink Settings screen appears to help briefly, yet requests handled by another server still fail.
That pattern points to routing, not missing content. Before changing redirects or repeatedly flushing permalinks, identify which layer produced the 404 and whether all serving nodes use the same document root and rewrite configuration.
What it means
A permalink 404 occurs when a readable WordPress path never reaches the front controller or when WordPress cannot resolve the resulting query. Server rewrite rules, virtual-host configuration, multisite paths, custom post-type registration, endpoint conflicts, and the status or slug of one item can all be responsible.
A server-branded 404 and a WordPress theme’s 404 page are different evidence. So is a failure affecting every friendly URL compared with one unavailable post. A destination redirect is not a substitute for repairing broken application routing.
A realistic WordPress example
In the migration example, a plain query such as /?p=123still opens the post while /sample-post/fails. Static files and the home page also work. One load-balanced node has the correct front-controller rule; the other still serves an older virtual-host configuration.
The lasting fix is to deploy the same active rewrite configuration to every node and reload it safely. A single supported WordPress rewrite flush can follow, but it should not be used as a recurring cure for server drift.
Why it matters and when to use it
Broken permalinks can remove most public content from navigation and search results while leaving the administration area apparently healthy. Correct diagnosis also prevents a genuine missing page from being confused with a site-wide routing failure.
Test a small route set: the home page, one post, one page, an archive, a plain query URL, a REST route, and a static file. Their status codes and 404 designs usually reveal whether the request stopped at the server or reached WordPress.
A straightforward route for beginners
- Back up the active web-server configuration and confirm how it can be restored.
- Check the WordPress Address, Site Address, and selected permalink structure.
- Compare a failing friendly URL with its plain-query equivalent and note whether the server or WordPress generated the 404.
- Verify the active Apache or Nginx front-controller rule and document root on every serving node.
- After correcting the server configuration, flush WordPress rewrite rules once through a supported action and retest the route set.
The advanced route
For Apache, confirm that the expected virtual host is active and that AllowOverridepermits the intended .htaccessbehavior. For Nginx, inspect the applicable try_filesrule. In containers or clusters, compare the deployed release and configuration rather than assuming every node is identical.
If only a custom post type, taxonomy, language prefix, or multisite path fails, inspect its rewrite registration and activation order. Endpoint collisions and stale generated rules can be narrow problems even when ordinary posts work.
Risks, common mistakes, backup, and rollback
Do not overwrite .htaccesswithout preserving hosting and security directives, and do not add broad redirects to hide a routing fault. Repeatedly saving permalinks can make one node appear fixed while leaving the deployment inconsistent.
Stop and restore the prior configuration if administration, REST, feeds, or static assets regress, a reload fails, or redirect loops appear. A successful check must survive cache expiry and service reload on every node.
How AIOWS helps:
AIOWS Redirect Manager
AIOWS Redirect Manager helps separate explicit WordPress redirect rules from permalink routing. Review its rule list while diagnosing the 404 so that a redirect is not blamed for a response generated earlier by the CDN or web server.
Leave redirect rules unchanged while proving the active server rewrite and WordPress permalink state. Add a managed redirect only when a specific old URL has genuinely moved to a live, relevant replacement; it should not be used to paper over a site-wide permalink failure.
The module cannot repair an Apache or Nginx configuration, synchronize load-balanced nodes, or restore missing content. Those tasks remain with the server and content owners. Its practical role here is to keep the WordPress redirect layer visible and controlled during diagnosis.
Related AIOWS articles
- 301 Redirect in WordPress: Safe Setup and Testing
- WordPress Redirect Loop: Find and Fix the Real Cause
- WordPress Trailing Slash Redirect Problems
Conclusion and recommended route
Identify who generated the 404, compare friendly and plain-query URLs, and verify the active rewrite configuration on every node. Correct the routing layer, flush WordPress rewrite rules once if needed, and retest representative routes instead of masking the failure with redirects.
