Every post on the site suddenly returns “page not found,” but the homepage loads fine. That specific pattern has a specific cause, and knowing how to fix a 404 error in WordPress usually comes down to rewrite rules rather than missing content.

Most cases resolve in under a minute. The rest need a look at .htaccess, the Nginx config, or a plugin that registered a custom post type without flushing.

This guide covers the full sequence:

  • Finding every broken URL with Search Console and Screaming Frog
  • Resetting permalinks and repairing corrupted rewrite rules
  • Fixing migration 404s, plugin conflicts, and server-level breaks
  • Mapping 301 redirects and verifying the fix actually held

What Is a 404 Error in WordPress

A 404 error in WordPress is an HTTP status code the server returns when a requested URL matches no post, page, or file. WordPress catches the miss, loads 404.php from the active theme, and sends the 404 header back to the browser before any content renders.

The status code lives in the response header. Not in the words printed on the screen.

That distinction matters more than most people expect, because a page can say “Page Not Found” in 72px type and still report a perfectly healthy 200 OK to Googlebot.

Link decay is the background cause of most of them. Pew Research Center found in 2024 that 38% of webpages that existed in 2013 were gone a decade later, and 8% of pages from 2023 disappeared within a single year.

Ahrefs put a bigger number on it. Across 2,062,173 sampled domains, 66.5% of inbound links since January 2013 had rotted, with 74.5% classified as lost once temporary errors and other issues were counted.

404 vs 410 vs Soft 404

Three response codes, three different messages to a crawler.

Have you seen the latest WordPress statistics?

Discover the latest WordPress statistics: market share, security trends, performance data, and revenue insights that shape the web.

Check Them Out →
CodeWhat it tells GooglebotWhen to use it
404 Not FoundMissing, may return laterDeleted posts, typo URLs, moved slugs
410 GonePermanently removedRetired products, expired campaign pages
Soft 404Says missing, returns 200 OKNever on purpose (this is a bug)

John Mueller stated on Reddit in March 2026 that 404s and 410s are not a negative quality signal, and that repeated crawling of dead URLs causes no problem.

Soft 404s are the real headache. Google has to evaluate the URL, discard it, then come back and do it again, which burns crawl budget on nothing.

How WordPress Generates the 404 Template

Template hierarchy:

  • WordPress runs its query, finds zero matching posts, and sets is404() to true
  • The theme’s 404.php file loads; if the file is absent, index.php handles the request
  • Block themes use a 404 template part inside the templates folder instead of 404.php

Both paths end the same way. A proper 404 header goes out with the HTML, which is what separates a real error page from a decorative one.

Checking the Response Code

Open Chrome DevTools, switch to the Network tab, reload, and read the status column against the document request.

Terminal users get there faster with curl -I https://example.com/missing-page, which prints the raw status line and nothing else.

What Causes 404 Errors in WordPress

WordPress 404 errors come from 3 layers: the server, the WordPress rewrite system, and the content itself. Corrupted .htaccess rules break every pretty URL at once. Rewrite rules that never flushed break one post type. Deleted posts and edited slugs break individual URLs.

Working out which layer is broken saves an hour of guessing.

Quick diagnostic: if the homepage loads but every inner URL fails, the problem sits at the server or rewrite level. If one post fails and the rest are fine, the problem is content.

Server-Level Causes

  • Corrupted, overwritten, or missing .htaccess file on Apache
  • modrewrite disabled after a host migration or PHP version change
  • Missing tryfiles directive in the Nginx server block
  • Case-sensitive file systems treating /About-Us and /about-us as separate URLs
  • File permissions blocking WordPress from writing rewrite rules back to disk

Apache still runs a big slice of the WordPress install base, but Nginx passed it some time ago. W3Techs put Nginx at 33.3% of the web server market in January 2026, ahead of Cloudflare Server at 25.8% and Apache at 24.4%.

WordPress-Level Causes

Permalink structure changed: switching from plain to post name in Settings without the rewrite rules regenerating.

Custom post type registered without a flush: the post exists in the database, the URL has no route to it.

Mismatched siteurl and home values: wpoptions still points at the old domain or the http version after an SSL install.

Category base edits: people strip the category slug out of their URLs and forget that every old archive link now dead-ends.

Custom taxonomies are the sneaky one. A plugin registers rewrite => array('slug' => 'guides') on activation, skips flushrewriterules(), and nobody notices until a client emails about a broken menu item three weeks later.

Content-Level Causes

Deleted posts, trashed pages, and slugs edited after publication account for the slow drip of 404s that show up in Search Console months apart.

