WordPress 404 on Every Page Except Homepage: Fixed

If your WordPress site returns a 404 error on every page except the homepage, the almost-certain cause is a broken permalink configuration — either the .htaccess file is missing or wrong, or the web server isn't set up to let WordPress handle its own URLs. The homepage works because it sits at the root; every other URL gets routed through WordPress's rewrite rules, and those rules aren't reaching the server. The fix is usually fast once you know which layer is broken.

What You're Seeing

The symptoms are distinctive enough that the cause is rarely ambiguous:

• The homepage loads perfectly — posts, widgets, and menus all intact.
• Every other URL (posts, pages, category archives, the admin login at /wp-login.php, even /wp-admin/) returns a 404.
• The 404 may come from WordPress (your theme's 404 template) or from the server itself (a plain browser-level 404 with no WordPress branding).
• The problem appeared after a migration, a hosting change, a server update, or seemingly out of nowhere after a maintenance window.

The key diagnostic detail: if only the homepage works, WordPress is loading and your database connection is fine. The problem is specifically in URL routing.

Why This Happens

1. The .htaccess file is missing, empty, or wrong

On Apache-based hosts (the majority of shared hosting), WordPress relies on a .htaccess file in the site root to tell Apache to pass all requests through index.php. If that file gets deleted during a migration, corrupted by a plugin, or overwritten with wrong content, every URL except the root breaks.

2. mod_rewrite is disabled on the server

Even a perfect .htaccess file does nothing if Apache's mod_rewrite module isn't enabled. This is common after server migrations, OS upgrades, or when a host spins up a new server image and forgets to re-enable the module.

3. AllowOverride is set to None

Apache can be configured to ignore .htaccess files entirely via the AllowOverride None directive in the server config. When that's set, your .htaccess file exists but has zero effect. You'll need your host to change it to AllowOverride All for your document root.

4. Nginx with no WordPress rewrite rules

Nginx doesn't use .htaccess at all. On Nginx servers, the equivalent rewrite rules must live in the server block config file. After a migration to an Nginx host, or after a server config reset, those rules are simply absent.

5. WordPress permalink settings pointing at the wrong structure

If the site was migrated from a different domain or subdirectory and the database still holds the old siteurl / home values, WordPress generates the wrong URLs — and even correct .htaccess rules can't save a request aimed at a path that doesn't match.

6. A plugin that rewrites or deletes .htaccess

Security plugins, caching plugins, and some migration tools write their own rules into .htaccess. A bad update or an incomplete write operation can leave the file in a broken state — sometimes with no WordPress rewrite block at all.

Step-by-Step Fixes

Before you start: take a full backup of your files and database. If you're on cPanel, Plesk, or a managed host, use their snapshot feature now. A bad edit to .htaccess or a server config file can take the homepage down too.

Fix 1: Resave Your Permalinks (Try This First)

This is the lowest-risk fix and works surprisingly often — it forces WordPress to regenerate the .htaccess rewrite block.

1. Log in to WordPress Admin → Settings → Permalinks.
2. Without changing anything, click Save Changes.
3. Test a page URL. If it loads, you're done.

If you can't reach /wp-admin/ at all because even that 404s, skip to Fix 2 first.

Fix 2: Replace or Repair the .htaccess File

Connect to your site via FTP or your host's File Manager. Look in the site root (the same folder as wp-config.php) for a file named .htaccess. Note: it starts with a dot, so make sure your FTP client shows hidden files.

Rename the existing file to .htaccess.bak so you have a backup, then create a new .htaccess file with this exact content:

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

If WordPress is installed in a subdirectory (e.g., /blog/), change both RewriteBase and the final RewriteRule target to match that path. Save the file, then test again.

Fix 3: Verify mod_rewrite Is Enabled (Apache)

If the new .htaccess still doesn't help, the module may be off. On a VPS or dedicated server you control:

1. Run sudo a2enmod rewrite then sudo systemctl restart apache2.
2. Also check your virtual host config for AllowOverride None and change it to AllowOverride All, then restart Apache again.

On shared hosting, open a support ticket and ask: "Is mod_rewrite enabled and is AllowOverride set to All for my document root?" Most hosts fix this in minutes.

Fix 4: Add Rewrite Rules to Nginx

On an Nginx server, open your site's server block config (often at /etc/nginx/sites-available/yoursite.conf) and confirm it contains a block like this inside the server {} directive:

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

If it's missing, add it, then run sudo nginx -t to test the config and sudo systemctl reload nginx to apply it. On managed Nginx hosts (Kinsta, Cloudways, etc.) contact support — you won't have direct access to that file.

Fix 5: Check and Correct siteurl and home in the Database

If you recently migrated the site, the database may still hold the old domain. Open phpMyAdmin, select your WordPress database, and run:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

(Replace wp_ with your actual table prefix if it differs.) Both values must exactly match your current domain, including https:// vs http:// and with or without a trailing slash, consistently. Update them with:

UPDATE wp_options SET option_value = 'https://yourdomain.com'
WHERE option_name = 'siteurl';

UPDATE wp_options SET option_value = 'https://yourdomain.com'
WHERE option_name = 'home';

After updating, go back to Settings → Permalinks and resave.

Fix 6: Isolate a Plugin Conflict

If the above steps don't resolve it and the problem appeared right after a plugin update, a plugin may have corrupted .htaccess. Deactivate all plugins via FTP by renaming the wp-content/plugins folder to plugins.disabled, then test. If pages load, rename it back and reactivate plugins one at a time to find the culprit. The plugin conflict diagnosis guide walks through this in full detail.

When the Problem Is a Recent Migration

Migrations are the single biggest trigger for this error pattern. Beyond the siteurl/home values in the database, check that:

• The document root on the new host points to the correct folder (the one containing wp-config.php, not a parent directory).
• The new host's PHP handler (FastCGI, PHP-FPM, mod_php) is actually processing .php files — a misconfigured handler can make WordPress appear to work at the root but fail everywhere else.
• Any CDN or reverse proxy (Cloudflare, Sucuri) in front of the site isn't caching stale 404 responses. Purge the CDN cache after every change.

How to Prevent This From Happening Again

• Keep a clean .htaccess backup. Once your site is working correctly, download a copy of .htaccess and keep it somewhere safe. You can restore it in under a minute if a plugin trashes it.
• Test after every migration. Before you point DNS at a new host, test with a temporary URL or hosts-file override. Click through at least five internal links before going live.
• Don't let plugins write freely to .htaccess. Review what your security and caching plugins are adding. Some plugins have a setting to disable direct .htaccess modification — use it if you manage that file manually.
• Monitor uptime. A simple uptime monitor pings an interior page (not just the homepage) every few minutes and alerts you the moment it 404s. By the time a visitor reports it, the problem may have been live for hours.

A monthly check of your server config, especially after any hosting-level changes, catches most of these issues before your visitors do. The WordPress maintenance schedule covers exactly what to check and when.

When to Call a Professional

You should call in a professional if:

• You've replaced .htaccess, confirmed mod_rewrite is on, and corrected the database URLs — and pages still 404.
• The server is Nginx and you don't have shell access to edit the config file.
• The site is on a managed platform (WP Engine, Kinsta, Pressable) and their support hasn't been able to identify the cause.
• The 404s appeared without any obvious trigger and you suspect something deeper — a hacked wp-config.php, a tampered server config, or malware redirects. (See the guide on cleaning a hacked WordPress site if you suspect that's the case.)

If you've worked through every fix above and the site is still broken, request a free Mend diagnosis. A senior engineer will triage the exact layer that's failing — server config, database, file permissions, or something else — and quote a flat price before touching anything. Most fixes like this ship the same day.