How to Fix 404 Errors in WordPress

What a 404 Error Is

A 404 error is the message a web server returns when someone asks for a page that the server cannot find. To fix 404 error WordPress problems well, it helps to understand what the number actually means. The 404 is an HTTP status code, part of the quiet conversation that happens between a browser and a server every time a page loads. When the server can answer, it sends a 200 code, which means the request succeeded. When the address points at nothing, it sends 404, which is short for "Not Found".

The important word there is "found". A 404 does not mean the server is broken, and it does not mean your whole site is down. It means one specific address did not match anything the server could deliver. The homepage can work perfectly while a single old blog post returns a 404. That is why 404 errors often feel random. A visitor lands on one page without trouble and hits a wall on the next.

WordPress sits on top of this system and adds its own layer. Most WordPress addresses are not real files on disk. When you visit a post at /blog/my-article, there is no folder called blog with a file called my-article inside it. Instead WordPress reads the address, works out which post you wanted, and builds the page on the fly. This is called pretty permalinks, and it depends on rewrite rules that tell the server to hand these requests to WordPress rather than looking for a matching file. When those rewrite rules break, the server stops handing requests to WordPress and starts returning 404 for content that still exists.

Soft 404s and real 404s

There is also a second kind of problem worth naming early. A real 404 returns the 404 status code. A soft 404 looks like a missing page to a human but returns a 200 success code to search engines, often because a plugin or theme shows a "nothing here" message on a page that technically loaded. Google treats soft 404s as a quality problem because it wastes crawl effort on empty pages. Throughout this guide, when we talk about fixing 404s we mean both returning the correct status code and, where the content should exist, making the real page load again.

Why the status code matters so much

It is tempting to think of the status code as a technical detail that only developers care about. In practice it shapes how search engines treat your site. A correct 404 tells a crawler that a page is gone so it can stop trying, which keeps your reports clean and your crawl budget focused on pages that matter. A 200 on a page with no real content sends the opposite signal and invites confusion. When you plan a fix, always ask two questions. First, should this page exist at all? Second, is the server returning the right code for the answer to that first question? Keeping those two ideas separate saves a lot of wasted effort, because the fix for a page that should exist is very different from the fix for a page that should not.

How to read a status code yourself

You do not need special software to check what a page returns. Your browser developer tools show the status code in the network tab when you reload a page. Open the tools, switch to the network tab, reload the address, and click the first request in the list. The status column shows 200 for a working page and 404 for a missing one. This quick check tells you whether you are looking at a genuine missing page or a soft 404 that only looks broken, and it takes a few seconds once you are used to it.

Getting comfortable with this habit pays off across every section that follows. Before you change a setting, note what the broken address returns. After you apply a fix, check the same address again and confirm the code changed to what you expected. That before and after loop removes guesswork, keeps you from declaring a problem solved when a cache is simply hiding it, and gives you a reliable way to prove to yourself that each step actually did something. Small as it is, that discipline is what separates a slow afternoon of trial and error from a calm ten minute repair.

Common Causes of 404 Errors

Almost every 404 on a WordPress site traces back to a short list of causes. Knowing them turns a frustrating guessing game into a quick process of elimination. Here are the ones you will meet most often. As you read, notice how many of them share a single root: the connection between an address and the content behind it has broken somewhere, whether in WordPress, in the server rules, or in the link that pointed at the page. Once you see 404s that way, the fix is usually a matter of finding which link in that chain snapped.

Permalink settings

This is the most common cause by a wide margin. WordPress stores your permalink structure in its settings, and it writes matching rewrite rules for the server. If those rules get out of step with the settings, perhaps after an update, a migration, or a change to the structure, individual posts and pages start returning 404 while the homepage keeps working. The good news is that this is also the fastest to fix, and we cover it in the next section.

A corrupted or missing .htaccess file

On Apache servers, the rewrite rules live in a file called .htaccess in the root of your site. Plugins, updates, and manual edits can damage this file or remove the WordPress block from it. When the block is gone or malformed, Apache no longer sends pretty permalinks to WordPress, and you get site wide 404s on posts and pages. Security plugins and caching plugins both write to this file, so conflicts here are common.

