When the homepage and WordPress dashboard work but individual posts or pages return 404 errors, start by rebuilding the site’s rewrite rules. If that does not restore the affected URLs, check the web server configuration.
Before making changes, note the current permalink structure under Settings > Permalinks. Do not select a different structure unless you intend to change your public URLs.
Resave the permalink settings
In WordPress admin, go to Settings > Permalinks and click Save Changes without changing any settings.
Saving this screen makes WordPress regenerate its rewrite rules. Test an affected post in a private browser window afterward. WordPress documents the available structures and server requirements in its permalink settings guide.
Clear any page cache, CDN cache, or hosting cache if the post still shows a cached 404 response.
Flush rewrite rules with WP-CLI
If you cannot use the dashboard but have command-line access, run this from the WordPress installation directory:
wp rewrite flush
To inspect the registered rules:
wp rewrite list --format=table
An empty list can mean the site has no permalink structure configured. Check it with:
wp option get permalink_structure
If that command returns an empty value, choose and save a structure in Settings > Permalinks before flushing again.
WP-CLI also provides a hard flush:
wp rewrite flush --hard
According to the WP-CLI command documentation, --hard attempts to update the server rewrite configuration as well as WordPress’s internal rules. It requires additional configuration and is not a replacement for checking the web server.
Check .htaccess on Apache
On Apache and compatible LiteSpeed servers, WordPress commonly relies on rewrite directives in an .htaccess file. Its location depends on the site configuration. A subdirectory installation, customized document root, or separate WordPress address can place the relevant file somewhere other than the directory containing the WordPress core folders.
If saving the permalink settings does not update the rewrite configuration:
- Back up the existing
.htaccessfile before changing it. - Check the site’s document root and WordPress installation settings to identify the relevant
.htaccessfile. - Confirm that the web server can read the file.
- Check the file and parent-directory ownership. Incorrect ownership after a migration can prevent WordPress from updating the file even when its permissions appear reasonable.
- Ask the hosting provider to correct ownership or confirm the appropriate permissions rather than making the file broadly writable.
- Ask the host to confirm that URL rewriting and
.htaccessoverrides are enabled.
Do not delete custom security, redirect, caching, or multisite directives. If WordPress displays proposed rewrite rules on the Permalinks screen, add them only after backing up the existing file and preserving any custom rules.
Check the Nginx site configuration
Nginx does not use .htaccess. Resaving permalinks can refresh WordPress’s internal rules, but it cannot add routing directives to the Nginx server block.
If posts still return 404 errors, ask the server administrator or host to confirm that requests not matching real files or directories are routed to WordPress’s index.php. The WordPress Nginx configuration documentation provides example routing with try_files.
The correct path depends on whether WordPress is installed at the domain root or in a subdirectory. After changing the server configuration, the administrator must test and reload Nginx.
This distinction matters after moving a site from Apache to Nginx: copying the old .htaccess file has no effect on Nginx.
Confirm whether the problem is limited to one URL
If most posts work after flushing the rules but one URL still fails, check that specific post rather than repeating the flush:
- Confirm the post is published and not in the trash.
- Open it in the editor and verify its slug.
- Check for another post, page, category, or custom post type using a conflicting slug.
- Compare the requested URL with the site’s current domain and permalink structure.
- Check whether a redirect or caching rule is intercepting the request.
When an old URL stopped working because the domain or permalink structure was intentionally changed, add a permanent redirect from the old URL to the new one. Flushing rewrite rules does not create redirects for previously published URLs.
Check plugins and custom post types
A plugin, theme, or custom code can register rewrite rules for products, portfolios, events, and other custom post types. If only that content returns 404 errors:
- Resave Settings > Permalinks once.
- Confirm the plugin or theme responsible for the content type is active.
- Check whether its URL base conflicts with a page or another content type.
- Review recent plugin, theme, or custom-code changes.
On a staging copy, temporarily disabling the component that registers the affected routes can help identify a conflict. Do not perform broad plugin deactivation on a live store or membership site without a maintenance plan and rollback path.
If standard posts and pages also fail after the rewrite rules are rebuilt, investigate the Apache or Nginx configuration next.