WordPress
How to fix a WordPress 404 error

Short answer
A WordPress 404 error shows up when you visit a post, page, or category address and WordPress can’t find content that matches it. The content itself is usually still safe in the database; the real cause is almost always the permalink rules that map URLs to content,
and those rules can go stale or incomplete over time.. This guide walks through how to fix a WordPress 404 error in order, starting with the most common cause and working toward the rarer ones. Worked through in the right order, most cases clear up in a few minutes with no risk to your content.
Why does WordPress show a 404 error?
WordPress uses a rewrite layer that turns “pretty” addresses (like /blog/post-title/) into the actual content queries behind them. That layer can break down for a few different reasons:
- The permalink rules were never generated properly, or drifted out of sync over time
- The server’s
.htaccessfile was deleted, corrupted, or overwritten - A plugin or theme added its own URL structure that conflicts with the existing rules
- The site moved to a new server, but the server configuration (such as mod_rewrite) wasn’t set up the same way
- The post itself was deleted, moved, or unpublished, in which case the 404 is accurate, not a configuration bug
What most of these share is that the problem sits in how WordPress maps an address to content, not in the content itself.
Is the error site-wide or limited to specific URLs?
Before fixing anything, pin down the scope. If the homepage loads fine but every post and page returns a 404, the cause is almost certainly the permalink rules or the .htaccess file. If only one specific post or category is affected, check that content’s own status first, whether it’s a draft, has been deleted, or had its address changed.
This distinction matters because in the first case the general fixes below apply even if you can reach the dashboard; in the second case, what you actually need is the content’s correct current address or status.
Reset your rewrite rules first
The fastest fix, and the one that works most often, is forcing WordPress to rebuild the permalink rules. In the dashboard, go to Settings → Permalinks, then click “Save Changes” at the bottom of the page without changing anything. Nothing visibly changes, but behind the scenes WordPress regenerates the rules that map your URL structure to your content and, on Apache servers, writes them into the .htaccess file.
If one click doesn’t resolve it, try switching to a different structure (like “Plain”), saving, then switching back to your original structure (such as “Post name”); this forces the rules to be rebuilt from scratch. Taking a backup before making any change is always a good habit.
Rebuild the .htaccess file by hand
If you can’t reach the dashboard, or resaving permalinks didn’t help, check the .htaccess file directly. Using FTP or your host’s file manager, go to your site’s root directory, rename the current file as a backup, then make sure the standard WordPress rule block below is present in full:
# 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 doesn’t exist, create it with this block. If Apache’s mod_rewrite module isn’t enabled on your server, these rules won’t do anything, in that case your hosting provider needs to enable the module.
Can’t log into the dashboard at all? Reset from the database
If you can’t reach the dashboard at all, even the login screen returns a 404, you can reset the permalink rules straight from the database. Open phpMyAdmin or your host’s database tool, find the rewrite_rules row in the wp_options table, and delete it. WordPress regenerates the rules automatically on the next page load. If you have WP-CLI access, the same thing is a single command: wp rewrite flush.
Check for a plugin or theme conflict
If resaving permalinks doesn’t hold, the error comes back after a few days, suspect a plugin or theme adding its own URL structure that conflicts with the existing rules. Plugins that add custom post types or multilingual support are common culprits; they insert their own URL patterns ahead of or behind WordPress’s core rules, and when that order breaks, certain addresses start returning 404s. Deactivate plugins one at a time, resaving permalinks after each, to find the one responsible.
A 404 error after moving to a new server
A jump in 404 errors right after moving a site to a new server or host is common. It’s usually because the old server’s .htaccess file wasn’t carried over, the new server’s mod_rewrite module is configured differently, or the server runs Nginx, where Apache-specific rules don’t apply at all (Nginx needs an equivalent rewrite rule set up in its own server block). If you’re seeing more 404s right after a migration, check what type of web server you’re now on, Apache or Nginx, and confirm the rules were translated into the right format.
Browser or CDN caching can mimic an already-fixed 404 error
You resaved permalinks and the fix worked, but some visitors still see a 404. The culprit is no longer WordPress, it’s caching. Browsers hold onto 404 responses for a while; someone who hit that address before your fix can keep seeing the old, broken response even after the fix is live. Testing in a private browsing window or on a different device shows right away whether you’re looking at a real, ongoing problem or just a local cache.
If your site sits behind a CDN or a page-caching plugin, such as Cloudflare, that layer can keep serving the old 404 response to visitors too. In that case, clear the cache for that specific address from your CDN dashboard or your caching plugin’s settings; otherwise, even after correctly fixing the permalinks, a WordPress 404 error keeps showing up for some visitors.
When a 404 error for deleted or moved content is actually correct
Not every 404 is a configuration bug. Sometimes it’s accurate: the post was deleted, set back to draft, or had its address changed. In that case, the right fix is a 301 redirect from the old address to the new one, either through a plugin or by adding a Redirect 301 line to .htaccess by hand. This step matters especially for traffic arriving from search engines; quietly removing a page sends every visitor and every search signal pointed at that address straight into a 404.
Avoiding a WordPress 404 error next time
Most of this is preventable. Make resaving permalinks a habit whenever you change your content structure, a new category or custom post type included; always set up a redirect when removing or renaming a page; and when migrating servers, explicitly confirm the .htaccess file made the move too. As our guide to the WordPress 403 Forbidden error shows from the server access side, 403 and 404 come from different layers: one rejects the request before it reaches WordPress, the other lets WordPress handle it but finds no matching content. If you’re dealing with a broader access issue, our guide to the WordPress white screen of death walks through the diagnostic order step by step.
If you want to see how WordPress generates these matching rules in its own core code, WordPress’s official wp-includes/class-wp-rewrite.php source code is worth a look; the documentation for its flush_rules() method states directly that a “hard” flush updates the .htaccess file, while a “soft” flush only updates the stored rule option in the database, which is the technical reason resaving permalinks actually works.
Next step
A WordPress 404 error looks alarming, but it’s usually a mapping problem fixed by resaving permalinks or rebuilding .htaccess, with no risk to your content. If the cause turns out to be a server migration or a deeper plugin conflict, our group company Web Tasarım Ofisi supports WordPress maintenance and technical troubleshooting.
To talk through your site’s technical setup or a custom software need, take a look at our custom software service or get in touch with Argo Ajans.
Frequently asked questions
What does a WordPress 404 error mean?
It means WordPress couldn't find content matching the address the browser requested. The content is usually still sitting safely in the database; the problem is typically the permalink rules that map addresses to content, not the content itself.
Does a 404 error cause data loss?
No. This is a routing/matching problem, your posts and pages stay safe in the database. Resaving permalink settings or rebuilding .htaccess doesn't touch your content.
Why does resaving permalinks fix it?
When you click "Save Changes" on the Permalinks screen, WordPress rebuilds the rules that map your URL structure to your content from scratch and, on Apache servers, writes them into the .htaccess file. That refreshes a mapping that can drift or go incomplete over time.
What if I can't log into the dashboard?
You can reset the permalink rules straight from the database: deleting the rewrite_rules row in the wp_options table through phpMyAdmin tells WordPress to regenerate the rules on the next page load. If you have FTP access, you can also add the standard WordPress rule block to .htaccess by hand.
What should I do if nothing works?
Share exactly which URLs trigger the error and which steps you've already tried with your hosting provider's support team, the cause may be something you can't see from your own panel, like the mod_rewrite module being disabled on the server.