Moved or deleted content

Sometimes the 404 is honest. The page really is gone. Someone deleted a post, changed a slug, unpublished a product, or reorganised the site and the old address no longer points anywhere. This is normal over the life of a site, but it hurts when the old address still has links pointing at it from search results, other websites, or your own menus. The fix here is a redirect, which we cover later.

Plugin and theme conflicts

Many plugins register their own rewrite rules. Membership plugins, ecommerce plugins, custom post type plugins, and multilingual plugins all shape how addresses map to content. When two of them disagree, or when a plugin fails to register its rules after activation, you can see 404s on specific sections such as shop pages, member areas, or a custom archive. A theme can cause the same trouble when it registers custom post types or taxonomies.

Server configuration

If the server does not have the right modules or directives enabled, pretty permalinks cannot work. On Apache this usually means mod_rewrite is disabled or the server is set to ignore .htaccess files with the AllowOverride directive. On Nginx there is no .htaccess at all, so the rewrite logic has to live in the server configuration. A missing try_files line is the classic Nginx cause of WordPress 404s.

Case sensitivity

Most web servers treat addresses as case sensitive. A link to /About-Us is not the same as /about-us. If a link, a menu item, or an old bookmark uses different capitalisation from the real slug, the server returns a 404. This bites people who move from Windows, where file names ignore case, to a Linux server, where they do not.

Migration issues

Moving a site to a new host or a new domain is a frequent source of 404s. The database can still hold old addresses, the permalink rules may not carry over, the .htaccess file might be left behind, and internal links can point at the old structure. A migration that looks complete on the homepage can hide dozens of broken deep links until you test them.

The Fastest Fix: Resave Permalinks

Before you edit any files or install anything, try this. Resaving your permalink settings forces WordPress to rewrite its rewrite rules and, on Apache, to refresh the WordPress block in .htaccess. It fixes a large share of 404 problems in under a minute, and it cannot hurt your content because it does not touch your posts or pages. This is the first thing to try whenever posts return 404 but the homepage loads.

Step by step

1. Log in to your WordPress dashboard as an administrator.
2. In the left menu, go to Settings, then Permalinks.
3. Do not change any option. Look at which structure is selected, usually Post name for most sites.
4. Scroll to the bottom and click Save Changes.
5. That single save rewrites the rules. Now open one of the pages that was returning a 404 in a new tab and reload it.

If the page loads, you are done, and the cause was stale rewrite rules. If it still returns a 404, the .htaccess file may not be writable, which stops WordPress from updating it automatically. In that case, move on to regenerating the file by hand, which is the next section. Either way, you have ruled out the single most common cause in about a minute, and that is worth doing before anything more involved.

One note for people running a cache. A page cache or a content delivery network can serve an old copy of a page even after you fix the underlying problem. If a page still looks broken after you resave permalinks, clear your caching plugin and any content delivery network cache, then test again in a private browser window so nothing local gets in the way.

Why this works

It helps to know what that single click actually does. When you save the permalinks screen, WordPress regenerates the internal set of rewrite rules it uses to translate a pretty address into the right piece of content. On an Apache server with a writable configuration file, it also refreshes the block of rules the server reads on every request. Many 404 problems are simply a mismatch between what WordPress thinks the rules are and what the server is actually using. Saving the screen brings the two back into agreement. Because it only rewrites rules and never touches your posts, pages, images, or settings, it is completely safe to try as often as you like, which is why it belongs at the very top of any troubleshooting routine.

Regenerating the .htaccess File

On Apache, the .htaccess file in your site root holds the rewrite rules that make pretty permalinks work. If resaving permalinks did not help, this file is the next suspect. It may be missing, it may not be writable, or it may have been damaged by a plugin. Regenerating it puts the correct rules back in place.

Find and back up the file first

Connect to your site with an FTP client or your host file manager. Look in the root folder, the same place that holds wp-config.php and the wp-content folder. The file is named .htaccess with a leading dot, which some tools hide by default, so enable "show hidden files" if you do not see it. Before you touch anything, download a copy so you can restore it if needed.

