WordPress 404 Errors on Posts and Pages: Causes and Fixes (Apache and Nginx)

Applies to: WordPress 7.1.2 on Apache 2.4 (tested with 2.4.68, Ubuntu 26.04 defaults checked on 2.4.66) and Nginx 1.31; tested in Docker

When the home page of a WordPress site works but every post and page shows 404 Not Found, the web server isn’t passing those addresses to WordPress. The quickest fix is to go to Settings > Permalinks and click Save Changes without changing anything: WordPress then rewrites its rules in the .htaccess file. If that doesn’t help, work through the checks below.

First, see which 404 you have

The page tells you where the problem is:

• A plain server page that says Not Found and “The requested URL was not found on this server.” (Apache) or shows 404 Not Found with nginx underneath: the request never reached WordPress. This is a rewrite problem; see the next sections.
• Your theme’s own “Page not found” page, with your header and menu: WordPress got the request but found nothing at that address. The post is missing, unpublished or has a new address; skip to “Only one post or page gives a 404”.

Apache: .htaccess missing or damaged

Pretty permalinks such as /about/ need WordPress’s rewrite rules. When we deleted .htaccess, the home page still loaded, but /about/ and every post returned Apache’s 404 page. Saving the permalinks again recreated the file:

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

If WordPress can’t write the file, the Permalinks page says so after you save: Error: Your .htaccess file is not writable, so updating it automatically was not possible. It then shows the rules to copy. Paste them into .htaccess in the WordPress folder yourself, for example with the cPanel File Manager, or fix the file’s owner and permissions.

Apache: .htaccess is ignored (your own server)

On a VPS or dedicated server, a correct .htaccess still does nothing in two cases. We tested both and got the same 404s:

1. AllowOverride None for the site folder. This is the default for /var/www/ in /etc/apache2/apache2.conf on Ubuntu. Allow .htaccess files in your virtual host:

   <Directory /var/www/html>
       AllowOverride All
   </Directory>

2. mod_rewrite is off. It isn’t enabled after installing Apache on Ubuntu. Because the rules sit inside <IfModule mod_rewrite.c>, Apache skips them silently. Enable it:

   sudo a2enmod rewrite

Then check the configuration and restart: sudo apache2ctl configtest && sudo systemctl restart apache2. More on the rules themselves in how to use Apache mod_rewrite. On LiteSpeed servers, see 404 errors on WordPress with LiteSpeed.

Nginx: missing try_files fallback

Nginx doesn’t read .htaccess at all, so saving the permalinks changes nothing. The server block must send unknown addresses to index.php. With try_files $uri $uri/ =404; (a common default) our posts and pages returned Nginx’s own 404. This line, which WordPress documents for Nginx, fixed them:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Test and reload with sudo nginx -t && sudo systemctl reload nginx.

Only one post or page gives a 404

• It isn’t published. A draft, a scheduled post and a trashed post all give the theme’s 404 to visitors. Check the status in Posts or Pages, including the Trash view.
• The address changed. WordPress remembers old slugs: when we renamed a post and a page, the old addresses redirected with a 301 to the new ones. For other changes, add redirects for important old addresses yourself; see setting up redirects in WordPress. The Redirection plugin described there also logs 404s, which helps you find broken links.
• A plugin that adds its own type of content (a shop, events, a custom post type) can give 404s until the rewrite rules are rebuilt. In our test, an “event” post type added without rebuilding them returned 404 until we saved the permalinks once; then it loaded.

To show visitors a helpful page when something is really missing, see creating a custom 404 page.

Official documentation: WordPress on Apache (.htaccess) and WordPress on Nginx.