Quick answer: A WordPress 404 error means the server couldn’t map the URL to any content. If every page except the homepage returns 404, go to Settings → Permalinks and click Save Changes to rebuild the rewrite rules. That fixes most cases. If only one page is missing, it was trashed or its slug changed, so add a 301 redirect. After any fix, purge your page cache, because caches like LiteSpeed store 404 responses too.
This guide is part of my complete guide to fixing common WordPress errors — the hub that maps every common error to its fix.
Match Your 404 Pattern to the Cause First
Most 404 guides hand you eight fixes and let you try them in order. That wastes time, because where the 404 shows up tells you almost exactly what broke. Find your pattern in this table, then jump to the matching fix.
| Where the 404 appears | Most likely cause | Go to |
|---|---|---|
| Every page except the homepage | Rewrite rules lost: permalinks, .htaccess, mod_rewrite or Nginx try_files | Fix 1 to Fix 4 |
| One page or post | Slug changed or the page was trashed | Fix 5 |
| wp-admin or wp-login.php | A security plugin renamed the login URL | Fix 6 |
| Images and files in /wp-content/uploads/ | File missing or wrong path after a migration | Fix 7 |
| Everything, right after a migration | Wrong siteurl/home, missing .htaccess, or AllowOverride off | Fix 7, then Fix 2 and Fix 3 |
| Fixed, but visitors still see the 404 | The 404 page itself is cached | Fix 8 |
The homepage-works-but-nothing-else pattern is the giveaway for rewrite problems. The homepage loads index.php directly, so it doesn’t need a rewrite rule. Every pretty URL like /blog/my-post/ does, and without the rule the server looks for a real folder by that name, finds nothing and returns 404.
Fix 1: Resave Your Permalinks to Flush the Rewrite Rules
Go to Settings → Permalinks and click Save Changes without changing anything. Then reload a page that was returning 404.
Here’s why this works, straight from WordPress core. The file behind that screen, wp-admin/options-permalink.php, calls flush_rewrite_rules() every time the page loads. That function deletes the stored rules, rebuilds them from every registered post type and taxonomy, and on Apache tries to rewrite the WordPress block in .htaccess. So simply opening the Permalinks screen already flushes the rules; clicking Save also writes the structure you picked.
Try this first. It’s harmless, takes ten seconds, and fixes the most common trigger: a plugin that registered a custom post type (portfolio, products, events) without flushing rules, so its URLs 404 until something rebuilds them.
Fix 2: Restore the Default .htaccess File (Apache and LiteSpeed)
If Fix 1 changed nothing, WordPress probably couldn’t write to .htaccess, or another plugin broke the file. Connect with FTP or your host’s file manager, open .htaccess in the WordPress root (enable “show hidden files”), and make sure it contains the standard block from the WordPress developer docs:
# BEGIN WordPress
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]
# END WordPressLeave rules added by caching or security plugins in place, but keep them outside the # BEGIN WordPress markers, because WordPress overwrites everything between them. If WordPress is installed in a subfolder, change RewriteBase / and the last line to that folder, for example /blog/ and /blog/index.php. Rename the old file to .htaccess-old before replacing it, so you can roll back.
Fix 3: Check That mod_rewrite and AllowOverride Are On
A perfect .htaccess does nothing if Apache ignores it. Two server settings matter: the mod_rewrite module must be enabled, and the site’s directory block must allow overrides with AllowOverride All. Fresh VPS installs often ship with AllowOverride None, which is why a site moved from shared hosting to a new server can 404 on every inner page even though the files are identical.
On managed hosting you can’t change these yourself, and you shouldn’t need to. If Fix 2 is in place and inner pages still 404, send support one line: “Please confirm mod_rewrite is enabled and AllowOverride All is set for my document root.”
Fix 4: Add the try_files Rule on Nginx
Nginx never reads .htaccess, so Fixes 1 and 2 can’t help there. Saving permalinks updates WordPress’s internal rules, but Nginx still needs to hand unknown URLs to index.php. That’s one line in the site’s location / block, as shown in the WordPress Nginx docs:
location / {
try_files $uri $uri/ /index.php?$args;
}Reload Nginx after the change (sudo nginx -t && sudo systemctl reload nginx). Not sure which server you’re on? Run curl -sI https://yoursite.com | grep -i server. On hosts that put Nginx in front of Apache, the Apache rules from Fix 2 usually still apply.
Fix 5: Redirect a Single Missing Page With a 301
When the rest of the site works and one URL 404s, nothing is broken server-side. The page was trashed, unpublished, or its slug changed. Check Pages → Trash and Posts → Trash first; restoring it fixes the 404 instantly.
If the slug changed, here’s a detail most guides miss. WordPress remembers old slugs for posts and redirects them automatically through wp_old_slug_redirect(). But the core function skips hierarchical post types, so pages get no automatic redirect. Rename a page from /services/ to /web-services/ and every old link to it 404s.
Fix it with a 301. In Rank Math, enable the Redirections module, go to Rank Math → Redirections → Add New, enter the old path as the source, the new URL as the destination, and choose 301 Permanent Move. Rank Math’s 404 Monitor module will also log which missing URLs real visitors and bots are hitting, which is a better to-do list than guessing.
Fix 6: wp-admin or wp-login 404? Check Your Security Plugin
A 404 on /wp-admin/ or /wp-login.php while the front end works is almost always deliberate. Security plugins such as All In One WP Security have a rename-login-page feature that moves the login to a custom URL and returns 404 at the old one. It does its job; you just forgot the new address.
Check your email for the address the plugin sent when you enabled it. If you can’t find it, connect via FTP, open wp-content/plugins/, and rename the security plugin’s folder (for example add -off to the end). WordPress deactivates it, the default login comes back, and you can log in, rename the folder back, reactivate the plugin and note the custom URL this time.
Fix 7: Fix Image and Upload 404s After a Migration
Broken images are a different problem from broken pages, because image URLs don’t go through WordPress at all. A 404 on /wp-content/uploads/2026/05/photo.webp means the file isn’t at that path. After a migration, check two things:
- The files moved. Open the uploads folder over FTP and confirm the year/month folders exist. Migration plugins sometimes skip large media folders when they hit an upload limit.
- The URLs were updated. In Settings → General, WordPress Address and Site Address must match the new domain. Image URLs saved inside post content still point to the old domain until you run a search-replace (WP-CLI
wp search-replaceor a plugin like Better Search Replace), with a database backup first.
If pages 404 too after the move, the new server is missing the rewrite setup, so go back through Fix 2 and Fix 3. When a migration throws a server error instead of a 404, my HTTP 500 error guide covers that side, and the WordPress error log guide shows you where PHP writes the details.
Fix 8: Purge the Cache, Because 404 Pages Get Cached Too
This is the step that makes people think their fix failed. I tested it on this site on 31 October 2026 by requesting a page that doesn’t exist:
$ curl -sI https://shahbazdev.com/blog/this-page-does-not-exist/
HTTP/2 404
x-litespeed-cache-control: public,max-age=3600
x-litespeed-tag: ...HTTP.404...LiteSpeed Cache tagged the response as a 404 and marked it cacheable for 3,600 seconds. In plain terms: once a visitor hits a missing URL, LiteSpeed keeps serving that 404 for up to an hour, even after you publish the page or add the redirect. Your fix is live and visitors still see the error.
So after every 404 fix, purge. In LiteSpeed it’s LiteSpeed Cache → Toolbox → Purge All; if you use Cloudflare, purge that URL there too. Then test with a cache-buster such as ?v=123 on the end of the URL to see what the server returns right now. My guide to clearing every WordPress cache layer covers the rest.
Frequently Asked Questions
Why does my WordPress site show a 404 error on every page except the homepage?
The rewrite rules that turn pretty URLs into WordPress queries are missing or ignored. The homepage loads index.php directly, so it still works. Go to Settings → Permalinks and click Save Changes. If that doesn’t help, restore the default .htaccess block on Apache or LiteSpeed, or add try_files $uri $uri/ /index.php?$args; on Nginx.
Do 404 errors hurt SEO?
A 404 on a URL that never had value is normal and doesn’t hurt the rest of the site. The cost comes from 404s on pages that had backlinks, rankings or internal links pointing at them: that value is lost until you restore the page or 301-redirect it to the closest replacement.
Why do I still see the 404 after fixing it?
Your page cache is serving the old 404. On this site, LiteSpeed Cache marked a 404 response cacheable for 3,600 seconds, so a fixed URL can keep showing the error for up to an hour. Purge the cache (and Cloudflare, if you use it), then test with a cache-buster like ?v=123.
Does WordPress redirect a page automatically when I change its slug?
For posts, yes: WordPress stores the old slug and wp_old_slug_redirect() sends visitors to the new URL. For pages and other hierarchical post types, no. The core function skips them, so add a 301 redirect yourself, for example in Rank Math → Redirections.
Why does wp-admin show a 404 error?
Usually a security plugin renamed the login URL, and the old wp-login.php and wp-admin addresses now return 404 on purpose. Find the custom URL in the plugin’s setup email, or rename the plugin’s folder in wp-content/plugins over FTP to deactivate it and get the default login back.
Wrapping Up
Read the pattern before you touch anything. Site-wide 404s are a rewrite problem: resave permalinks, then check .htaccess, mod_rewrite or Nginx. A single 404 needs a restore or a 301. A wp-admin 404 is your security plugin doing its job. Whatever you fix, purge the cache afterwards so visitors see it.
If the 404s survive all eight fixes, or they started after a migration you’d rather not untangle yourself, get in touch and I’ll take a look.
Shahbaz Ali is a senior WordPress and Framer developer with 6+ years of agency experience, specializing in WordPress development, Framer builds, and speed optimization.