The standard WordPress rules

Open the file and look for the block that WordPress manages, marked by comment lines. If it is missing or garbled, replace it with the standard block below. These are the default rules WordPress writes for a single site install. Keep any other rules from plugins or your host outside of this block, above the BEGIN line or below the END line.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Read that block from the top. RewriteEngine On turns on the rewrite module. RewriteBase and the index.php rule set the starting point. The two RewriteCond lines are the heart of it. They say that if the requested address is not a real file and not a real directory, then the last rule sends the request to index.php, which hands control to WordPress. That is exactly the behaviour pretty permalinks need. If this block is correct and posts still 404, the problem is usually that Apache is told to ignore .htaccess, which is a server setting called AllowOverride that your host controls.

Make the file writable

If you want WordPress to manage this file for you again, set its permissions so the web server can write to it, commonly 644, and confirm the owner is correct for your host. Once it is writable, go back and resave permalinks one more time so WordPress can keep the block current on its own. On a healthy Apache setup, that combination clears the vast majority of site wide 404s.

The Nginx Equivalent

Nginx does not read .htaccess files at all. If your site runs on Nginx, which is common on managed and high traffic hosting, the rewrite logic lives in the server configuration instead. When WordPress permalinks 404 on Nginx, it is almost always because the configuration is missing the try_files directive that routes unknown addresses to index.php.

The block below shows the essential part. The location / section tells Nginx to first try the exact file, then the directory, and if neither exists, to pass the request to index.php with the original query string. That last step is what lets WordPress take over and build the page, exactly like the .htaccess rules do on Apache.

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com;
    index index.php index.html;

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

After editing an Nginx configuration you must reload the service for the change to take effect, using a command such as sudo systemctl reload nginx, and you should test the configuration first with sudo nginx -t so a typo does not take the site offline. Because Nginx configuration usually needs server level access, people on managed hosting often ask their host to add the try_files line rather than editing it directly. If your host manages the stack for you and permalinks are broken at the server level, our team can review the setup for you. You can get a free quote and we will take a look.

Setting Up 301 Redirects

Some 404s are not bugs. The page genuinely moved or was removed, and the old address still gets traffic from search results, links on other sites, or your own old content. The right answer is a redirect that sends both people and search engines from the old address to the best current page. A redirect keeps visitors from hitting a dead end and preserves much of the ranking value the old page had earned.

Which redirect type to use

The status code you choose matters. Use the wrong one and you either confuse search engines or keep a dead page alive in their index. Here is the short version.

For most moved content, a 301 is what you want. Reserve 302 for genuinely temporary situations, and use 410 when you have deliberately retired a page and want it gone from search. Pointing every old address at the homepage is a common mistake. Search engines can treat a redirect to an unrelated homepage as a soft 404, so send each old address to the closest matching live page instead.

Using the Redirection plugin

The free Redirection plugin is the most popular way to manage redirects in WordPress without touching server files. It also logs 404s as they happen, which makes it a discovery tool as well as a fix. Here is how to add a redirect with it.

1. Install and activate the Redirection plugin from Plugins, then Add New.
2. Go to Tools, then Redirection, and complete the short setup wizard the first time.
3. In the Add new redirection box, enter the old address in the Source URL field, for example /old-page.
4. Enter the new address in the Target URL field, for example /new-page.
5. Leave the type set to 301 moved permanently for a permanent move, then click Add Redirect.
6. Test the old address in a private browser window. It should land on the new page with the address updating in the bar.

The plugin approach is friendly, reversible, and does not require server access, which is why it suits most site owners. For a handful of redirects on Apache you can also add them manually to .htaccess with a Redirect 301 line, and on Nginx with a return 301 directive, but a plugin is easier to manage and audit once you have more than a few.

Manual redirects and when to use them

Server level redirects run before WordPress even loads, so they are slightly faster than plugin redirects and they keep working even if WordPress is unavailable. On Apache you place a Redirect 301 line inside your .htaccess file, giving the old path and the full new address. On Nginx you use a location block with a return 301 directive. The trade off is that these edits require file access and a careful hand, since a mistake in a server file can affect the whole site. For a small number of long lived redirects, such as a domain change, the server level route is a good fit. For the day to day work of retiring and moving individual posts, the Redirection plugin keeps everything in one place with a log and an undo, which most teams prefer.

