How to Fix 404 Errors in WordPress (2026)

A 404 error means “page not found” — the visitor or search engine asked for a URL that no longer exists on your server. On WordPress, 404s come in two very different flavors, and the fix depends entirely on which one you’re dealing with. Sometimes every post on the site suddenly 404s because the permalink rules broke. Other times a single old URL 404s because you deleted a page or changed its slug. The first is an emergency to fix in minutes; the second is an ongoing SEO housekeeping task.

This guide covers both. We’ll start with site-wide and structural 404s caused by broken permalinks and .htaccess issues, then move to individual 404s and soft 404s — how to find them, judge their SEO impact, and decide whether to redirect, restore, or simply leave a helpful error page. Along the way we’ll cover the 404s that show up after a migration or slug change, how to build a custom 404 page that actually helps, and the important case people forget: when a 404 is the correct answer and you should not redirect it anywhere.

Angle 1: Whole-Site or Post 404s from Broken Permalinks

If your homepage loads fine but every individual post and page returns “404 Not Found,” the culprit is almost never missing content. It’s your permalink rewrite rules. WordPress uses pretty URLs like /how-to-fix-404-errors/ instead of /?p=123, and that translation depends on rewrite rules stored in the database plus a rewrite block in your .htaccess file. When either gets out of sync, WordPress can’t map the request to the right post and serves a 404.

Fix 1: Flush your permalinks

This is the single most effective fix, and it takes ten seconds. In your dashboard, go to Settings → Permalinks and click Save Changes — you don’t need to change any option. Just saving forces WordPress to regenerate its rewrite rules and, on Apache, rewrite the .htaccess block. A large share of sudden site-wide 404s clear up immediately after this. It’s the same “flush permalinks” step referenced in our roundup of common WordPress errors and fixes, and it’s always worth trying first.

Fix 2: Repair or recreate the .htaccess file (Apache)

If saving permalinks doesn’t help, your .htaccess file may be missing, corrupted, or not writable. On Apache hosting, WordPress needs a rewrite block that looks like this in the root of your installation:

# 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

Connect via FTP or your host’s file manager, confirm .htaccess exists in the WordPress root, and make sure it contains the block above. If the file is missing entirely, WordPress usually can’t write it when permissions are locked down — set the file to 644 temporarily, save permalinks again, then tighten permissions back. If you edited the file by hand, restore the standard block exactly as shown.

Fix 3: Confirm mod_rewrite (or the Nginx equivalent) is active

Pretty permalinks depend on URL rewriting at the server level. On Apache, the mod_rewrite module must be enabled; some budget shared hosts disable it or restrict AllowOverride, which stops .htaccess directives from taking effect. If flushing permalinks and fixing the file both fail, ask your host whether mod_rewrite is on and whether .htaccess overrides are permitted.

If you’re on Nginx, there is no .htaccess file at all — rewrite rules live in the server config. The standard WordPress rule is:

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

On managed WordPress hosting this is usually already in place, but a misconfigured or migrated Nginx block is a frequent cause of every-URL-404 after a server move. You’ll need your host to add or correct it, since it can’t be changed from the dashboard.

Fix 4: Check for a plugin or theme conflict

Occasionally a security, caching, or redirect plugin hijacks rewrite handling and forces 404s. Temporarily deactivate plugins (rename the /wp-content/plugins folder via FTP if you’re locked out of admin) and switch to a default theme to isolate the cause. If the 404s vanish, reactivate items one at a time until the offender reveals itself.

Angle 2: Individual 404s, Soft 404s, and Their SEO Impact

Once the structural problems are solved, you’re left with the more common day-to-day situation: specific URLs that 404 because content was deleted, moved, or renamed. A handful of individual 404s will not sink your site — returning a genuine 404 for a page that truly no longer exists is completely normal and expected. The SEO problem arises when URLs that earned links, traffic, or rankings start 404ing, because that value evaporates instead of being passed to a live page.

Soft 404s are a subtler issue. A soft 404 is a page that returns a 200 OK status but has little or no real content — an empty search result, a thin archive, or a “no products found” page. Google flags these because the status code lies about what the user actually sees. They waste crawl budget and can dilute quality signals. The fix is to make the page return an honest status (a real 404 or 410 if it should be gone) or to add substantive content if the page should stay.

Finding your 404s

You can’t fix what you can’t see. Use these sources together:

• Google Search Console. The Pages (formerly Coverage) report lists URLs excluded as “Not found (404)” and separately flags “Soft 404.” These are the 404s Google has actually tried to crawl, which makes them the highest priority — Google knows about them and is spending crawl budget on them. This is the same report we lean on in our guide to technical SEO for WordPress.
• A crawler. Tools like Screaming Frog or Ahrefs Site Audit crawl your live site and follow internal links, surfacing 404s that visitors hit from your own navigation and content. Internal links pointing to dead URLs are worth fixing first because they waste crawl budget and frustrate real users.
• Server logs and analytics. Your access logs and analytics 404 reports show which missing URLs get real traffic — often from external links or bookmarks you’d never find otherwise.

The three-way decision: redirect, restore, or keep the 404

For every 404 worth acting on, choose one of three outcomes.

1. Redirect (301) to a relevant page. If the content moved, was merged, or was replaced, send a permanent 301 redirect from the old URL to the closest matching live page. This preserves the link equity and ranking history the old URL accumulated, and it takes visitors somewhere useful. The key word is relevant — a 301 should point to a genuine successor, not a generic destination. For the mechanics of setting these up at scale in WordPress, see our WordPress redirects guide.