WordPress creates an automatic redirect when you change a post or page slug. Custom post types do not always get that treatment, which is why WooCommerce product URL edits break so quietly.

Pew’s 2024 analysis found 23% of news webpages carry at least one broken link, and 54% of Wikipedia articles contain a dead reference. Editorial sites accumulate this faster than anyone plans for.

A page not found message on a live URL almost always traces back to one of these three layers, and rarely to anything more exotic.

How to Find Every 404 Error on a WordPress Site

Finding every 404 takes 3 data sources: a crawler for internal links, Search Console for what Googlebot hit, and a live logger for what real visitors hit. No single tool catches all three. Crawlers miss orphaned URLs, Search Console misses recent breaks, loggers miss unlinked pages.

ToolWhat it catchesFree limit
Screaming Frog SEO SpiderInternal 4xx links, redirect chains500 URLs per crawl
Google Search ConsoleURLs Googlebot found missingUnlimited, 28-day validation
Ahrefs Site AuditDead URLs holding backlinks5,000 credits monthly
Redirection pluginLive 404 hits with referrerFree, no cap

In Search Console, the report you want is Indexing, then Pages, then Not found (404). Export the CSV before you start fixing anything.

Screaming Frog’s Response Codes tab with the Client Error (4xx) filter gives you the internal picture, plus every source URL that links to the broken target. That second column is the one that saves time.

Redirection by John Godley sits at over 2 million active installations and logs every 404 a real visitor triggers, along with the referrer, so you know whether the bad link lives on your site or someone else’s.

Server logs catch what none of them do. Bot probes, hotlinked images, old feed URLs. cPanel exposes raw access logs under Metrics, and enabling the WordPress debug log adds the PHP side of the picture.

Prioritize by value, not by count. A 404 with 40 referring domains and 900 monthly impressions outranks 300 parameter URLs nobody ever visited.

Semrush’s large-scale site audit research has consistently found 4xx errors on roughly a third of the sites analyzed, so the list is usually longer than expected on the first pass. Cleaning it up overlaps heavily with the broader job of repairing dead links across a WordPress install.

How to Fix WordPress 404 Errors by Resetting Permalinks

Resetting permalinks fixes most WordPress 404 errors in under 10 seconds. Go to Settings, then Permalinks, then click Save Changes without altering a single setting. WordPress calls flushrewriterules(), rebuilds the rewrite array in wpoptions, and rewrites the block in .htaccess.

That is the whole fix. Save Changes is doing real work even though nothing on the page appears to change.

What the flush actually does:

  • Regenerates the rewrite rules array stored in the wpoptions table
  • Rewrites the WordPress block between the BEGIN and END markers in .htaccess
  • Re-registers rules for custom post types and taxonomies added by plugins

WP-CLI does the same job from the command line with wp rewrite flush --hard. The hard flag forces the .htaccess rewrite, which the soft flush skips.

When the flush fails silently, permissions are the usual suspect. WordPress cannot write to .htaccess if the file sits at 444, and the admin screen gives no warning about it.

Verify with a hard reload and a look at the Network tab. A 200 on the previously broken URL means the rewrite rules took. Still 404? Move to the .htaccess repair below.

One related job people combine with this: stripping index.php out of WordPress URLs, which depends on the same rewrite rules and breaks in the same way when modrewrite is off. If pretty permalinks refuse to stick at all, the underlying issue is usually the same one behind permalinks that stop working after a host change.

How to Repair a Corrupted .htaccess File

Repairing .htaccess means replacing the WordPress rewrite block with the default rules and setting permissions to 644. Locate the file in the WordPress root over SFTP or File Manager, rename the old copy, paste the default block, then reload an affected URL to confirm a 200 response.

Rename. Never delete. Plugins, security tools, and caching layers write their own directives into that file, and losing them creates a second problem while you fix the first.

The file is hidden by default, so enable “show hidden files” in File Manager or press Ctrl+H in FileZilla before you go looking for it.

The Default WordPress .htaccess Block

Everything between the two markers gets managed by WordPress. Directives outside the markers stay untouched during a permalink flush.

BEGIN WordPress

<IfModule modrewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index.php$ – [L] RewriteCond %{REQUESTFILENAME} !-f RewriteCond %{REQUESTFILENAME} !-d RewriteRule . /index.php [L] </IfModule>

END WordPress