Redirect chains and loops to avoid

Two mistakes are worth calling out. A redirect chain happens when address A points to B, and B points to C, forcing visitors and crawlers through several hops. Each hop slows the page and dilutes ranking value, so always point the old address straight at the final destination. A redirect loop is worse. It happens when A points to B and B points back to A, which traps the browser and shows an error. When you add a redirect, always test the old address afterwards and confirm it lands on the intended page in a single step.

Redirects also protect the search value you have built, which is why they sit close to the heart of good technical SEO. If you want the wider picture of how redirects, structure, and content fit together, our complete WordPress SEO guide walks through it. When redirects are part of a larger cleanup, it can be worth having a developer map old addresses to new ones in one pass, and you can request a free quote for that work.

How to Find 404 Errors

You cannot fix what you cannot see. Big sites often carry broken links for months because no one is looking. These are the practical ways to surface every 404 on your site so you can deal with them on purpose rather than one angry email at a time.

Google Search Console

Search Console is free and shows you the addresses Google tried to crawl and could not load. Open the Pages report under Indexing and look for the Not found (404) group. This tells you which missing pages Google knows about, which is exactly the set that affects your search presence. Export the list, decide for each address whether it should redirect to a live page or be allowed to return a clean 404, and work through it. Search Console also flags soft 404s in the same report, so you catch both problems in one place.

Server logs

Your web server records every request, including the ones that returned 404. Access logs are the most complete source because they capture real traffic, not just what a crawler found. Most hosts expose raw logs or a log viewer in the control panel. Filter for the 404 status code and you will see which missing addresses people and bots actually hit, along with how often. Frequency matters, because a 404 that gets thousands of visits deserves attention before one that gets two.

Crawl tools

A crawler walks your site the way a search engine does, following links and reporting which ones lead to 404s. Desktop crawlers and online tools both do this. The value here is that they find internal broken links, the ones inside your own menus, posts, and buttons, which you can fix at the source rather than papering over with a redirect. The Redirection plugin mentioned earlier adds a fourth angle by logging 404s live as visitors trigger them, which catches addresses that no crawler and no report predicted.

Bring the sources together

Each method sees a different slice. Search Console shows what affects search, logs show real traffic, crawlers show internal link rot, and a live logger shows current misses. Using two or three together gives you a full picture. A slow site can make crawling and log analysis harder to interpret because timeouts can look like errors, so if pages are sluggish it is worth reading our guide on how to speed up a WordPress website alongside this cleanup.

Designing a Custom 404 Page

Some 404s will always exist. People mistype addresses, follow old links, and reach pages you retired on purpose. A thoughtful 404 page turns that dead end into a helpful moment instead of a bounce. It cannot replace fixing broken links, but it softens the ones you cannot prevent.

What a good 404 page includes

• A clear message in plain language that the page was not found, without blaming the visitor.
• A search box so the person can look for what they wanted right there.
• Links to popular pages or main sections, so there is an obvious next step.
• Your normal header and footer so the visitor still feels on your site and can navigate.
• A calm, on brand tone that matches the rest of your site rather than a stark error screen.

How WordPress serves it

WordPress uses a template file named 404.php in your theme to render the not found page. Most quality themes include one, and many themes and page builders let you design it visually without code. If your theme has no 404 template, WordPress falls back to a basic one. The key technical point is that a custom 404 page must still return the real 404 status code. A pretty page that returns a 200 code becomes a soft 404 and creates the search problem we described at the start, so design the page freely but leave the status code alone.

Keep the page light. A 404 page loads at a moment when someone is already a little lost, so it should appear quickly and point them somewhere useful. If you build custom landing experiences on your site, the same care applies, and our guide on how to create a landing page in WordPress covers the layout thinking that also suits a strong 404 page.

Turn the 404 page into a small recovery tool

