A 404 in Search Console is not a penalty. It means Google requested a URL on your site and the server said the page does not exist. Google expects that for pages you deleted. The 404s worth fixing are the ones that had traffic or links, and the ones your own site still links to; for those, a 301 redirect to the right page is the fix. The rest you can leave.
Search Console reports three related statuses under Indexing → Pages. This guide covers what each means, where they come from on WordPress, and how to decide between a redirect, a restored page and a real 404.
Not found (404), soft 404 and page with redirect
| Search Console status | What happened | What to do |
|---|---|---|
| Not found (404) | Google requested the URL and got a 404 (Google treats a 410 the same) | Redirect it if it had traffic or links; otherwise leave it |
| Soft 404 | The server answered 200, but the page looks like an error or is nearly empty | Return a real 404, add content, or redirect |
| Page with redirect | The URL redirects, so only the destination can be indexed | Usually nothing; update sitemap and links that still use it |
Two related statuses come from the same place. Redirect error means Google could not follow the redirect: a loop, a chain that is too long, or a redirect to a bad URL. Server error (5xx) means the server failed; that is a hosting problem, not a missing page.
Where WordPress 404s come from
- Deleted or trashed posts. Trash a post and its URL starts returning 404.
- Changed slugs. WordPress redirects some changed post slugs on its own, but not deleted content, and not every case.
- A permalink structure change. Changing Settings → Permalinks moves every post URL at once.
- Removed media and attachment pages. Deleting an image removes its attachment URL too.
- An SEO plugin switch. Sitemap URLs differ between plugins (
/sitemap_index.xml,/wp-sitemap.xml), so Google keeps requesting the old one. - Links you do not control. Other sites link with typos; scrapers and spam generate URLs that never existed.
Decide: redirect, restore or leave
- Open Indexing → Pages → Not found (404) and export or scroll the example URLs.
- Check what each URL was worth. In Performance → Search results, filter by the page (Page → URL contains) over the last 16 months: did it get clicks? In Links, open Top linked pages under External links, export it and search the file for the URL; a page with links from other sites is worth a redirect even if it never got clicks. Ahrefs Webmaster Tools, free for sites you verify, can also list pages that return 404 but still have backlinks. Run the broken link checker on your own pages to see whether you still link to it.
- Pick one action per URL:
- It moved, or a newer page replaces it: 301 redirect to that page.
- It was deleted and nothing replaces it: leave the 404 (or return 410), and remove internal links and sitemap entries pointing at it. To send a 410, Rank Math’s Redirections screen has a 410 Content Deleted type, and the Redirection plugin can answer a matched URL with an error code instead of a redirect.
- It was deleted by mistake: restore it from the trash or a backup.
- It never existed: leave it.
Do not redirect everything to the homepage. Google can treat redirects to an unrelated page as soft 404s, and the visitor still does not get what they came for.
A worked example
Here is how that sorting plays out on an illustrative food blog that changed its permalinks from /%year%/%monthnum%/%postname%/ to /%postname%/ and deleted a few old posts in the same month:
| URL in the 404 report | Clicks, last 16 months | Linked from | Decision |
|---|---|---|---|
/2021/03/best-blenders/ | 1,240 | Two other sites, and your own sidebar | 301 to /best-blenders/ |
/2019/07/kale-smoothie/ | 85 | Nothing | 301 to /green-smoothies/, the post that replaced it |
/summer-giveaway-2022/ | 0 | Nothing | Leave as 404; remove it from the sitemap |
/tag/blendr/ | 0 | A typo on a forum | Leave as 404 |
/.env | 0 | Nothing | Leave; bots probe for leaked config files |
The first row is one of hundreds with the same pattern, so a single pattern rule handles all of them (see below) rather than hundreds of single redirects. The second gets a hand-written redirect because a newer post covers the same thing. The last three cost nothing to leave alone.
Add a 301 redirect in WordPress
- Rank Math: turn on the Redirections module (Rank Math SEO → Dashboard → Modules), then add the rule under Rank Math SEO → Redirections.
- Yoast SEO: redirects are a Yoast SEO Premium feature, under Yoast SEO → Redirects.
- Redirection plugin (free): Tools → Redirection → Add redirect, with the old path as the source and the new URL as the target.
- At the server: an
.htaccessrule on Apache, or your host’s redirect settings.
Point the redirect straight at the final URL. If the target itself redirects, you have built a chain; the redirect checker shows every hop and its status code.
Redirect a whole pattern after a permalink change
When every old URL has the same shape, one regular-expression rule beats hundreds of single redirects. In the Redirection plugin, add a rule, open the gear icon, tick Regex, and use:
Source URL: ^/\d{4}/\d{2}/([^/]+)/?$
Target URL: /$1/
That sends /2021/03/best-blenders/ to /best-blenders/. Rank Math’s Redirections screen accepts the same pattern if you set the source’s match type to Regex, and Yoast SEO Premium has a regex option too. Test three or four old URLs from the 404 report with the redirect checker before you trust the rule, and make sure it cannot catch current URLs: a pattern that is too broad redirects live pages.
On Apache, the same rule in .htaccess, placed above the # BEGIN WordPress block, is:
RedirectMatch 301 ^/\d{4}/\d{2}/([^/]+)/?$ /$1/
Check the status code yourself
curl -sI https://yourdomain.com/old-page/ prints the response headers. A fixed URL should answer 301 with a location: line pointing at the new page, and that page should answer 200. A deliberately removed page should answer 404 or 410, not 200.
Soft 404s on WordPress
A soft 404 is a page that answers 200 but looks like an error or has almost nothing on it. On WordPress the usual ones are:
Empty category or tag archives that still render a “Nothing found” template.
Internal search results (
/?s=…) that Google found through links.Themes that show a “not found” message without sending a 404 status.
Very thin pages: a page with a heading and nothing else.
Out-of-stock or discontinued products that show little more than “unavailable”.
Pages whose content loads only through JavaScript that fails for Google, leaving an empty shell.
Fix them by returning a real 404 for content that is gone, noindexing archive and search pages you do not want in search (your SEO plugin can do this for search results and empty archives), or adding the content the page was supposed to have. For a product that is out of stock for now, keep the page and its description and point to alternatives; for one that is gone for good, redirect to its replacement or return a 404. The indexability checker flags a page that answers 200 with an error-page title.
Your own 404 page should help the visitor (a search box and links to your main sections) and still return a 404 status. Many themes get this right; check yours with curl on a made-up URL.
Page with redirect
This status is Google confirming it followed your redirect. Leave it, with two exceptions:
- The redirecting URL is in your sitemap. A sitemap should list final URLs only. Most SEO plugins rebuild the sitemap from current URLs, so this usually means an old sitemap is still submitted, or a plugin is listing something it should not.
- Your own pages link to it. Update internal links to the destination so visitors and crawlers skip the hop.
Troubleshooting by symptom
The 404 count jumped overnight. Something changed URLs in bulk: a permalink change, a new SEO plugin with a different sitemap address, or a deactivated plugin or theme that registered a custom post type (portfolios, events and recipes often come from one). Find the shared pattern in the example URLs and fix it with one rule, or bring the post type back.
A page that works in your browser is reported as 404. Run URL Inspection → Test live URL. If the live test passes, the 404 was temporary, often a cache serving an old error or a deploy in progress. If it fails, look for a security plugin or firewall that answers bots differently, or a trailing-slash mismatch between the URL Google has and the one your site serves.
The report fills with URLs you never made. Paths such as /.env, /wp-config.php.bak or random strings come from bots probing for weaknesses. They do no harm as 404s. Do not redirect them.
Redirect error. Google gave up following the redirect. Googlebot follows up to 10 hops, so check for a loop or a long chain, often an http-to-https rule, a www rule and a plugin redirect stacked on top of each other. Collapse them so each old URL goes to its final destination in one hop.
Soft 404 on a page with real content. Test the live URL and open View tested page → Screenshot. If Google sees an empty page, a script or blocked resource is failing; if it sees the content, the page may still read like an error (“no products found”) and needs more substance.
Validation failed. At least one URL in the group still has the problem. That is expected when the group includes URLs you chose to leave as 404s.
Validate the fix in Search Console
Check a fixed URL with URL Inspection → Test live URL: a redirect should show as a redirect to the right page, a restored page as available. Then open the status in Indexing → Pages and click Validate fix. Search Console rechecks the listed URLs over the following days or weeks.
One caution: URLs you deliberately left as 404s will still fail validation, because they are still 404s. That is expected. Validation passing is not the goal; making sure the URLs that matter resolve is.
How RankHive handles this
On a connected WordPress site, RankHive reads your Search Console data and your pages every week. When that analysis finds a URL that should point somewhere else, such as a page that has lost its content or one of two pages competing for the same search, it drafts the redirect with the old and new URL side by side. It is not a 404 monitor and won't catch every broken URL, so keep checking the Page indexing report as described above. When you approve, the RankHive plugin writes the redirect to WordPress and the Change Log records it. Reverting a redirect RankHive created turns it off, since the plugin does not delete redirect rules.
Related reading
- Search Console errors on WordPress: every Page indexing status and its fix.
- Discovered – currently not indexed: when the page exists but Google has not indexed it.
- WordPress technical SEO: permalinks, redirects and the rest of the setup.
Your job is to redirect the 404s that had value and let the others be. Sort them by hand with the steps above. On WordPress, RankHive drafts a redirect when its weekly analysis finds one is needed, and ships it only after you approve it.