`

Set the file to 644 and hand ownership to the web server user. Anything looser gets flagged by security scanners, anything tighter blocks the flush.

Get the syntax wrong and Apache stops serving the site entirely. A stray character in this file is one of the more common triggers behind a 500 response replacing your whole site, so keep the renamed backup until the fix is confirmed.

Broader permission problems across wp-content and uploads follow the same 644 files, 755 directories pattern covered in correcting WordPress file permissions.

Multisite .htaccess Rules

Multisite installs use a different block, and the subdirectory version differs from the subdomain version.

Subdirectory networks need the extra RewriteRule lines that strip the site path from wp-admin, wp-includes, and wp-content requests.

Subdomain networks use a shorter block closer to the single-site default.

Copying the single-site rules into a subdirectory network produces 404s on every subsite dashboard. Grab the correct block from the Network Setup screen, which prints the exact rules for your configuration.

How to Fix 404 Errors on Nginx Servers

Nginx ignores .htaccess completely. Fixing 404 errors there means adding a tryfiles directive to the server block, testing the config with nginx -t, then reloading the service. Permalink flushes alone leave every pretty URL broken.

This is the step most WordPress 404 tutorials skip, and it wastes a lot of people’s evenings.

The directive itself is one line:

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

The file usually sits at /etc/nginx/sites-available/yourdomain.conf or inside /etc/nginx/conf.d/, depending on how the stack was built.

Apply the change:

  • Run nginx -t to validate syntax before touching anything live
  • Reload with systemctl reload nginx (reload, not restart, keeps connections alive)
  • Flush permalinks in WordPress afterward so the rewrite array matches

Managed hosts handle this at the platform level. Kinsta, Cloudways, and RunCloud all run Nginx with WordPress rules baked in, so the fix belongs in the host dashboard or a support ticket rather than a config file you cannot reach.

LiteSpeed sits in between. It reads .htaccess like Apache does, which trips people up when they assume a LiteSpeed host behaves like Nginx.

How to Fix 404 Errors Caused by Plugin and Theme Conflicts

Plugin and theme conflicts cause 404 errors when a custom post type or taxonomy registers without flushing rewrite rules. Deactivate every plugin, test the broken URL, then reactivate one at a time until the 404 returns. The last plugin activated is the culprit.

Do this on staging. Deactivating 20 plugins on a live store during business hours is a decision you only make once.

SuspectWhat breaksUsual fix
WooCommerceProduct and endpoint URLsResave permalinks after any endpoint change
Membership pluginsGated content routesCheck access rules before blaming rewrites
LMS pluginsLesson and topic URLsFlush after course structure edits
Custom post type buildersEntire post type archiveRe-register the slug, then flush

WooCommerce alone runs on a large share of WordPress e-commerce sites, and its endpoint URLs (order-received, edit-account, and the rest) sit on top of the same rewrite system, which is why product 404s so often follow a checkout plugin update.

Rule out the theme next. Switch to Twenty Twenty-Four, reload the URL, and see what happens.

Themes register rewrite rules too, usually inside functions.php, and a theme that adds a custom slug without a flush behaves exactly like a misbehaving plugin. Anyone comfortable working directly in the functions.php file can search for registerposttype and addrewriterule to confirm it in about a minute.

If the site breaks in other ways once the theme switches, you are looking at a theme-level fault rather than a routing problem, and the 404 is a symptom instead of the cause.

With more than 65,000 plugins in the WordPress.org directory, conflicts are a numbers game. Most sites run 20 to 30 of them, and every one that registers a post type is a candidate.

How to Fix 404 Errors After a Site Migration

Migration 404s come from database values that still point at the old domain. Correct siteurl and home in wpoptions, run a serialization-aware search and replace across the tables, purge every caching layer, then confirm modrewrite is active on the new server.

Migrations produce the ugliest 404 patterns because the breakage happens at four levels at once.

Where it breaksSymptomFix
wp_optionsRedirect loop or total 404Correct siteurl and home
Serialized post metaBroken builder layoutsWP-CLI search-replace
Caching layerOld routes served to visitorsPurge CDN and page cache
Server configEvery pretty URL returns 404Enable mod_rewrite or add try_files

Raw SQL REPLACE across the database is the mistake that costs people a weekend. WordPress stores theme settings, widget configs, and plugin options as serialized PHP with character counts baked in.

Change the string without recalculating the count and PHP silently discards the value. No error, no warning, just a site that looks wrong.

WP-CLI handles it properly:

` wp search-replace 'https://old.com' 'https://new.com' --precise --skip-columns=guid --dry-run `

Run the dry run first, read the replacement count, then run it again without the flag. The –skip-columns=guid part is not optional, since GUIDs work as permanent feed identifiers and rewriting them re-shows old posts in every RSS reader.

Page builders hide absolute URLs inside serialized JSON. Elementor is the usual offender, and a search and replace that misses its data leaves working pages with dead internal links.

Then there is HTTPS. Half-finished SSL installs leave siteurl on http, which produces both mixed content warnings and 404s on assets, and the underlying causes overlap heavily with other certificate and protocol failures in WordPress.

Search Engine Land documented a media company whose Brazilian site lost roughly 90% of sessions after a domain migration, with soft 404 errors as the root cause. Forecasting put the site on track for 20,000+ daily clicks against the 5,000 to 7,000 it was actually getting.

Semrush’s Farfetch case ran the other direction. Its Site Audit crawl flagged over 12,000 broken internal links post-migration, and traffic returned to pre-migration levels within six weeks of the fixes going live.

How to Redirect Broken URLs Instead of Deleting Them

Redirect a broken URL with a 301 pointing at the closest topical match. Blanket redirects to the homepage get reclassified as soft 404s and pass nothing. URLs with no backlinks, no impressions, and no traffic history stay as 404s.

The decision is simpler than most guides make it. Does the URL have inbound links or search impressions? Redirect it. Does it have neither? Leave it broken.

301 vs 302 vs 410

CodeSignalUse for
301Permanent moveMerged posts, changed slugs, migrations
302Temporary moveSeasonal pages, A/B tests, maintenance
410Permanently goneRetired products, deleted campaigns

Gary Illyes stated in 2016 that 30x redirects no longer lose PageRank, retiring the older 15% loss rule that Matt Cutts had described in 2013.

Chains still cost you. Old URL to intermediate URL to final URL dilutes the signal and slows the crawl, so map every source straight to its final destination.

Plugin Redirects vs Server Redirects

Plugin redirects fire after WordPress bootstraps, which means PHP, a database query, and a measurable delay on every hit. Fine for a content team managing 40 URLs by hand.

Server redirects in .htaccess, an Nginx map block, or Cloudflare Bulk Redirects fire before WordPress loads at all. Cheaper by an order of magnitude on high-volume URLs.

Rank Math’s redirection module and Yoast SEO Premium both auto-create a 301 when you edit a published slug, which stops the most common source of self-inflicted 404s at the point it happens.

My preference: plugin for editorial one-offs, server rules for anything getting real traffic. Mixing the two is fine as long as one system owns each URL.

How to Build a 404 Page That Keeps Visitors on the Site

A working 404 page returns a genuine 404 header and gives visitors a way forward. Site search, recent posts, top categories, and the main menu recover sessions that a bare error message loses. Edit 404.php in a child theme, or the 404 template part in a block theme.

Cludo’s research found a custom error page cuts bounce rate by roughly 12% compared with a default one.

AddSearch data puts around 45.87% of 404 arrivals as coming from emails, bookmarks, typos, and direct links rather than internal navigation. Those visitors already wanted something specific from you.

What earns its place on the template:

  • A search field wired to the WordPress search query
  • Your standard header and footer, unchanged
  • 3 to 5 popular posts or top-level categories
  • Plain language, no HTTP jargon

GitHub runs a parallax Star Wars illustration with a search bar sitting right in the middle of it. Slack keeps things quieter and links straight to the homepage, help centre, and status page, which covers the three reasons anyone lands there.

Keeping the site menu visible on the error page does more work than the artwork does, though the artwork is what people remember.

Adding a search field to the WordPress template is the single highest-value element, since a visitor who typed a URL usually knows the exact thing they wanted.

Watch the header. Page builders and some caching plugins serve a designed 404 template with a 200 status, which converts a clean error into a soft 404 that Google has to keep re-evaluating.

Track the hits in GA4 with a custom event fired from the 404 template, or through a trigger if you already run Google Tag Manager on the site. Referrer data tells you which broken link to chase.

The full template build, including block theme handling and conditional content, is covered in designing a custom WordPress 404 error page.

How to Verify a 404 Fix Actually Worked

Verify a 404 fix by reading the raw response header, not the rendered page. Run curl against the URL, confirm a 200 or 301 in the status line, clear every cache layer first, then recrawl the site and validate in Search Console.

Browser cache lies. So does Cloudflare, LiteSpeed Cache, WP Rocket, and every other layer between your fix and the visitor.

Order matters here. Purge caches, then test, or you spend an hour debugging a fix that already worked.

The verification sequence:

  • Purge page cache, object cache, and CDN cache
  • Run curl -I https://example.com/fixed-url and read the status line
  • Recrawl in Screaming Frog and confirm zero unexpected 4xx responses
  • Open URL Inspection in Search Console, then Request Indexing on priority pages
  • Click Validate Fix on the Not found (404) report

Validation is slow and partial. Google checks a representative sample rather than every URL, so the count in the report drains over weeks rather than dropping to zero the next morning.

John Mueller has pointed out that the Mark as Fixed action tracks reprocessing without accelerating it. Clicking it twice does nothing except make you feel busy.

One last check people skip: verify the redirect lands where you think. A 301 to a URL that itself 404s passes the header test and fails the actual job.

How to Prevent 404 Errors From Returning

Preventing 404 errors takes 3 habits: automatic redirects on slug changes, a scheduled crawl, and Search Console alerts. Sites that lock slugs before publishing and audit internal links after bulk deletions stop generating the errors that cleanup projects keep rediscovering.

TaskCadenceTool
Full site crawlMonthlyScreaming Frog or Ahrefs
Live 404 log reviewWeeklyRedirection or Rank Math
Search Console checkWeeklyPages report
Internal link auditAfter bulk editsCrawler export

Slug discipline beats every tool on that list. Decide the URL before you hit publish, because the cheapest 404 is the one that never existed.

Rank Math’s 404 Monitor writes a row for every hit, including bot probes, so the table grows fast on busy sites. Truncate it periodically or disable the module once you have the data you needed.

Permalink structure changes belong on staging. Testing them live is how a 40,000-URL site generates 40,000 errors in one click.

Bulk deletions leave a trail of dead internal links pointing at nothing. Re-crawl after any category restructure, and treat pages left with no internal links pointing to them as the same class of problem.

Fixing what the crawl finds means editing the source pages, and doing that properly overlaps with how internal links get added and maintained in WordPress.

Backups turn a broken .htaccess into a two-minute rollback. UpdraftPlus, Jetpack VaultPress, and host-level snapshots from Kinsta or SiteGround all do the job, provided somebody has actually tested a restore.

Agencies running this across a portfolio usually centralize the monitoring, which is a whole workflow of its own once you are looking after a stack of WordPress installs at once.

FAQ on How To Fix A 404 Error In WordPress

Why do all my WordPress posts return 404 errors?

Rewrite rules broke. Go to Settings, then Permalinks, then Save Changes without altering anything. WordPress regenerates the rewrite rules and rewrites the .htaccess block, which resolves the vast majority of site-wide 404 errors instantly.

Does resetting permalinks delete my content?

No. Saving the permalink settings only rebuilds the rewrite rules array in wpoptions and the .htaccess block. Posts, pages, media, and URLs stay exactly as they were before the flush ran.

Where is the .htaccess file in WordPress?

It sits in the WordPress root, alongside wp-config.php. The file is hidden by default, so enable “show hidden files” in cPanel File Manager or press Ctrl+H in FileZilla to see it.

Why does my page exist but still show a 404?

Usually a custom post type or taxonomy registered without a rewrite flush. Resave permalinks first. If that fails, deactivate plugins one at a time until the URL loads correctly again.

Do 404 errors hurt SEO rankings?

Not directly. John Mueller confirmed 404s and 410s are not a negative quality signal. The indirect cost comes from wasted crawl budget, lost link equity, and visitors who bounce immediately.

Should I redirect all 404s to the homepage?

No. Google reclassifies blanket homepage redirects as soft 404s, so nothing gets passed along. Redirect only URLs with backlinks or impressions, and point each one at its closest topical match.

Why do 404 errors persist on Nginx after fixing permalinks?

Nginx ignores .htaccess completely. Add tryfiles $uri $uri/ /index.php?$args; to the location block, test with nginx -t, then reload the service. Managed hosts handle this from the dashboard instead.

What causes 404 errors after moving a WordPress site?

Mismatched siteurl and home values in wpoptions, plus old absolute URLs buried in serialized post meta. Fix both with a WP-CLI search and replace, then purge every caching layer.

How do I find all broken URLs on my site?

Combine three sources: the Not found (404) report in Google Search Console, a Screaming Frog crawl filtered to 4xx responses, and a live logger like the Redirection plugin.

How long does Search Console take to clear 404 errors?

Weeks, not days. Validation runs against a representative sample rather than every URL, so the count drains gradually as Googlebot recrawls. Clicking Validate Fix repeatedly does not speed it up.

Conclusion

Knowing how to fix a 404 error in WordPress is mostly a matter of working the layers in order: rewrite rules, then the server config, then the content itself.

Read the response header before you touch anything. A page that looks broken and returns 200 is a different problem than one returning a clean 404.

Two habits keep the list from growing back:

  • Lock the slug before publishing, and let a redirect plugin catch the ones you change anyway
  • Crawl monthly, and treat dead URLs with backlinks as the priority

Leave the junk alone. Bot probes and scraper typos cost nothing, and chasing every entry in the log wastes hours better spent on the crawl budget your real pages need.