A good 404 page does more than apologise. Think about why people arrive there and give them a fast route forward. If a shopper hits a removed product, links to the matching category help far more than a generic message. If a reader follows an old link to a renamed guide, a prominent search box and a short list of popular articles rescue the visit. You can even track which addresses send people to the 404 page and use that list to add redirects for the common ones, which slowly shrinks how often the page is needed at all. Treated this way, the 404 page becomes a quiet part of your analytics rather than just a polite dead end.

Preventing Future 404s

Fixing today's 404s is only half the job. A little discipline keeps them from coming back. These habits cost almost nothing and save hours later.

Redirect whenever you change a slug

The single biggest source of avoidable 404s is changing a post or page slug without adding a redirect. If you must rename an address, add a 301 from the old slug to the new one at the same time. Some SEO plugins offer to do this automatically when you edit a published post, which is worth turning on.

Keep links relative and consistent

Use consistent capitalisation and a single preferred version of your domain, with or without www, and redirect the other. Mixed capitalisation and mixed domains create 404s and duplicate addresses that are easy to avoid with one rule applied everywhere.

Check links before you delete content

Before removing a page, look at whether anything links to it and whether it gets traffic. If it does, plan a redirect to the nearest live page rather than letting it fall into a 404. A quick check in Search Console or your logs answers this in a minute.

Test after every big change

Updates, migrations, and theme switches are the moments 404s appear. Build a short habit of spot checking key pages and running a crawl after any major change. Catching a broken section the day it breaks is far easier than finding it in a search report weeks later.

Keep a simple redirect map

As your site grows, a plain record of every address you have retired or moved, and where it now points, saves real time. It stops you from creating chains, makes migrations far smoother, and gives whoever works on the site next a clear picture of past changes. A spreadsheet is enough. The point is that redirects are a living part of a healthy site, not a one time task, and a small record keeps them under control.

Watch your reports

Make a monthly habit of opening the Not found report in Search Console and the 404 log in your redirect plugin. A short review each month keeps the list small and stops broken links from piling up into a big cleanup. If you would rather hand this maintenance to someone, our WordPress services include ongoing care that covers exactly this kind of upkeep.

Troubleshooting Checklist

When a 404 lands on your desk, work through these steps in order. Each one rules out a cause, and most sites are fixed before they reach the bottom.

1. Confirm the scope. Is it one page, one section, or the whole site? One page usually means moved content. A whole section suggests a plugin. Site wide points at permalinks or .htaccess.
2. Resave permalinks. Go to Settings, then Permalinks, and click Save Changes. Retest the broken page. This alone fixes a large share of cases.
3. Clear caches. Empty your caching plugin and any content delivery network, then retest in a private window so old copies do not mislead you.
4. Check .htaccess or Nginx. On Apache, confirm the standard WordPress block is present and correct. On Nginx, confirm the try_files line routes to index.php.
5. Test for plugin conflicts. Deactivate plugins, ideally on a staging copy, then reactivate them one at a time to find the culprit. Resave permalinks after reactivating anything that registers custom addresses.
6. Switch to a default theme. Temporarily activate a default theme to rule out theme registered post types or taxonomies as the cause.
7. Check the address itself. Look for wrong capitalisation, a trailing slash mismatch, or a slug that changed. Match the real slug or add a redirect.
8. Decide redirect or clean 404. If the content moved, add a 301 to the best live page. If it is gone for good, allow a clean 404 or use a 410.
9. Verify server settings. On Apache, confirm mod_rewrite is enabled and AllowOverride permits .htaccess. This is often a host level check.
10. Recheck your reports. After fixing, watch Search Console and your logs to confirm the 404s clear and no new ones appear.

Most WordPress 404 errors come down to permalinks, .htaccess or Nginx rules, a plugin conflict, or content that moved. Work the list from the top and you will resolve nearly all of them without guesswork. If your case turns out to be a stubborn server level issue, a messy migration, or a pile of broken links that needs a proper redirect map, that is exactly the kind of work our team handles every week. Building the site the right way from the start also prevents most of these problems, which our guide on how to make a WordPress website covers in full. When you want a hand, get a free quote and we will get your pages loading again.