What a WordPress 404 Error Actually Means
When you need to fix WordPress 404 errors, it helps to know what the error is telling you. A 404 means the server received the request but could not find a page at that address. WordPress itself is usually still running fine — that is why your homepage often loads while individual posts return 404. The problem is almost always routing: WordPress does not know how to map the pretty URL you clicked to the post or page stored in the database.
That distinction tells you where to look: every post 404ing points to permalinks or .htaccess, one post 404ing points to its slug, and 404s after a migration or update point to that event.
Diagnose the Pattern Before You Change Anything
Take two minutes to narrow the problem down. It will save you from changing settings that were never broken.
- All posts 404, homepage works: permalink or .htaccess problem. Go straight to Step 1.
- One post or page 404s: check its slug, its status (is it still published, or did it slip into draft or trash?), and whether a page and a post share the same slug.
- 404s after a migration or domain change: the site URL in Settings > General may still point at the old address, or the database still holds old URLs.
- 404s only for a custom post type: the post type was registered or changed without flushing rewrite rules.
- 404s only on one part of the site, like /shop/ or /portfolio/: a plugin or theme feature that owns that slug is conflicting with something else.
Test in a private browser window too, to rule out a stale cached 404.
Step 1: Flush Your Permalinks (Fixes Most Cases)
Resaving your permalink settings forces WordPress to regenerate its rewrite rules. This is the single most effective fix for WordPress 404 errors, and it takes under a minute.
- In wp-admin, go to Settings > Permalinks.
- Without changing anything, scroll down and click Save Changes.
- Visit one of the posts that was returning 404 and check whether it loads now.
If that does not work, force a full reset: switch the structure to Plain, click Save Changes, then switch back to your preferred structure (Post name is the usual choice) and save again. This rebuilds the rewrite rules from scratch rather than refreshing them. Clear your caching plugin’s cache afterwards, then retest.
See also my guide on migrating a WordPress site without breaking it — migrations are a common moment for rewrite rules to fall out of sync.
Step 2: Repair or Replace the .htaccess File (Apache Servers)
On Apache hosting, WordPress stores its permalink rules in a file called .htaccess in your site’s root folder (usually public_html). If that file is missing, corrupted, or not writable, pretty permalinks break and posts 404 even though the content still exists.
First, back up the existing file. Connect with your host’s File Manager or an FTP client, show hidden files (files starting with a dot are hidden by default), download .htaccess, and keep that copy somewhere safe. Then replace its WordPress section with the default rules:
# 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
Three rules will save you future headaches: never put custom rules between the # BEGIN WordPress and # END WordPress markers, since WordPress overwrites that block; set permissions to 644 once it works; and if WordPress cannot write the file, ask your host to confirm Apache’s mod_rewrite module is enabled and AllowOverride is set to All.
WPBeginner’s guide to fixing the WordPress .htaccess file walks through the same repair with screenshots if you want a second reference.
Step 3: If You Run Nginx, Check the Server Block Instead
Nginx does not read .htaccess files at all, so Steps 1 and 2 will not help on Nginx hosting. Permalinks on Nginx depend on a rule in the server configuration, which you usually cannot edit on shared hosting — ask your host to confirm it contains this:
location / {
try_files $uri $uri/ /index.php?$args;
}
That rule mirrors what Apache’s .htaccess block does. If it is present and posts still 404, the problem is inside WordPress — return to Steps 1 and 4.
Step 4: Isolate Plugin and Theme Conflicts
Plugins that change URLs — caching plugins, SEO plugins, redirect plugins, and multilingual plugins — can all break routing when they conflict with each other or with your theme. Test methodically rather than guessing.
- Deactivate all plugins, then check whether the 404s are gone.
- If they are, reactivate plugins one at a time, testing a broken URL after each one, until the 404 returns. The last plugin you reactivated is the culprit.
- If deactivating plugins does not help, switch briefly to a default theme such as Twenty Twenty-Five and test again. If the 404s clear, the problem is in your theme’s rewrite rules or templates.
Do this on a staging site if the site is live — see my guide on setting up a WordPress staging site. Once you find the culprit, check for an update and contact its developer with the exact URL and reproduction steps.
Step 5: Fix Slug Conflicts and Custom Post Type 404s
WordPress cannot serve two pieces of content at the same URL. If you have a page called “Services” and a post category or custom post type also using the slug services, one of them will win and the other will 404. Rename one slug — edit the page or post, change the slug under the title, and set up a redirect from the old URL (Step 6) if the old URL was already indexed or shared.
Custom post types have their own version of this: registering one, or changing its slug, does not automatically rebuild rewrite rules. The fix is Step 1 again — resave permalinks. Developers should flush rules once on activation, never on every page load.
Also check the post’s status first: a post set to Draft, Private, or Trash 404s for visitors even though you can still see it logged in.
Step 6: Redirect Deleted or Moved Pages Instead of Leaving 404s
Some 404s are legitimate — you deleted a page, or you changed its URL on purpose. Leaving those URLs to 404 is still a problem: visitors arriving from search results or old links hit a dead end, and search engines eventually drop the page. Set up a 301 redirect from the old URL to the closest relevant live page.
Use a plugin such as Redirection for a dashboard interface with 404 logging, or add the redirect to .htaccess above the WordPress block. Redirect to the closest matching page, not the homepage — a blanket homepage redirect confuses visitors and search engines, and Google treats it as a soft 404.
For a page with no good replacement, build a helpful custom 404 page with a search box and links to popular posts — one obvious next step instead of a dead end.
How to Prevent WordPress 404 Errors
- Resave permalinks after every migration, domain change, post-type change, or major plugin activation.
- Test a handful of old URLs after any URL-structure change, and set up redirects before you delete or rename a popular page.
- Keep a backup before editing .htaccess or changing permalink settings — see my complete WordPress backup guide if you do not have a routine yet.
- Monitor 404s in Google Search Console under Pages, and in your redirect plugin’s logs, so you catch broken links from external sites early.
- Avoid editing .htaccess directly on a live site without a backup, and never paste rewrite rules from a forum post without understanding what each line does.
Work through these steps in order and you will fix WordPress 404 errors in nearly every case, without touching the database or reinstalling anything. Reinstalling core is almost never the answer to a 404. Routing is.
Still stuck? The remaining causes are usually server-level — a misconfigured virtual host or a proxy stripping paths — so open a ticket with your host listing the exact URLs, the pattern you found, and what you tried. Or get in touch through my contact page and I will take a look.