Most WordPress 404 errors come down to one click: go to Settings → Permalinks and click Save Changes without changing anything. That flushes the rewrite rules, which is the routing table WordPress uses to turn a pretty URL into a database query. When a theme switch, a plugin, or a migration leaves that table stale, every post 404s until you rebuild it.
If the fix does not hold, or it never worked in the first place, the cause is one of eight other things. This guide runs through them in the order a troubleshooter would actually try them, starting with how to tell which kind of 404 you have. Getting that part right saves you from editing a server config file when the real problem was a post left in Draft.
First, Work Out Which 404 You Have
The symptom pattern points straight at the cause. Check yours before touching anything.
| What breaks | What still works | Likely cause |
|---|---|---|
| Every post and page | Homepage | Stale rewrite rules or broken .htaccess (Fix 1, 2, 3) |
| One post only | Everything else | Post status, slug change, or slug collision (Fix 4, 5) |
| Only your custom post type | Normal posts and pages | Rewrite rules never flushed after registration (Fix 6) |
| The whole site, homepage included | Nothing | Server, virtual host, or DNS, not WordPress |
| /wp-admin | Front end | Plugin or theme conflict (Fix 7) |
| Old URLs you deleted | Current content | Working as intended. Redirect them (Fix 8) |
| Images and uploads | Pages and posts | File paths, permissions, or CDN, not rewrite rules |
One more check before you start: open the broken URL in a private window. If it loads there but not in your normal browser, you are looking at a cached copy of the old error and there may be nothing to fix at all. More on that below.
Fix 1: Flush the Permalink Rewrite Rules
Go to Settings → Permalinks. Change nothing. Click Save Changes.
WordPress stores its rewrite rules in the database and regenerates them when you save this screen. On Apache it also rewrites the WordPress block inside .htaccess. Any time URLs stop resolving after a theme change, a plugin update, or a move between servers, this is the first thing to try, because it costs nothing and it is the fix that works most often.
If that does not work, do the hard version: switch the structure to Plain, save, wait a few seconds, switch back to your real structure, and save again. That forces a full rebuild rather than a refresh of what is already there.
Still broken? The rules are being written somewhere the server is not reading, which takes you to the next two fixes.
Fix 2: Rebuild .htaccess (Apache and LiteSpeed)
WordPress can only update .htaccess if the file exists and is writable. If it was deleted, corrupted by another plugin, or locked down to read-only, saving permalinks appears to work and changes nothing.
Connect over SFTP or open your host's file manager, look in the WordPress root next to wp-config.php, and check for a file named .htaccess. It starts with a dot, so turn on hidden files if you do not see it. Back up whatever is there, then make sure it contains the standard block:
# 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 WordPressLeave anything outside the BEGIN and END markers alone, since caching and security plugins keep their own rules there. Set the file permissions to 644. If WordPress complains that the file is not writable, that permission is why.
Two server-side causes look identical from the dashboard: mod_rewrite not enabled, and AllowOverride set to None in the virtual host, which makes Apache ignore .htaccess entirely. Neither is fixable from WordPress. Ask your host to check both. The WordPress .htaccess documentation is worth having open for that conversation.
Fix 3: You Are on Nginx, Which Has No .htaccess
Nginx never reads .htaccess. If your host runs Nginx, and many managed WordPress hosts do, every guide telling you to edit that file is wasting your afternoon. Routing lives in the server block instead, and it needs this:
location / {
try_files $uri $uri/ /index.php?$args;
}Without that try_files line, the homepage resolves and every pretty permalink returns 404, which is exactly the pattern in row one of the table above. On managed hosting you usually cannot edit this yourself, so open a ticket and quote the directive. It is a small change on their side and support will know exactly what you mean.
Fix 4: The Post Itself Changed
When exactly one URL 404s and the rest of the site is fine, stop looking at the server. Open the post in the editor and check:
- Status. Draft, Pending, and Scheduled posts return 404 to logged-out visitors. So does a post someone moved to Trash.
- Visibility. Private posts are visible only to logged-in users with the right capability. In a private window they 404.
- The slug. Editing a title in the block editor sometimes updates the slug with it. The old URL, the one in your sitemap and everyone's bookmarks, now points nowhere.
- The date. If your permalink structure includes
/%year%/%monthnum%/, changing the publish date changes the URL.
If the slug or date moved and you want the old URL to keep working, do not rename it back and hope. Redirect it, which is Fix 8.
Fix 5: Two Things Are Fighting Over the Same Slug
WordPress resolves a URL against one rewrite rule. When two things claim the same path, one of them loses and usually 404s or shows the wrong content.
The common collisions:
- A page and a category with the same slug, when your category base is empty
- A custom post type registered with
'rewrite' => array('slug' => 'services')while a page at/services/already exists - A custom taxonomy sharing its slug with a post type archive
- A plugin registering an endpoint on a path you also use, common with membership, LMS, and e-commerce plugins
Rename one side of the collision, then flush permalinks again. Post type and taxonomy slugs are the safer side to change, since page URLs are usually the ones with links pointing at them.
Fix 6: Custom Post Types Need a Flush After Registration
This one is for developers, and it is the single most common self-inflicted 404. You register a post type, single items load fine, the archive 404s. Or the whole thing 404s until you visit the Permalinks screen, and then it works, which makes it look fixed until the next deploy.
Registering a post type adds rewrite rules in memory. They are not written to the database until something flushes them. Do it on activation, once, not on every page load:
function myplugin_activate() {
myplugin_register_post_types();
flush_rewrite_rules();
}
register_activation_hook( __FILE__, 'myplugin_activate' );Calling flush_rewrite_rules() on init is the classic mistake. It rebuilds every rule on every request and turns a routing problem into a performance problem. If a theme or plugin you inherited does this, that is worth fixing on its own.
If the post type comes from a plugin like ACF or CPT UI rather than your own code, just resave permalinks after you add or edit it.
Fix 7: A Plugin or Theme Is Rewriting Your URLs
If /wp-admin 404s, or the 404s appeared the same day you installed something, run a conflict test. On a staging copy, not on production:
- Deactivate every plugin. Test the broken URL.
- If it loads, reactivate plugins one at a time, testing after each.
- If it still 404s with everything off, switch to a default theme such as Twenty Twenty-Five and test again.
Usual suspects are SEO plugins with redirect modules, security plugins that rename login or admin paths, multilingual plugins that add a language segment to every URL, and caching plugins serving a stale route. Once you know which one, its settings usually have the switch.
Fix 8: Some 404s Should Be Redirected, Not Repaired
If you deleted a post, merged two articles, or changed a slug on purpose, the URL is supposed to be gone. The 404 is not a bug. Leaving it there is, because visitors and search engines keep arriving at a dead end.
Send the old URL to the closest equivalent page with a 301, which tells search engines the move is permanent and passes the link equity along. Use a 302 only when the original URL is genuinely coming back. Our complete guide to WordPress redirects covers the difference and the ways to implement each.
The free Redirection plugin handles this from the dashboard and logs every 404 it sees, which doubles as your monitoring. Point each dead URL at a real replacement rather than dumping everything on the homepage. A redirect to a page that has nothing to do with the request gets treated as a soft 404 anyway, so you gain nothing.
When content is gone and nothing replaces it, 410 Gone is the honest answer. It tells crawlers to stop asking, which a 404 does not.
Fix 9: Case, Slashes, and the www Mismatch
URLs are case sensitive on most Linux servers. /About-Us/ and /about-us/ are two different requests, and only one of them exists. If your old site ran on a case-insensitive setup, half your inbound links can break in a migration without anything on the site being wrong.
Check the same three things after any move:
- Trailing slash. Pick one form and redirect the other. Do not serve both.
- www. Both
example.comandwww.example.comshould resolve, with one redirecting to the other. - Site URL settings. Settings → General must match the scheme and host you actually serve, including
https.
The Fix Worked and You Still See the 404
Rewrite rules change instantly. Caches do not. Between your browser, a page cache plugin, the host's server cache, and a CDN like Cloudflare, a 404 response can be stored in four places, and any one of them will happily keep serving it.
Before you conclude a fix failed, purge the page cache, purge the CDN, and load the URL in a private window. If it works there, the fix landed and you are looking at a copy.
What to Do With the 404s You Cannot Prevent
Some 404s are permanent. People mistype URLs, other sites link to you with a typo, and old campaign links outlive the pages they pointed at. Two things make them survivable.
Give the 404 page somewhere to go. Most themes ship a bare "Page Not Found" and stop there. Add a search box, links to your main sections, and your most-read posts, so someone who lands there has an obvious next click instead of the back button.
Watch the log. The Search Console coverage report shows which URLs Google is finding and failing on, and your server access log shows every 404 including the ones no crawler reports. Patterns in that list tell you which redirects are worth writing.
Do 404 Errors Hurt Your SEO?
A 404 on a URL that should not exist is normal and harmless. Google's own documentation on HTTP errors is clear that returning 404 for missing content is correct behavior, and crawlers expect to see them.
What does cost you:
- 404s on URLs that still have links. The authority those links carry stops at the dead end instead of flowing into your site.
- Soft 404s. A page that says "not found" while returning 200, or a blanket redirect of everything to the homepage. Both confuse indexing.
- 404s on pages you meant to keep. They drop out of the index, and the traffic goes with them.
In practice that means fixing the URLs that used to work and redirecting the ones you retired deliberately. The rest can stay as they are.
Frequently Asked Questions
Why do my WordPress posts return 404 but the homepage works?
The homepage resolves without rewrite rules. Every other URL needs them. That pattern means stale rewrite rules, a missing or unreadable .htaccess on Apache, or a missing try_files directive on Nginx.
Does resaving permalinks delete anything?
No. It regenerates the rewrite rules and, on Apache, rewrites the WordPress block in .htaccess. Your posts, pages, and settings are untouched. Custom rules you added outside the BEGIN and END markers stay where they are.
I cannot find .htaccess on my server. Where is it?
It is a hidden file in the WordPress root, next to wp-config.php. Enable hidden files in your FTP client or file manager. If it genuinely is not there, either WordPress could not create it, or you are on Nginx and it would do nothing anyway.
Why does my custom post type 404 until I visit the Permalinks page?
Registering the post type adds rewrite rules in memory but does not save them. Visiting Permalinks flushes them to the database. Call flush_rewrite_rules() on plugin activation so it happens once, automatically.
Should I redirect all my 404s to the homepage?
No. Redirecting unrelated URLs to the homepage is treated as a soft 404 and helps nobody. Redirect each URL to its closest real equivalent, and leave the rest as 404 or 410.
How long does it take for a fixed 404 to disappear from Search Console?
Google re-crawls on its own schedule, so the report lags the fix by days or weeks. You can request validation once the URLs resolve, which prompts a re-check rather than waiting for the next crawl.
Wrapping Up
The order you work through these matters more than the list itself. Check which URLs actually break, flush permalinks, and move outward to the server only when the symptom points that way.
The one habit worth keeping after the site is working again: watch your 404 log for a week after any migration, redesign, or bulk slug change. That is when the URLs quietly break, and it is the only time you can still map the old ones to the new ones from memory.
Your email address will not be published