Let’s be honest: nobody opens their web browser in the morning thinking “great, a 404 error”. Yet this little HTTP error code is part of daily life for every website. It appears when the requested URL doesn’t match any resource on the web server.
In plain English, the browser did talk to the server, the network is fine, but the specific page you wanted can’t be found at the address given. This “404 Not Found” means the requested page no longer exists, has been deleted, moved to another directory, or was mistyped by the visitor.
It is frustrating for the visitor, potentially costly for the business, and never neutral for organic search.
404: a simple definition, real consequences
Technically, 404 is a response code of the Hypertext Transfer Protocol. The server returns “not found” when the requested file (for example /blog/seo-guide.htm) isn’t in the expected folder, doesn’t have the right extension (htm, asp, php…), doesn’t have the right access permissions, or has been renamed without a redirect.
Sometimes the cause is more trivial: a typo in the URL, a broken link copied and pasted from an article, a script generating faulty syntax, a WordPress migration that didn’t keep the old address structure, a MIME type wrongly declared by the system administrator, or even a directory problem not defined in the server configuration.
In real life, a 404 often appears after a website update: someone “tidied up” the content, deleted an old web page, changed the URL of the new page, then forgot to redirect. The result: a visitor arrives via an external link (a backlink, a social network, an advertising email campaign) and… falls into the void.
On top of that, the Googlebot crawling your site also sees the 404, wastes a little crawl budget, and your SEO thanks nobody. An isolated 404 entry isn’t dramatic; a high, recurring, untreated number can hurt your conversion rate and overall performance.
So why “404 error”?
Because it is a standardised HTTP error code. In the web protocol, all response codes are grouped into families: 1xx for information, 2xx for success, 3xx for redirection, 4xx for client-side errors and 5xx for server-side ones.
The HTTP 404 error is therefore “page not found”: the server did receive the web browser’s request, but the requested resource can’t be found at the address given. The first digit “4” says “request problem on the client side”, and the number “04” specifies precisely “not found”.
This isn’t an opinion, it’s a convention: using a common code lets search engine bots, browsers and audit tools understand the situation without ambiguity.
Concretely, imagine a /products/ directory on your computer (or on the server’s disk): if the URL points to /products/red-shoes.htm while the file is actually called red-shoes.html, you get a 404. Same thing if the page was moved to another directory without a redirect, or if the administrator changed its location during a migration.
Sometimes the access permission to the content is missing (read permission not granted to the web process): in that case it is often no longer a 404 but a 403, which is why it pays to check the URL and the exact type of response so you fix the right part of the problem.
Historically, different servers have adopted the same semantics, even if the implementation varies: Microsoft IIS displayed its own system error pages (classic on ASP or HTM sites), while Apache and Nginx make it easy to create a custom 404 error.
Wherever you are, the logic is the same: the requested route doesn’t match any available resource. An incorrect MIME type (for example declaring a PDF as text/plain), a missing file, a broken link in a template, and you get the same “404 Not Found” response.
“Client error” doesn’t mean the visitor is to blame; it means that, from the protocol’s point of view, the request points to something that no longer exists at that location. A link checker can help detect 404 errors in bulk, then a wider server-side test confirms which layer (reverse proxy, application, CMS) is responsible for the response.
You can try a similar URL (same slug, htm vs html), check the directory, the permissions, whether the file exists and the MIME type exposed. In a few minutes, you can tell whether the 404 is real (the page doesn’t exist) or “accidental” (wrong path, wrong extension).
The 404 number also fits into a chain of decisions on the search engine side: a search engine bot discovering a 404 understands that this address shouldn’t be indexed. That’s useful: you can create a visible “404” page (with a friendly message) while still returning the correct HTTP error code, so that Google doesn’t treat it as ordinary content.
That is the whole point of a custom 404 page: human on screen, technical in the response.
For tooling and troubleshooting, the ideal approach is sequential: first check the URL, then check the location and directory on the server, then confirm that no rule blocks access (ACL, filesystem permission). If everything is fine, inspect the application: routes, controllers, rewriters, and fix.
If needed, use a 301 redirect to send the user to an equivalent page. Audit suites (Search Console, crawlers) will tell you whether the old URL’s “spot” still generates traffic: a good test for prioritising what to repair first.
Finally, why insist so much on this particular code? Because a 404 served properly is a clean signal. If you return 200 on an empty page, bots hesitate; if you return 404 when the page is really gone, they understand and move on to the next one.
If the page has changed address, prefer the 301. And if you want to do better than “sorry…”, set up a useful 404: a small search box, links to key sections, a contact form, a button to use a link checker or to help the team report the broken URL.
The “404 error” standard isn’t just jargon; it’s a common language between web browser, server, software and bot, a language that, once mastered, saves you from exasperating your visitors and helps you keep control of access to your content.
The impact of 404s on users, business and SEO
For the user, a 404 is an abrupt end to the experience. They were looking for specific information, a product, a reference, and find themselves facing a page-not-found sign. Many leave the site straight away; your bounce rate climbs, your traffic drops, your conversion rate suffers.
On an ecommerce site, that can mean a lost sale; on an editorial site, a lost reference page. On the SEO side, search engines look at the whole picture: broken internal links, old backlinks pointing to old URLs without a 301 redirect, the volume of 404 errors detected, how quickly you can fix them.
If you let these signals “rot”, you hurt the perceived quality of the site and dilute the authority passed on by sometimes very valuable links.
A word, too, on the common confusion between “hard” 404 and “soft” 404. A hard 404 does return the 404 code and displays an error message. A soft 404 displays a page that seems to exist (with content), but whose HTTP response is inappropriate (200 OK although the resource is empty or deleted).
Search engines don’t like these ambiguous situations: they get in the way of properly controlled indexing and muddy your SEO.
What are the SEO differences between 404 and 410 errors?
From an SEO point of view, 404 and 410 don’t tell search engines exactly the same story. Both are HTTP error codes, but the semantics differ: 404 = “page not found (maybe temporary)”, 410 = “resource permanently removed”. In other words, 410 is more explicit.
Google and co. eventually treat a persistent 404 as a disappearance, but a 410 sets the status immediately: “this URL will no longer exist”. The practical result: 410 favours faster deindexing, while a 404 leaves a small door open (useful if the situation is temporary: test, migration, planned return).
For day-to-day operations, think “intent”. If you moved a page to a new location (same directory or another), the best SEO option is still the 301; if you deleted it with no replacement, 410 is the most consistent; if you don’t know yet (content being redesigned, application interface under construction), 404 is acceptable.
A good admin habit is to document the entry at the time of deletion: reason, old URL, action chosen (301/404/410), date.
Technically, the difference doesn’t require big work: whether you are on Apache/Nginx, Microsoft IIS or an ASP framework, it is mostly about configuring the right response on the server or software side. Also check your MIME headers (a wrongly declared type can cause odd behaviour in the web browser), and the file-to-URL match in the target directory.
When in doubt, start by checking the URL (typo, case, extension), try a similar one (similar slug), then run a wider test: server logs, inspection of the routing layer, checking the rewrite rules. An administrator can, in a few minutes at the computer, work out whether to return 404, 410… or fix the path.
From a “linking and signals” point of view, 410 sends a clearer message to bots: “don’t insist”. It is therefore relevant for saving crawl budget when many old pages have to disappear. The 404, for its part, can protect the reader experience when the page is coming back soon (short maintenance, rollback, fix in progress).
In both cases, take care over the error page displayed: even if the machine response is 404 or 410, nothing stops you from providing human-friendly formatting (search, links to categories, contact).
One last operational tip: industrialise. A check script, server rules and logging will save you back-and-forth. On IIS (Microsoft), on a PaaS, or in a headless CMS, store the decision (404/410) in software or a routing table; expose a simple interface for your teams.
And, before any redesign, run a pre-production crawl and a post-production “health check” to verify that critical URLs return the expected HTTP error code. That will save you from “killing” a URL that should have been 301-redirected… and from accidentally sending a 410 where a temporary 404 would have been enough.
How to identify 404 errors (without spending the night on it)
The first sensible step is to detect. In Google Search Console, you have a dashboard listing the 404 errors known to Google, the URL requested, the detection date, and sometimes the referrer (the page pointing to your 404). It is a free and appropriate tool for tracking the overall state.
For wider exploration, Screaming Frog (free or paid version) acts as a link checker and reports all internal 404s, redirect chains and not-found errors caused by an unavailable file. On a smaller site or for occasional use, a Broken Link Checker (there are browser extensions, WordPress plugins and online checkers) lets you check the URL, identify dead links and the origin of the problem.
Don’t forget your server logs: they often hold the most reliable information about the address requested, the agent (bot, Googlebot, browser), the code returned and the directory requested. Reading them regularly in an analysis tool or with a small in-house script helps you work out whether the error comes from a moved file, a missing permission, an undefined MIME type, a badly configured interface or simply a broken link in an article.
Fixing the 404 error without breaking anything: the redirect strategy (and common sense)
Once the cause is found, fix it. If the URL was misspelt in a page, correct the syntax and update the link. If the resource was deleted or moved, put in a 301 redirect to the most appropriate URL: the exact new page if it exists, or failing that the category, the parent directory, or even the home page when there is no equivalent left.
The important thing is to preserve the visitor’s intent and the original semantic reference; redirecting every 404 to the home page is easy, but rarely effective for the user experience and not ideal for SEO. On WordPress, dedicated plugins (Redirection, Rank Math, Yoast) help you create and track redirects without touching the server code.
Avoid redirect chains (301 → 302 → 301 → …): each hop “eats” a bit of the user’s patience and can hurt performance. Also make sure the new destination returns a 200 response code, that the page is available and that navigation doesn’t cause a loop.
An appropriate 301 redirect restores traffic, repairs the value of your backlinks and sends a clean signal to search engines.
The custom 404 page: from error to delight
Even with carefully managed redirects, some visitors will land on your 404 page one day. That is precisely where a custom 404 page can turn a “404 error” into a brand moment. Instead of “displaying” a dry “page not found” line, offer a human message (“Oops… we lost this page in a wormhole”), a funny visual, a short video.
Offer useful links: internal search, reference pages, categories, best-sellers, contact email and phone number. Add a very short form if the user wants to report the problem (“tell us the URL, we’ll fix it”).
This creation shouldn’t be a theme park: stay clear and accessible, with no bias that encourages a wrong choice. The aim is to help, keep the spirit of the service and offer something relevant right away. From an SEO point of view, make sure the page really returns the 404 code (not 200) so that search engines use the information properly: page absent, no indexing.
As a bonus, add a “try another address” block with autocomplete; in some interfaces, a mini client-side “check the URL” helper even prevents recurring typos.
Organisation, governance and tooling: stopping 404 errors from coming back
The best 404 is the one you never see. To get there, set up a little governance. At every release, whether it’s a new page, a deletion, a restructure of the site tree or a change of directory, the checklist should include: an SEO audit of internal links, a redirect plan (ideally tested in pre-production), sitemap updates, and a check of the links in the pillar articles that generate the most traffic.
Every digital team (content, product, system administrator) has its part: document what was changed, note the old URLs, define the replacement URL.
For tools, combine Google Search Console (the “Google” and Googlebot view), Screaming Frog (the exhaustive “crawler” view), a recurring external-link checker, and your Analytics/dashboard to measure the impact on bounce rate, conversions and organic traffic.
HubSpot suites or other CRMs also make it easier to track which pages convert after a 404 (you measure the effectiveness of a CTA block on the 404: “download our guide” or “get in touch”). On rich websites, setting up an alert when an internal link becomes broken is a small service that saves a lot of time.
Special cases for 404 errors: WordPress, in-house CMS, hosting, permissions
On WordPress, 404s often appear after a change to permalinks. One badly applied setting, and everyone sees “page not found”. The most appropriate solution is sometimes the simplest: try “Save” on the permalinks (which regenerates the .htaccess), check the redirect rules, then resolve the remaining 404s with a plugin (and a quick Screaming Frog crawl to check).
In a custom CMS, the cause is often a badly routed directory, insufficient file permissions, or a MIME type not assigned for a format (pdf, csv, image); on the hosting side, moving a folder or maintenance can create a flurry of 404s on “example.com/…”.
Here again, system logs are your best friends: work out the origin and repair.
Also think about external links: when a media outlet cites your article with a misspelt name, you inherit a “reference” 404. Two options: contact the publisher to change the link (sometimes slow), or redirect from the old spelling to the right page (immediate, appropriate for the user).
In a B2B context, the custom 404 page can even display a commercial message (“need help? call us…”): discreet, useful, measurable.
404 errors, SEO and “good” practices without lists (promise)
Before a redesign, map the old directory: use a crawler to extract all the URLs visited in the last 12 months (cross-check Analytics + Search Console). For each one, choose a new destination page. Then create the 301 redirect plan, test it in pre-production, verify it in production; if a 404 error remains, it should be repaired within the week.
Meanwhile, customise the 404 to catch attention without hurting the user experience: a clear title, a paragraph that explains, useful links, a search field, a simple form to report the issue, and, why not, a light image and a micro video.
On high-traffic pages, watch the number of 404s generated by historic internal links (old articles pointing to deleted content). It is better to change the anchor and the link at the right place than to pile up redirects. And remember: a redirect isn’t an eternal band-aid; it is a bridge. If you create new content, update it with the final URLs.
When you deliberately remove a product or service that has become obsolete, own the 404 if no equivalent solution exists: it is the right code, the appropriate response. But pair it with an alternative call to action (“download the replacement guide”, “discover the new page”).
On the SEO side, don’t “pretend” with misleading 200s: search engines prefer the truth (a clear 404) to an empty page that returns 200. And if you migrate massively, think “crawl budget”: avoid zigzag redirects, centralise, then track the evolution of detected 404 errors in Google Search Console.
Measure, or nothing: from 404 to dashboard
You only manage well what you measure. In Analytics, track the sessions that end up on the 404 page (create a segment, look at acquisition channels, performance indicators, entry pages). In Search Console, look at the indexing tab → pages → “not found”; sort by priority (those that receive external links, those clicked from the SERP).
Note the 404s generated by bots: not everything needs fixing immediately if no human can reach a page from your site. Use a regular checker (weekly is a good rhythm) to detect new 404 errors and resolve spikes after every update.
For the marketing team, it is useful to put a “404 rate / 1,000 page views” KPI in the dashboard, plus a “backlinks to 404s fixed via 301 redirect” KPI. You will then see the SEO impact of the fixes: positions recovered, organic traffic restored, conversions back.
And if your platform includes a “404 → conversion” module, you can even attribute a sale saved by an excellent 404 message. Yes, it happens.
A quick 404 error FAQ to finish properly
Is a 404 bad for Google?
It isn’t “bad” if it’s occasional, consistent and you fix it. What causes trouble is volume, the lack of a redirect when there is a replacement, confusion (soft 404), and broken internal links all over the place.
**Should I redirect everything to the home page?**No. Redirecting to the home page is acceptable as a last resort, but the most appropriate solution is still the closest page semantically. It is better for the user and for search engines.
How do I find out where my 404s come from?
Google Search Console gives good leads. Screaming Frog tells you how your internal pages link to each other. Server logs give the rawest view (and often the most useful).
Do I need a 410 (Gone)?
To signal that a resource is permanently removed, 410 is appropriate. In practice, a well-handled 404 plus a 301 redirect when a replacement exists is enough for most sites.
And on WordPress?
Check the permalinks, the .htaccess, test your redirect plugins, run a link checker. Most post-redesign “404 not found” errors come from a simple detail.
The moral of the 404 error story
The 404 error is like a “page not found” sign at the end of a street. You can let people turn back, or you can put up a clear redirect, give a helpful pointer, customise the message and help the person reach the content they were looking for.
Between two equivalent websites, the one that fixes things fast, avoids broken links, uses console and SEO audit tools, measures the effectiveness of its fixes and creates a well-thought-out custom 404 page will have the edge: less lost traffic, a smoother user experience, more stable SEO.
In short, the 404 is not a fatality. It’s a signal. And well handled, it is even a small opportunity to show that your website can make a mistake… without losing its user.
