Editorial illustration.
A visitor clicks a link from an old article, a search result or a bookmarked page. Instead of the information they expected, they see a short message saying that the page cannot be found. Most people do not stop to investigate. They go back, search elsewhere or close the tab.
A 404 response is sometimes the correct technical answer: the requested resource does not exist. The missed opportunity is treating the error page as the end of the conversation. A useful 404 page can explain what happened, offer sensible next paths and give the site owner evidence about which links need repair.
Quick Answer
Treat a 404 as both a user-experience problem and a maintenance signal. First confirm whether the URL is genuinely obsolete or whether a broken link, routing rule or deployment mistake caused it. Redirect only when a close replacement exists. Otherwise, keep the 404 status, show a helpful page, and offer navigation, search or a small set of relevant destinations.
Do not redirect every missing URL to the homepage. That hides broken links from visitors and from your own monitoring. A redirect should preserve the visitor’s intent, not merely remove an error from a report.
Why a 404 deserves attention
Broken links waste more than a click. They interrupt a task, weaken confidence and can make an organisation look as though it has stopped maintaining its information. An old product guide, event page or support article may still receive visitors through external links long after its original navigation entry disappears.
There is also a difference between a single mistyped URL and a pattern. One request for /guides/old-name may be harmless. Hundreds of requests for a URL that used to contain an important tutorial may point to a missing redirect. A cluster of 404s after a redesign can reveal a migration problem rather than random internet noise.
A practical recovery workflow
1. Reproduce the request
Open the exact URL and record the status code, final URL, page title and response behaviour. Test it in a private window as well as your normal browser so a local cache or login session does not mislead you.
Check whether the problem affects one path or a whole section. A typo in one slug is different from every page under /docs/ returning 404. Look at the server, hosting or edge logs when available, but avoid storing unnecessary personal data in those logs.
2. Decide whether the page moved or disappeared
Search your source files, CMS content and deployment history for the old slug. A page may have been renamed, moved into a category or accidentally excluded from the build. Confirm the intended destination with the content owner; guessing from a similar title can send readers to the wrong explanation.
If the content still exists under a new permanent URL, a redirect is usually appropriate. If it was replaced by a genuinely different page, do not pretend that the two are equivalent just because both mention the same broad topic.
3. Repair internal links first
Search the repository for the missing path and update links that you control. Check navigation, related-article cards, footer links, XML-generated references and old call-to-action buttons. A redirect protects an external bookmark, but it should not excuse a broken link that remains in your own article.
Pay attention to spelling, trailing slashes, uppercase letters and URL-encoded characters. A link can look correct in a document while differing from the deployed route by one character.
4. Choose the smallest useful redirect
Use a permanent redirect when a page has moved and the replacement clearly serves the same purpose. Use a temporary redirect only when the change is genuinely temporary. The exact configuration depends on your server, hosting platform or framework, so follow that system’s documented redirect mechanism.
Avoid chains such as old URL to an intermediate URL to the final URL. Point the old address directly to the current destination. Test both the status code and the final content, because a technically successful redirect can still land on an irrelevant page.
5. Build a helpful 404 page
The page should say, in plain language, that the requested page is unavailable. Keep the site’s identity and main navigation visible, but do not bury the useful action beneath a large graphic. Offer a search box if your search works well, a link to the main article index, and a few relevant routes based on the section the visitor was trying to reach.
Include a way to report a broken link when the site is important enough to need one. Do not expose internal stack traces, filesystem paths or debugging details. The error page is public and should be safe for an unauthenticated visitor.
6. Test real recovery paths
Test an old article URL, a missing image, a mistyped path and a URL with a query string. Confirm that the 404 page itself returns a 404 status rather than returning a visually similar page with a 200 status. Test on a phone, because a recovery link that is difficult to tap is not much of a recovery path.
If the site has multiple languages, check whether the 404 page respects the visitor’s language route. A helpful English message on a Malay content path may still feel like a failure even when the technical response is correct.
Common mistakes to avoid
The most common mistake is sending every missing URL to the homepage. It creates a soft failure: visitors see a page, but not the answer they requested. It also makes automated checks less useful because missing content appears to exist.
Another mistake is redirecting to the nearest keyword match without checking the reader’s goal. A retired event announcement should not silently become a generic events page if the visitor needs the original date or outcome. Explain the change or preserve an archived page when the information remains valuable.
Do not depend on one monthly crawl. Monitor important routes after deployments, and review recurring 404 patterns from logs or analytics in a privacy-conscious way. Keep a small list of routes that must always work, such as contact, login, checkout, documentation and support pages.
My Take
A 404 page is a small test of whether a site understands its visitors. The best response is not always a redirect. It is a clear decision: restore the page, redirect to a true successor, or acknowledge that the route is gone while offering a useful way forward.
Bottom Line
Repair internal links, redirect only to a genuine replacement, and make the 404 page useful when no replacement exists. Then test the result after every major content move. A missing page may be unavoidable; a visitor being abandoned there is usually a design choice.