You run a broken-link check on your WordPress site and find twelve URLs returning 404 errors.
The tempting response is to create twelve redirects and clear the report.
That can be the wrong fix.
WordPress 404 errors are symptoms, not automatic redirect requests. One URL may be broken because somebody typed the link incorrectly. Another may belong to a page that moved. A third may point to content that was deliberately removed and has no meaningful replacement.
Those situations need different actions.
The useful question is not simply, “How do I get rid of this 404?” It is:
What was this URL supposed to do, and what should happen when somebody requests it now?
This guide gives you a practical way to answer that question.
A 404 response means the requested resource was not found at that URL.
That tells you what happened when the URL was requested. It does not tell you why it happened.
A WordPress 404 might exist because:
an internal link contains a typo;
a page slug changed;
an old post was deleted;
two pages were consolidated;
a product or service page was retired;
an external website is linking to a URL that never existed;
an old campaign URL is still being requested;
a page that should exist has disappeared unexpectedly;
the website is displaying an error-like page while returning the wrong HTTP status.
Those causes matter because the correct response is different in each case.
Google’s guidance on soft 404 errors makes the same distinction. If content has moved, a permanent redirect may be appropriate. If content has been removed and there is no suitable replacement, returning a real 404 or 410 can be correct.
Google has also explained that ordinary 404s are a normal part of websites and do not automatically require redirects. Its Search Central guidance on 404s specifically cautions against blindly redirecting missing URLs to merely similar pages or the homepage.
So before changing anything, diagnose the URL.
For each missing URL, work through these questions in order.
1. Should the requested page still exist?
If yes, investigate why it is returning a 404.
The page may have been deleted accidentally, left unpublished, moved to draft, affected by a permalink change, or disrupted by another site problem.
If the intended page still belongs on the site, restoring it may be better than creating a redirect.
If no, continue.
2. Is the 404 being caused by a broken link rather than a missing page?
Suppose an article links to:
/wordpress-suppport/
but the real destination has always been:
/wordpress-support/
The problem is the source link.
Correct the link wherever you control it. You do not automatically need to create a permanent redirect for every misspelling that has ever been requested.
If the URL was once valid, continue.
3. Did the old page move, or is there a genuine replacement?
If the old URL represented content that now lives at a new URL, a permanent redirect is normally appropriate.
The replacement should satisfy substantially the same user need.
A retired service page redirected to its direct replacement makes sense. A deleted article redirected to an unrelated blog post simply because both mention WordPress does not.
Google’s redirect guidance recommends permanent redirects when a page has permanently moved and advises directing users to the correct new location.
4. Was the page deliberately removed with no useful replacement?
A real 404 may be the right result.
You can still make the site’s 404 page helpful by providing navigation and useful routes back into the site. That does not mean the missing URL itself needs to resolve to another page.
5. Does the situation look abnormal rather than isolated?
A sudden cluster of 404s deserves investigation before individual URLs are patched one by one.
For example, dozens of important pages disappearing after a migration, permalink change, plugin change, or deployment may indicate a wider technical problem.
That is no longer simply a broken-link cleanup job. Record what changed and escalate the underlying issue.
Fix the source link when the destination already exists and the link itself is wrong.
Common examples include:
a typing error in an internal link;
an old internal link that was never updated after an approved URL change;
a menu item pointing to the wrong path;
a copied URL containing an accidental extra character;
a link using the wrong slug.
Imagine you find this inside an older article:
/wordpress-maintanance/
The intended live page is:
/wordpress-maintenance/
If the incorrect version was simply a typo, update the source link.
This removes the error from the path you control and sends future visitors directly to the correct destination rather than making them travel through an unnecessary redirect.
There may still be cases where the incorrect URL receives meaningful external traffic or links and a redirect deserves consideration. That is why it helps to record the source of the 404 before making the decision.
The distinction is simple:
Broken link: correct the link.
Moved page: consider a redirect.
Those are not the same problem.
Sometimes the 404 is the mistake.
A page that is supposed to be live may have been:
deleted accidentally;
moved to draft;
unpublished during an edit;
affected by a URL or permalink change;
lost during a migration;
removed even though the business still needs it.
Before redirecting the URL elsewhere, ask whether the original page should still exist.
For an important service page, campaign landing page, documentation page, or frequently referenced article, restoration may preserve the intended user journey better than sending visitors somewhere different.
Do not recreate a page merely because an old URL appears in a report, though.
First confirm that the content still has a legitimate purpose, that the information is current, and that restoring the page fits the site’s present structure.
If the disappearance was unexpected and you do not know why it happened, treat that as an investigation point rather than guessing.
Use a permanent redirect when an old URL has a clear new destination and the move is intended to be permanent.
Good candidates include situations where:
a page received a new permanent URL;
two overlapping articles were deliberately consolidated;
an old service page was replaced by a new version serving the same purpose;
a site migration changed URL paths;
a retired page has a direct successor that satisfies the same reader need.
The important part is the relationship between the old URL and the destination.
A redirect should answer the visitor’s original request as closely as possible.
For example:
Old URL: an article explaining how to prepare a specific WordPress task.
New URL: the updated version of that same article.
That is a logical redirect.
Now compare it with:
Old URL: a discontinued service page.
New URL: the homepage.
The homepage may be important, but that does not make it the correct replacement.
Redirecting unrelated missing URLs to the homepage can confuse visitors. Google’s site-move guidance also warns against sending many old URLs to an irrelevant destination because those redirects may be treated as soft 404s.
When you approve a redirect, point the old URL directly to the final intended destination where practical rather than deliberately building a chain of redirects.
A clean 404 is not automatically a defect that needs to be eliminated.
If a page has been intentionally removed and there is no meaningful replacement, returning a 404 can accurately communicate that the resource no longer exists.
The same may apply to:
nonsense URLs generated by bots;
malformed URLs that were never real pages;
obsolete content with no suitable successor;
external links pointing to URLs that never existed;
old temporary pages that should not return.
Google’s current crawling guidance says that when content is no longer available and there is no replacement with similar content, a 404 or 410 response is appropriate.
That does not mean ignoring the visitor experience.
Your site’s 404 template can still provide normal navigation, a way back to useful content, or a search option. The key is that the server should still communicate the correct status for the missing resource.
A soft 404 is different.
This can happen when a page looks like an error or has little meaningful content but returns a successful 200 response instead of an appropriate error status.
If Search Console reports a soft 404 for a page that genuinely should exist, investigate why Google is seeing the page that way. The problem may involve missing content, failed resources, rendering problems, or another technical issue.
Do not assume that adding a redirect is the solution.
Use this table when reviewing individual URLs.
| Situation | First action | Redirect? | Escalate when |
|---|---|---|---|
| Internal link contains a typo | Correct the source link | Usually not necessary for the typo alone | The bad URL has meaningful external links or traffic |
| Page should still exist | Investigate and restore the intended page | Not as the first response | The page disappeared unexpectedly or restoration is technically unclear |
| Page permanently moved | Confirm the final replacement | Usually yes, using an appropriate permanent redirect | The replacement is uncertain or several URLs are involved |
| Two pages were intentionally consolidated | Confirm which page became the primary resource | Usually yes | Canonical, migration, or wider SEO decisions are involved |
| Content was intentionally removed with no replacement | Keep a true 404 or consider 410 where appropriate | No | Business or legal requirements affect removal |
| Random or malformed URL never existed | Leave it unavailable | No | The volume suggests a technical, security, or routing problem |
| Error-looking page returns 200 | Investigate the soft 404 | Not automatically | Rendering, server, theme, plugin, or application behaviour is involved |
| Many important URLs suddenly return 404 | Stop treating them as isolated errors | Do not bulk redirect blindly | Immediately investigate the wider site change |
The table is a triage tool, not a substitute for checking the actual page history and destination.
For recurring WordPress work, keep the investigation separate from the final decision.
A simple 404 Review Sheet can use these columns:
| Field | What to record |
|---|---|
| Broken URL | Exact URL returning the error |
| Found via | Broken-link scan, Search Console, analytics, visitor report, external link, or manual check |
| Source page | Page containing the broken link, when known |
| URL history | Never valid, previously live, moved, removed, or unknown |
| Intended content | What the visitor was probably trying to reach |
| Live replacement | Exact replacement URL, if one genuinely exists |
| Recommended action | Fix source link, restore page, redirect, keep 404/410, or investigate |
| Reason | Short explanation for the recommendation |
| Approval required | Yes or no |
| Owner | Person responsible for the next action |
| Status | Open, awaiting approval, completed, or escalated |
| Checked date | Date the action was verified |
This prevents a list of 404s from becoming a list of unexamined redirect requests.
It also creates a useful handoff between routine website administration and decisions that need an SEO specialist, developer, content owner, or business owner.
A virtual assistant can often collect the URLs, identify the source pages, correct obvious internal-link mistakes, update approved internal links, verify approved changes, and maintain the review sheet. My broader guide to WordPress tasks you can outsource to a virtual assistant covers that recurring maintenance role and the points where technical or strategic decisions should be escalated.
Redirect strategy should not become an automatic VA decision simply because the assistant found the error.
The useful division of work is:
Find and document the problem reliably. Apply straightforward approved corrections. Escalate decisions where the correct destination or technical cause is uncertain.
A 404 report can make every missing URL look like the same problem.
It is not.
Some URLs need a corrected link. Some pages need restoring. Some genuinely moved content needs a permanent redirect. Some missing URLs should remain missing. Others are clues that something larger has gone wrong.
That is why the best first action is diagnosis.
For every 404, establish what the URL represented, whether the content still belongs on the site, and whether a genuine replacement exists. Then choose the response that makes sense for the visitor rather than the response that simply removes a row from an error report.
At Boost VA, I can support the recurring execution around WordPress 404 reviews, including checking reports, tracing source links, updating approved internal links, maintaining the review sheet, verifying completed changes, and flagging URLs that need an SEO or developer decision. If that work is becoming another website-maintenance backlog, explore my WordPress and virtual assistant support and tell me what needs keeping on top of.