WordPress Permalinks Broken: Fix 404 Errors on All Pages

Your homepage loads fine, but click into any post, page, or category and you get a 404. That's almost always a permalinks problem, not a missing-content problem - and it's one of the most common things we see right after a migration, a server move, or a plugin update. Here's how to actually fix it, not just paper over it.

Symptom: What You're Seeing

The pattern is usually specific enough to diagnose from the description alone:

• The homepage (yourdomain.com/) loads normally.
• Any inner URL - a post, a page, /wp-admin in some cases, a category archive - returns a WordPress or server-level 404.
• Switching the permalink structure to "Plain" (?p=123) in Settings → Permalinks makes the pages load again.
• Nothing changed in the content itself - the post is still there in the database and in wp-admin.

That last point is the tell. If the content exists and only the pretty URL fails, the rewrite layer between Apache/Nginx and WordPress is broken, not the site.

Why It Happens

1. The .htaccess file is missing or empty

WordPress on Apache relies on a .htaccess file in the site root to translate /blog/my-post/ into the query string WordPress actually understands. Migrations are the #1 cause of this file going missing - most backup/restore tools skip dotfiles unless you explicitly tell them not to, and a fresh WordPress zip download never includes one.

2. mod_rewrite isn't enabled, or AllowOverride is set to None

Even with a correct .htaccess, Apache has to be told to honor it. If mod_rewrite is disabled, or the virtual host has AllowOverride None instead of AllowOverride All, every rewrite rule in .htaccess is silently ignored.

3. You're on Nginx, and nobody translated the rules

Nginx doesn't read .htaccess files at all. If a site was moved from an Apache-based host to an Nginx or Nginx+PHP-FPM stack (common on some VPS setups), the permalink rewrite has to be defined directly in the server block. Skip that step and every non-homepage URL 404s.

4. File permissions block WordPress from writing the file

When you click "Save" on the Permalinks screen, WordPress tries to write a fresh .htaccess automatically. If the file (or the directory) is owned by the wrong user or set to a restrictive permission, that write fails silently and the old, broken rules stay in place.

5. A security or caching plugin is intercepting requests

Less common, but worth ruling out: some security plugins (especially ones that rewrite the login URL or block "suspicious" request patterns) and full-page cache plugins can return their own 404 before WordPress's rewrite logic even runs.

The Fix

Step 1 - Re-save your permalink structure

This alone fixes it about half the time, because it forces WordPress to regenerate its rewrite rules and attempt to rewrite .htaccess.

1. Log in to wp-admin.
2. Go to Settings → Permalinks.
3. Without changing anything, click Save Changes at the bottom.

If your site loads correctly afterward, you're done. If it still 404s, move to Step 2 - the write almost certainly failed.

Step 2 - Check that .htaccess exists and has the WordPress block

In cPanel:

1. Open File Manager and navigate to your site's document root (usually public_html, or public_html/yoursite for an addon domain).
2. Click Settings (top right) and enable Show Hidden Files (dotfiles) - otherwise .htaccess won't even appear in the list.
3. Open .htaccess and confirm it contains a block like this:

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

If the file is missing entirely, create a new file named .htaccess in the document root, paste the block above, and save. If it's owned by the wrong user or set to something restrictive, right-click the file, choose Change Permissions, and set it to 644.

Step 3 - Confirm mod_rewrite and AllowOverride (Apache/VPS)

If you manage your own Apache instance on a VPS rather than shared cPanel hosting, check both settings directly:

apache2ctl -M | grep rewrite
# should print: rewrite_module (shared)

Then in your virtual host config, make sure the relevant Directory block allows overrides:

<Directory /var/www/yoursite/public_html>
    AllowOverride All
</Directory>

Restart Apache after any change: sudo systemctl restart apache2.

Step 4 - On Nginx, add the rewrite rule directly

There's no .htaccess equivalent to edit - the rule lives in the server block:

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

Add that inside your site's server { } block (usually in /etc/nginx/sites-available/yoursite), then test and reload:

sudo nginx -t
sudo systemctl reload nginx

Step 5 - Rule out a plugin

If permalinks still fail after the .htaccess and server config are confirmed correct, deactivate all plugins via File Manager (rename wp-content/plugins to plugins-disabled temporarily) and test again. If the site works, rename the folder back and reactivate plugins one at a time until the 404 returns - that's your culprit.

Prevention

• When migrating, always confirm your backup tool copies dotfiles - check for .htaccess in the destination before pointing DNS at the new server.
• After any server or stack change (Apache to Nginx, PHP version, moving to a VPS), re-save permalinks as a standard post-migration step, not just when something breaks.
• Keep a copy of your working .htaccess rules somewhere outside the site itself, so you can restore them in seconds instead of troubleshooting from scratch.
• If you're on Nginx, document the rewrite rule in your server provisioning script so it's never a manual, forgettable step.