How to Find and Redirect 404 Errors in WordPress
Dead URLs cost you visitors, backlinks and crawl budget. Here is how to track them down and send each one to the page it should have been all along.
One click, one expectation, then nothing but "page not found". The 404 is the most annoying dead end on the web. Your visitor sees a disappointment, Google sees a site nobody maintains, and you see potential you paid for and never collected.
The good news is that almost every 404 can be defused with one clean redirect. This guide covers why they appear in the first place, how to find them reliably instead of stumbling over them, and how to turn each one into a working route again.
Where 404 errors come from
A 404 means one thing: there is nothing at this address any more. In a WordPress site that has been running for a few years, that happens faster than you would expect. The usual causes:
- Deleted or merged posts: you remove an old article or fold two pages into one, but the old URL is still stored in search engines and in other people's links.
- Changed permalinks: a new title, a different category structure or a change to the permalink settings rewrites the URL. Every link to the old address now points at nothing.
- Typos in backlinks: another site links to you and gets a character wrong. The mistake is not yours, the 404 is yours anyway.
- Migration and relaunch: moving to a new domain, a new theme or a new site structure often takes whole URL patterns with it.
Why dead links actually hurt
404 errors are not a cosmetic problem. They cost you reach and trust in three measurable ways at the same time:
- Poor user experience: people who land on an error page usually leave immediately. The prospect is gone before they have seen anything you offer.
- Wasted SEO and backlinks: when a valuable external link points at a dead URL, the link equity goes nowhere. Without a redirect, none of that trust reaches a page that is still live.
- Wasted crawl budget: search engines crawl your site with a finite amount of effort. Every dead URL a bot keeps checking is time it does not spend on the content that matters.
Finding them reliably
Before you can redirect anything, you need to know which URLs are running into nothing. The most complete picture comes from combining three sources, because each one sees errors the others miss.
Google Search Console
Under Pages, in the indexing report, Search Console lists URLs that return a 404. This is your most important source for errors Google already knows about and that may already be costing rankings. The catch is latency: the data is often several days old.
Server logs
Your server access logs record every request with its status code. Filtering for 404 shows you errors no user reports and no Search Console picks up, including malformed bot requests. The trade-off is comfort, since reading raw logs is technical work and nobody does it weekly.
A live 404 monitor
The convenient option is a 404 monitor running inside WordPress. The one in Linkjet logs every URL that triggers a 404 on your site, in real time, without you digging through logs. Each entry then turns into a redirect with a single click. That link between finding and fixing is what saves the most time in practice, because the two steps normally live in different tools.
Step by step: redirecting a dead URL
Here is how a logged error becomes a working redirect:
- 1. Open the 404 monitor: in Linkjet you get the list of URLs that produced a 404, usually with the most frequent hits at the top.
- 2. Pick the dead URL: choose the entry you want to fix. The address itself usually tells you what content was expected there.
- 3. Set the destination: enter the URL that comes closest to the original content. If there is no exact successor, choose the nearest match by topic rather than the homepage.
- 4. Redirect it as a 301: select redirect type 301, permanent, and save. From that moment, anyone calling the old address arrives at the right page.
The 301 is a deliberate choice here. It tells search engines the old address has moved for good and carries the accumulated link equity to the new target. Which code fits which situation is covered in detail in the guide to setting up 301 redirects.
Redirect it, or send a deliberate 410?
Not every dead URL deserves a redirect. The question that decides it is simple: does a reasonable successor exist?
| Situation | Right answer | What it does |
|---|---|---|
| A renamed post, a merged page, an updated guide | 301, permanent redirect | Saves the visitor and carries the link equity to the new page |
| An expired giveaway, a discontinued offer, content gone for good | 410, Gone | Tells search engines the page vanished on purpose and speeds up removal from the index |
| A URL that never existed, for example a typo in a foreign backlink | 301 to the intended page | Recovers a backlink somebody else broke |
Alongside 301 and 410, Linkjet also supports 302, 307 and 308. For temporary detours you reach for 302 or 307, for permanent ones 301 or 308, and for content that is genuinely gone, 410.
Hundreds of 404s at once: bulk work and automation
After a migration you rarely have three dead URLs. You have three hundred. Working through them one by one is where good intentions go to die.
This is where the machine readable side of Linkjet helps: the complete list of logged 404 URLs can be read out through the REST API. That opens up a workable process. You hand the list to an AI that proposes a matching destination for each dead address from your existing content, for example the closest post by topic. You review the suggestions and set up the redirects, instead of researching every URL by hand. Because Linkjet makes no external calls of its own, the data stays on your server and only goes where you send it.
If dead links elsewhere on your site are also on your list, the tools for that job are collected in the broken link checker comparison. A 404 monitor sees the requests that arrive at your site, while a link checker sees the links leaving it, so the two are complementary rather than interchangeable.
Coming from Pretty Links or Redirection?
If you already maintain redirects in Pretty Links or Redirection, you do not start from scratch. The Linkjet import assistant takes over your existing rules, so you begin with a populated list and only use the 404 monitor for genuinely new errors. If you would rather compare several redirect plugins before you switch anything, we put seven of them next to each other in the free redirect plugin comparison. This guide stays with the workflow instead. Linkjet Free covers everything described here, and prices for the rest of our plugins are on the pricing page.
Conclusion
404 errors are a normal side effect of a site that keeps changing: deleted posts, edited permalinks, mistyped backlinks, migrations. They only become expensive when you leave them lying around. Search Console, server logs and above all a running 404 monitor find dead URLs reliably. Each find then becomes a clean 301 in a few clicks, or an honest 410 where nothing has replaced the old content. That turns dead ends back into working routes and gets the visitors, backlinks and crawl budget back.
Spot dead URLs and redirect them in one click
Linkjet logs 404 errors automatically, turns any entry into a 301 redirect and exposes the whole list through a REST API. Free, GPLv2, no external calls.
Frequently asked questions
How do I find 404 errors on my WordPress site?
The most reliable approach combines three sources: Google Search Console for errors Google already knows about, even though the data there is often several days old, server logs for a complete but technical overview, and a live 404 monitor inside WordPress for real time detection. A 404 monitor such as the one in Linkjet logs every dead URL automatically, so you never have to dig through raw logs. Each entry then turns into a redirect with a single click, which puts finding and fixing into the same step.
Should I redirect a 404 with a 301 or mark it as 410?
If a suitable successor exists, for example a renamed post or a merged page, a 301 redirect is the right choice because it also carries the accumulated link equity across. If nothing has replaced the old content, a deliberate 410 is the more honest answer, because it actively tells search engines the content was removed for good and Google usually drops the URL from the index faster than it would with a plain 404. Avoid sending every dead URL to the homepage, since Google often reads that as a soft 404 and ignores the redirect. Alongside 301 and 410, Linkjet also supports 302, 307 and 308 for temporary cases.
Why do 404 errors hurt my website?
404 errors cost you on three levels at once: visitors usually leave the error page immediately, valuable backlinks pointing at dead URLs deliver nothing without a redirect, and search engines burn crawl budget on URLs that never lead to content. Dead links like these typically come from deleted posts, changed permalinks, mistyped backlinks on other sites or a migration to a new domain. Left untreated they add up to a visible amount of lost traffic and SEO potential. A clean 301 redirect to a target that matches the original topic prevents most of that damage.
Can I redirect all 404 errors to the homepage?
You should not. Google frequently reads a redirect to an unrelated target as a soft 404 and ignores it, so the link equity of the old URL evaporates instead of arriving anywhere. Choose the closest page by topic instead, for example the renamed or merged article. If no reasonable replacement exists, a deliberate 410 is a more honest answer than a redirect that leads nowhere useful.
How do I handle very many 404 errors after a migration?
With hundreds of dead URLs after a relaunch, the Linkjet REST API earns its keep: you read the complete list of logged 404 URLs in machine readable form and generate matching destination suggestions from your existing content, for example the closest post by topic. You then review the suggestions and create the redirects, instead of researching every URL by hand. If you are also moving over from Pretty Links or Redirection, the import assistant takes your existing rules along so you do not start from zero. Because Linkjet makes no external calls, all of that data stays on your own server.
