Which 404 errors are actually worth fixing?
Fewer than the report suggests. A 404 appears when the server can't find anything at the requested address, and a WordPress site that's been live for a few years collects them from everywhere: addresses a bot guessed, links somebody typed wrong, deleted posts, old feeds and attachment pages nobody opens. Fixing every row wastes a day, so I sort the list by value first, which is where crawlability and indexing fixes should start.
Google's help for the Page indexing report is blunt about it: 404 responses aren't necessarily a problem if the page was removed without any replacement. Its HTTP status documentation adds that 4xx codes, other than 429, have no effect on crawl rate. A 404 becomes a fault when something of value still points at it.
| Signal | Where I find it | Why it matters |
|---|---|---|
| Impressions or clicks | Search Console's Performance report, filtered by page | Google was showing that URL to searchers, so there's demand the site is now throwing away |
| Links from other sites | Search Console's Links report and a backlink export | People still follow those links, and every one of them lands on a dead end |
| Links from your own pages | A crawl of the live site | It's a broken path you control, and it can be fixed at the source |
A dead URL with none of the three can usually stay a 404. A URL with any of them gets its own decision, which is the rest of this post.
How do I fix 404 errors on WordPress pages that still exist?
Usually by rebuilding the rewrite rules, not by adding redirects. When posts and pages return 404 but the homepage works, the content's fine and WordPress has lost the rules that map its permalinks to it. I open Settings, then Permalinks, and click Save Changes without changing anything. WordPress's documentation says that if .htaccess is writeable you'll see "Permalink structure updated", and if it isn't, the screen shows the rewrite rules to paste in yourself. It also notes that just visiting the Permalinks screen flushes the rewrite rules.
If that doesn't clear it, I open .htaccess itself. On Apache the WordPress block sits between # BEGIN WordPress and # END WordPress, and WordPress's server docs print the default block in full so a file a plugin has damaged can be restored. The host also needs mod_rewrite, which is on WordPress's own list of what to ask a host for.
This is the one kind of 404 where a redirect is the wrong fix. The URLs are right, so redirecting them only hides a broken setup that'll break the next page you publish too.
Should I redirect a 404 to the homepage?
No. It's a popular shortcut, and it doesn't fix anything. Google's site move guidance says not to redirect many old URLs to one irrelevant destination, such as the home page, because it can confuse users and might be treated as a soft 404 error. That means the redirect keeps none of what the old page had and adds a hop on top. The visitor doesn't win either: someone who clicked a link about one product and lands on a homepage has to start again.
I've had to make this call on my own site. When I retired its old pages, they pointed at the homepage while their replacements were being written, and my redirects file records that they held 4,791 impressions between them. Each page that had a replacement was remapped to it as soon as the replacement existed.
The same logic saved a store. On one WooCommerce catalogue, a redesign that renamed URLs with no redirect map cut daily clicks from 162 to 49 in three days. In the recovery the old sapphire category pointed at the new sapphire category rather than the homepage, every other old URL got a 301 to its closest new page, and clicks were back at 362 a day.
Plugins that send every 404 to the homepage exist, and they make the Search Console list look clean. The list shrinks because the errors turn into redirects Google may read as soft 404s, not because anything got fixed.
Rather have me do this? One person, whole job.
Book a call on UpworkHow do I choose between a 301, a 410 and leaving the 404?
I ask these in order, and the first one that's true decides the URL.
- i.
The same page lives at a new address
A changed slug, a new permalink structure or a product that moved category. That's a 301 to the new URL, which Google says tells its indexing pipeline the target should be canonical.
- ii.
It was merged into another page
Two thin posts folded into one, or an old product replaced by its successor. The 301 goes to the page that absorbed it, but only if that page answers what the old one did.
- iii.
It's retired on purpose and nothing's close
An old event, a dropped service or a product line that's gone. I return a 410 when the removal is deliberate, or leave the 404. Google treats every 4xx except 429 the same, so the 410 is a note for whoever reads the logs later. Choosing what to remove is a pruning decision with its own rules.
- iv.
It never really existed
Bot probes for files the site never had, spam links with random strings on the end, a mangled query. These stay 404.
- v.
The broken link is on your own site
Fix the link first, then decide about the URL. A menu item or a post that still points at a dead address should point at the live one.
How do I fix a 404 error in WordPress with a 301?
To redirect a page in WordPress when there's only a handful of URLs, a plugin's the practical route. This is the order I work in.
- Step 01
Check whether WordPress already handles it
When a post's slug changes, WordPress remembers the old one, and its
wp_old_slug_redirectfunction sends a 301 to the current permalink. A second rule on top only adds a chance of a loop. - Step 02
Add the rule in a redirect manager
Most SEO plugins and every dedicated redirect plugin have one. The Redirection plugin is one example: it creates 301s and keeps a log of the 404s it sees. I enter the old path, the new URL and 301, nothing else.
- Step 03
Point at the final URL
If the target itself redirects, the new rule creates a chain. Google can follow up to 10 hops but advises redirecting straight to the final destination, so I update older rules too.
- Step 04
Update the links that still use the old URL
Menus, buttons and links inside posts should carry the new address. The redirect's the safety net for links you don't control.
- Step 05
Test the real response
I request the old URL with
curl -Iand look for a 301 with a Location header naming a page that answers 200. A plugin screen only shows what was saved, not what the server sends.
A platform move is where all of this happens at once, and I've written up how I build the redirect map when a Wix site moves to WordPress.
When is the server a better place for redirects than a plugin?
A plugin rule runs inside WordPress, so the request has to load PHP and WordPress before the redirect answers. For a few dozen rules that's fine, and the owner can see and edit them. A server rule in Apache or Nginx answers before WordPress starts.
| Situation | Where the rule goes | Why |
|---|---|---|
| A handful of changed posts or products | A redirect plugin | The owner can read and change it without server access |
| Hundreds of URLs that follow one pattern, like a changed permalink base | One pattern rule on the server | A single rule replaces hundreds of rows, and nothing waits on WordPress to load |
| Addresses WordPress never served, like old static files or another platform's paths | The server config | Those requests may not reach WordPress, so a plugin can't answer them reliably |
| Removals you want marked as gone | Apache's Redirect gone, or an Nginx return 410 | Both send a 410 directly, without building a page first |
Apache's Redirect directive takes permanent for a 301 and gone for a 410, and Nginx's return directive takes a status code plus a URL for the redirect codes. My own site keeps every redirect in one server-side file, with a comment above each block saying why it's there, because when nobody knows why a rule exists, nobody dares delete it.
What should a custom 404 page show?
A way back into the site, and an honest status code. MDN's advice is that custom 404 page design is a good thing in moderation: make it human if you like, but don't confuse visitors about why they're seeing it. I'd give it a plain line saying the page isn't here, a search box and links to the pages people most often want.
On a classic theme, WordPress looks for the theme's 404.php template and falls back to index.php, so that's the file to edit. Then I test it with a made-up URL. It has to answer 404, not 200, because a friendly not found page served with 200 is exactly what Google reports as a soft 404.