2. Restore the content. Sometimes a URL 404s because a page was deleted or unpublished by mistake, or because it still earns steady traffic and links. If the content is worth having, the best move is to restore or rewrite it at the original URL. This recovers the page’s value directly rather than diverting it elsewhere.

3. Leave a genuine 404. If a URL has no meaningful equivalent, never ranked, and earns no links or traffic, the correct answer is to let it return a clean 404 (or a 410 Gone if you want to signal deletion is permanent). This is not a failure — it tells search engines the page is genuinely gone so they can drop it from the index. Forcing a redirect here just creates clutter.

Don’t redirect everything to the homepage

This is the most common 404 mistake, so it deserves its own warning. When people discover a pile of 404s, the tempting shortcut is to bulk-redirect every dead URL to the homepage. Don’t. Google treats a redirect to an irrelevant page — especially the homepage — as a soft 404, so you gain nothing and add a confusing hop for users who expected specific content. Redirect only to genuinely relevant destinations. If there isn’t one, a plain 404 is the better, cleaner outcome. A tidy handful of honest 404s beats a hundred misleading redirects.

404s After a Migration or Slug Change

Migrations and slug changes are where 404s appear in bulk, and they’re worth their own checklist because the failure modes are predictable.

Permalink structure changed during migration. If the old site used /%postname%/ and the new one uses /blog/%postname%/, every old URL now 404s. Match the new permalink structure to the old one where possible; if you must change it, map old patterns to new ones with redirects. Pattern-based (regex) redirects handle this far more efficiently than editing thousands of URLs one at a time.

Domain or HTTPS change. Moving from http:// to https://, or from www to non-www, should always be backed by a site-wide 301 redirect to the canonical version. Missing this is a classic source of mass 404s and duplicate URLs after a move.

Slug edits on individual posts. Every time you change a published post’s slug, the old URL dies. WordPress SEO plugins like Yoast and Rank Math can auto-create a redirect when a slug changes — enable that feature so single-post edits don’t silently create 404s.

Re-submit and monitor. After a migration, submit an updated sitemap so Google re-discovers your live URLs quickly — see our guide to XML sitemaps in WordPress. Then watch the Search Console Pages report over the following weeks and clean up 404s as they surface. Migrations also tend to spawn duplicate URLs; if you see the same content on multiple addresses, our guide on how to fix duplicate content in WordPress walks through canonical tags and redirects.

Building a Custom 404 Page That Actually Helps

No matter how diligent you are, some visitors will land on a 404 — from an old bookmark, a typo, or a link you can’t control. A good custom 404 page turns that dead end into a way forward. Most quality WordPress themes ship with a 404.php template; you can style it or replace it to include:

• A clear, friendly message that the page wasn’t found — no cryptic error codes shouting at the visitor.
• A prominent search box so people can look for what they wanted.
• Links to your most popular posts, main categories, or key pages.
• A link back to the homepage and your main navigation.

Crucially, a custom 404 page must still return an actual 404 HTTP status code. Designing a pretty “page not found” screen that returns 200 OK recreates the soft-404 problem. The page can look welcoming and route users somewhere useful while still being honest with crawlers about what happened.

Wrapping Up

Fixing 404 errors in WordPress splits cleanly into two jobs. When the whole site or every post 404s, it’s structural — flush your permalinks first, then check .htaccess (or the Nginx config) and confirm URL rewriting is active. When individual URLs 404, it’s an editorial call: redirect with a 301 to a relevant page when a real successor exists, restore content that still has value, and leave a clean 404 when the page is genuinely gone. Resist the urge to funnel everything to the homepage — Google reads that as a soft 404 and users read it as a dead end.

Treat 404 monitoring as ongoing maintenance, not a one-time cleanup. Watch the Search Console Pages report, run a crawler now and then, and act on each 404 deliberately. Do that and your dead links stay few, your link equity stays intact, and the rare visitor who does hit a 404 gets a helpful nudge instead of a wall.

FAQ

Why do all my WordPress posts suddenly show 404 errors?

This is almost always a broken permalink structure rather than missing content, since your homepage still loads. Go to Settings → Permalinks and click Save Changes to regenerate the rewrite rules. If that doesn’t fix it, check that your .htaccess file (on Apache) contains the standard WordPress rewrite block and that mod_rewrite is enabled on your server.

Should I redirect every 404 error to my homepage?

No. Redirecting an old URL to an irrelevant page like the homepage is treated by Google as a soft 404, so you gain none of the SEO benefit and you frustrate users who expected specific content. Only 301-redirect to a genuinely relevant successor page. If no relevant destination exists, let the URL return a clean 404 instead.

What is a soft 404 and why does it hurt SEO?

A soft 404 is a page that returns a 200 OK status but shows little or no real content — an empty archive, a thin page, or a redirect to an unrelated URL. The status code contradicts what the visitor actually sees, so Google flags it, wastes crawl budget on it, and may exclude it. Fix soft 404s by returning an honest status code or adding substantive content.

How do I stop getting 404 errors after a site migration?

Match your new permalink structure to the old one where possible, and add 301 redirects for any URL patterns that changed, including http-to-https and www-to-non-www moves. Submit an updated XML sitemap so Google re-crawls your live URLs, then monitor the Search Console Pages report for weeks afterward and clean up 404s as they appear.

Is it bad to have any 404 pages on my site?

Not at all. Returning a 404 for a page that genuinely no longer exists is correct and expected behavior — it tells search engines to drop the URL from their index. The problem is only when URLs that earned traffic, links, or rankings start 404ing without a redirect, or when 404s pile up from broken internal links. A small number of honest 404s is healthy.