March 16, 2007
We understand what 404 means: Page Not Found. But the average internet user has no idea what 404 means or what to do about it. To them, it's yet another unintelligible error message from the computer. Most 404 pages are unvarnished geek-speak. Consider the default 404 page under IIS:
The default 404 page under Apache is no better:
Internet Explorer tries to shield the user from these poorly constructed 404 pages by automatically substituting friendlier error messages:
It's not bad. It's certainly an improvement over the default 404 from Apache or IIS. But we can do better.
We can stop relying on the default behavior of our webservers and web browsers, and create our own custom 404 page. Unfortunately, many sites have custom 404 pages that are barely discernable from the generic webserver defaults. You wonder why they bother.
So, what exactly should a user-friendly custom 404 page do? Although there's an entire website dedicated to documenting funny 404 pages, funny isn't necessarily helpful. What can we do to help the user at this point? I have some ideas.
- Drop the 404
Yes, the HTTP response code is 404, but there's absolutely no reason that ever needs to be shown on the actual page. Error codes aren't helpful. A simple explanation of the problem in plain English is all that's required. Any 404 page that has the characters "404" on it, if not already an outright failure, is already well on its way to becoming one.
- Automatically notify you of the 404
Repeat after me: it is not the user's job to inform you about problems with your website. If you require the user to click a button to notify you about a 404, or if you require the user to fill out a broken link form, you have utterly failed your users. 404 notification should be automatic, and by that I do not mean "sit in my log files until I eventually have time to look for it". I suggest weekly or monthly 404 rollup reports, emailed automatically to the powers that be. I'd also recommend real-time email notification if there is a sudden spate of 404s, so you have an opportunity to fix the problem while it's still relevant-- before the world gives up on your seemingly nonexistent page.
- Try to find what the user was looking for and provide links to possible matches
Don't just put a search box on the 404 page and force the user to perform a search. That's a cop-out. Instead, automatically perform a search on their behalf, using the erroneous URL as the search input, and display those results on the 404 page. You can also try to correct the URL, based on rules derived from the top ten or top fifty observed 404 errors. Does the URL end in .htm instead of .html? Is it spelled wrong? Are your URLs case-sensitive? Was the page moved, renamed, or reorganized somewhere else? It's sensible to have a search box on your 404 page for convenience's sake, but forcing the user to perform a search should always be the method of last resort.
- Present links to the most popular or most recent items
If someone is visiting your website, statistically speaking, there's a good chance they are coming to see the same attraction everyone else is. Even if they aren't, your popular content is popular for a reason. Why not present links to your "greatest hits" on the 404 page? Similarly, if you run a periodic website like a blog, or a newspaper, display the last few articles or entries on the 404 page. And at the very least, you'll want a link back to the main website. Provide a filtered list of relevant links, and an errant user will never be more than one click away from escaping their current predicament.
- Keep the 404 page simple
Your 404 page should be brief, concise, and to the point.* You're already dealing with confused users who can't find what they're looking for. Don't add insult to injury by spamming the user with a giant, complicated 404 page containing a complete sitemap of your website. For example, the apple.com 404 page makes this mistake.
I found that Jakob Nielsen, A List Apart, and 404 Research Lab also had good advice on making 404 pages potentially user friendly instead of the geeky, incomprehensible dead end signs they usually are.
Unfortunately, I haven't had time to implement a better 404 page on my own website. Yet. If you're looking for live examples of 404 pages that get this right, I can recommend the 1976 design 404 page, as well as the useit.com 404 page. Sadly, this is an extremely short list because so few websites meet the criteria I outlined above. I sampled 404 pages from dozens of websites and most fail spectacularly, serving up 404 pages that are downright user hostile.
Whichever route you choose, never settle for the default 404 page. Replace it with a custom 404 page that is polite, illuminating, and most of all, helpful.
* But not too brief. You have to make your customized 404 page larger than 512 bytes, otherwise IE will assume it's a standard web server 404 message and replace it with its own friendly-ized version.
Posted by Jeff Atwood
One of the best error pages I've ever seen is/was from Dunstan's 1976 Design blog (http://1976design.com/blog/error). I think it hits most of your points for a good error page, although it doesn't automatically search and it doesn't automatically send an error report (although it comes awfully close with a simple "submit quick error report" that requires no forms to fill out).
I don't like useit's "common mistakes" scenarios, these facilites should be provided by the server. My hosting provider looks for .htm, and if it can't find it, it will resolve so .html. Same goes for the case sensitive scenario.
But yes, good 404s rock.
Here's another article I enjoyed on 404s
I’ve been doing a fair bit of revamping on 2Dolphins and moving some pages around. I’ve done .htaccess redirects to handle the majority of these changes.
And I've also created a custom 404 page (http://www.2dolphins.com/notfound.html) to catch anything else and this page includes a Google search box and sitemap to help wayward surfers find what they might’ve been looking for.
A 404 page MUST have the number 404 on it or in the title. If I'm surfing and I run up against one, the first thing I want to realise is that it's a 404 page. Just seeing those numbers is all the info I need. Having all that other stuff is just fine too, but the '404' is key.
I love getting the Apache "double 404" page, the one that says not only did we not find this page, we also could not find the page that is supposed to handle the 404 error. I bet a lot of my fellow nerds appreciate the irony.
I like the 3rd bullet on the IE 404 page!
I think you give users a little too much credit, Jeff. I'd say roughly 3/4 of the 404's I see on my browser come from typo's (mostly mine. but only mostly). A more minuscule fraction come from personal/personnel pages on a shared/institutional server- a situation that would be better served by your suggestions, and/or other measures.
I pose a question about your 'automated report' mechanism: how many of these do you want to read:
[ ERROR ] 404 - Requested Resource:'http://www.codinghororr.com/blog/'
[ ERROR ] 404 - Requested Resource:'http://www.cotinghorror.com/blog/'
[ ERROR ] 404 - Requested Resource:'http://www.codinghorror.com/blag/'
Obviously, some logic could be incorporated into the logging or reporting- but, couldn't (or perhaps, shouldn't) you just redirect the hapless user anyway, using similar logic?
I'm guessing Joe or Jane User only needs three or four 'vanilla' 404 errors to get the gist- and, much like modal dialogs, or other error boxes, are they likely to even read much of it? My guess is no.
Really, I think spiffy 404 pages are much more of an aesthetic, rather than functional issue.
...or we could just be really blunt with users and tell them what we really think ... http://www.homestarrunner.com/404
Sorry, I know it's a bit random, but I find the implementation amusing, as well as perfectly themed for the site in question.
Automatically redirecting to the wrong page is automatically much, much worse than simply having a bland 404 page. Redirecting incorrectly means the user can't go back and manually correct the problem. As a wise Python developer once wrote, "In the face of ambiguity, refuse the temptation to guess."
As Tarkin states, users pick up on what a normal 404 page means fairly quickly. If the 404 replacement page does not resemble a standard error page, you risk confusing the user and making the problem worse.
Also noteworthy is the increased load by attempting to search for the correct results. Any returned information is on a best-guess bases, and going through my server logs, I'm entirely sure I could produce correct results manually for many of 404s.
* Double check every internal link for correctness.
* Keep replacement 404 pages simple and to the point, and avoid incorrect links as much as possible
* Fix simple url problems (.htm-.html)
* Monitor logs for common 404'd pages
For myself, the only time that 404s get annoying is when the link in question is from the same site. Otherwise, I would much rather have a standard, short, 404 page.
Ugh! I've been meaning to do a better job with this for Subtext. Too many things to do.
One question, do you think the page should fit the exact same design as any other page on your site? Or should it clearly be an error page?
Fuck 'em. If anything, 404 pages should be MORE complicated!
Rob O (2Dolphins): Don't mean to be harsh but your site needs another look:
* Buttons that look like tabs!
* The marketplace link that opens another window and sends you offsite! At least have a page explaining what it is first.
* You click the adoption journal 'tab' and the whole top row of navigation changes!
* "We hope everyone had a fun and safe St. Patty's day celebration". Is this a public site - because after a few mins of looking around I still don't know who 'we' are and what they do!? Possibly some kind of dolphin charity...?
Cool! Thank you ;) But what about your 404? ;)
Fuck 'em. If anything, 404 pages should be MORE complicated!
I agree. It's pointless to suggest answers to an user. Better not to even give them the slightest hint of responsibly or compassion.
Whichever route you choose, never settle for the default 404 page. Replace it with a custom 404 page that is polite, illuminating, and most of all, helpful.
Grrr. If there's one thing I hate, its a 404 page that doesn't look like a 404 page. Then you have to stare at it.... and..... is it really a 404? Is it actually helpful? F'in show me a helpful 404 page. I dare you.
You can yell at a user in all caps: you typed it in wrong and/or it doesn't exist anymore: and they will still have no clue.
And... 404 is an english word. Is it really geekspeak? I mean they are using the WWW... even if they never heard the words "world wide web".
404 is the computer equivalent of a flat tire. If my mechanic uses equivocations and start talking about wheel failure, or tells me to "have a professional check the tire" or "your wheels may not be performing properly."
Really, you should tell them that their computer is broke, and give them the 1-800 number to Dell computer.
And that would be helpful.
Show you a helpful 404 page? I did already, in the post itself:
Although neither is perfect..
- useit should automatically fix casing and file extensions, as others have pointed out
- 1976 should automatically notify the site owner without forcing the user to do anything
.. they're the closest to the ideal 404 pages I've yet seen.
The SGI web site used to have a really funny 404, it was a random picture of a baby crying
It made me laugh out loud everytime I saw it.
btw, I think the 404 pages linked here have way too much text on it. SGI's page was just '404 - page not found' but it was a beautiful graphic design that made you almost feel happy to find a bad page
While useit's 404 isn't bad, this annoyed me:
"The most common mistakes in accessing useit.com are:
* Making the URL end in .htm - all pages on useit end in .html (note the trailing "l")
* Using UPPER CASE CHARACTERS - all names are in lower case only"
Both of those "mistakes" are easily corrected with simple url rewriting rules. Since they obviously know about them and they are frequent enough to remark on them, this is user hostile behavior. If you know about it, and there's an easy solution, just fix it.
I would agree that the 404 should actually stay. People do pick up on it quickly and it's not actually that distracting or confusing, especially if you follow the rest of your tips. It just means that for those in the know it is much quicker to ascertain the problem.
I'm in two minds over the fact many different style of 404's will confuse people. I think it needs to be well done, or not done at all. If you have half arsed "Woops" page it will confuse people more than it helps. But if you have a well thought out page which places links etc. it is probably more helpful.
What's wrong with the IIS default 404?
As a tech writer for the IIS team, maybe I'm taking this too personal, but all those pages are MUCH better than ever before, and able to go toe-to-toe with the best error pages.
The IIS pages give you solid advice on what you should do to revover from the error, which in this case is pretty simple stuff: either fix a possible typo or you're out of luck. Some things just can't be made any better with a message. Case in point: the HTTP 404 error.
But back to the IIS 404 page. The exact http error designator (404) doesn't even appear until half way down the page, but it does appear and that's important.
Why? "HELLO?" Not everyone surfing the web is a total novice. Some of us actually want to know the name of the HTTP error code when we come across an error. On some of these 404 examples being held up as "good," I have to scan for 5 seconds before I even realize I've encountered an error. That's no good.
Finally the IIS page for 404 directly addresses an audience different than the average idiot: support personnel. Granted, it does seem a little lame to suggest these support professionals go to the MS.com site and search for 404, but what the hell: This is a template driven effort. In some cases, this section is going to be helpful to support people and the regular web surfers can disregard.
No way do the IIS default pages deserve this grief, but especially not from a dude who doesn't even practice what he preaches: http://codinghorror.com/404
you say that if you even include '404' on the page you have alrady failed. YOu need to let the geeks know what the page is. If I see '404' on the page, i don't even have to read the rest of the text to know what it means.
Automatically guess where they want to go?
I would consider this to be a really bad idea! Mainly due to the fact if you transparently cover for the users error, they may never find out they made an error and keep using the same link (even to bookmarking and forwarding to friends). From then on they are depending upon your guesswork logic to keep their viewing pleasure.
Normally we will redirect it back to main page
you might want to avoid the ad-bloated 404 page: a lots of flashy adds surrounding the whole screen, and a small sentence here, written using the most invisible font possiblen saying the page does not exists.
also, if your 404 page design looks like any other page on your site, avoid messing up the parts: dont put the "page not found" paragraph where there is a navigation bar and a search box on other pages (http://www.club-internet.fr/actualite_v5/fdsq).
please avoid the lame error message: normal users dont know anything about template engines (http://www.club-internet.fr/actualite_v5/fjdk.phtml)
and last, let the user realize he made an error: dont redirect him automatically to the home page. if for some reason the user is not looking at the page (opening a bunch of links from an article for example), he will be surprised not to find what he was looking for on the page when finally looking at it. you may also understand that some people are slower to find, identify and read informations from a page, so a 2 seconds redirection is a definitive no-no (http://www.lycos.fr/fdsq).
If you have a custom 404 page, please, please, please just show it, don't redirect to it, changing the URL shown in the user's address bar. Doing the latter makes it so much harder to fix typos.
My 404 does a ton of stuff. First I have a list of redirects to make (I restructured my website several years ago but some links are still published with old information - there's even one on a DVD somewhere). If the user comes in on one of those links, my 404 invisibly redirects to the right page. I use a redirect instead of a server rewrite because I used to have the redirected pages include a small yellow banner at the top that said something like "I've redirected you as best I can. Please note the new address. If this is not what you were looking for, then contact me." But nobody ever contacted me so I dumped it.
Secondly, any 404'd image gets a blank image delivered. I was considering an image that says "image removed" but went for blank instead. I know I had a particular reason at the time.
I also get an email for every 404, telling me where the user was going, where my 404 sent them, and the array of server variables so I can see the referer and remote host and whatever if I ever need them. The email will NOT be sent for: favicon.ico, robots.txt or blank.gif (because those would be hit all the freakin' time).
My 404's look also matches the rest of my website, so it has less of a "dead end" feel and more of a "whoops, wrong way" feel, but the only people who get an actual 404 page are coming in from mp3 search sites like dogpile, and I really don't like that my stuff gets catalogued in places like that (especially since I rotate my music), so perhaps it should just send people off into space.
Here's a sample redirect:
Something removed from a temp directory:
Other regular 404:
And for anyone who wants to go straight to the 404:
"Drop the 404"
No no no!
The average user who reports a fault is very bad at describing it. Without sensible information, you are going to have a hard time working out that the error is a 404 in the first place. Some users are even incapable of telling you that the problem is on a web page in the first place. You won't know to even look at your web server error logs.
Something that non-technical users do manage at least some of the time is to report codes that they do not understand verbatim.
Include 404 in your error message. Somewhere identifiable. For example, all your errors might always have "Error code: xxx" at the bottom. This way, when somebody reports an error you can ask for it and have some idea of what is happening.
The book "Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points" has great tips on how to create good 404 pages.
1. Drop the 404 (its just an error code)
I would keep the numbers '404' on the not found page. Waaay back dropping the 404 would have been a good idea. After all these years 404 has almost evolved into being a real word, not an error code.
Still, the not-found page should be crystal clear to Aunt May, and still have the 404 short hand for those who know what it means. So, 404 is ok to use, but never use 403 or 405 (what ever those are).
One of the more amusing 404 pages I've seen:
you didn't get the page you wanted, but you get something interesting.
I think apple's 404 page is great. A lot of normal people that view the site are even more incompetent then most webusers (think about it. Someone viewing your blog is bound to know more then average joe who wants a shiny mac).
The mac's 404 page gives you a ton of places to go from your dead end, and I think that's really what you want to do, especially if you're a company like apple (i.e. wants people to buy their stuff).
It seems to me that you're kind of driving toward an aesthetically pleasing before (but only slightly) usability.
But that's just what I think :-)
On a previous incarnation of www.att.com, I did a few things:
First, if there are any upper-case characters in the path, permanently redirect to an all lower-case link. (We always used lower-case as a rule.)
Otherwise, examine the referring link. If empty, it could be a typo or a bookmark that no longer exists (shudder). This is also where a spellcheck module would come in handy (see Des Traynor's earlier comment).
If it's an offsite link, explain that and suggest notifying the webmaster of that site. If it's an on-site link (d'oh!) then offer a simple one-button form to send a heads-up, which went into a queue. We did _not_ auto-send this, lest a bot or script begets a flood of emails! (In hindsight, I suppose we could have de-duped the feedback, but we had to be mindful of server resources too.) Using the form also gives the visitor a nice sense of participation.
To be sure, our web analytics and proactive link validation caught 404s too, but with so many links and domains, things can still fall through the cracks. Adding some smarts to the handler helped alert us to the low-hanging fruit in rapid fashion (the proverbial 80/20 rule).
One last thought: Keep the 404 handler (and others) nimble and lightweight, but packed with informational goodness. Have fun!
Error codes may not be useful for solving the problem, but in general most of the errors that have to fail hard with an error message are those that you couldn't handle, so it's doubtful the user could either. It's so much easier to google for an error code than for a message, especially when you can't copy-paste the text.
Now on the web that applies less so, but having some sort of "problem ID" in addition to the message *is* helpful.
"Unfortunately, I haven't had time to implement a better 404 page on my own website. Yet."
Don't do as I do...
Very nice article. However, there is a very important part of the 404 error code process that the author did not touch upon. Search engines (i.e. Google) view 404 pages very differently than they view normal web pages (200 OK). It is in extremely important with regards to your indexing that *all* of your 404 page returns a 404 error code and not a 200. If they do not, there is a possibility that you can end up with many pages "404" pages that are indexed causing you severe duplicate content issues (which can result in a severe penalty).
To be safe, I would verify this by checking a server header checking tool like the one at http://www.seoconsultants.com/tools/headers.asp.
Take for example everyone's favorite 404 page:
Great page.. very funny. Unfortunately, it does not return a 404. It returns a "HTTP/1.1 200 OK". If, for example, I had a bunch of pages that I link to that end up removed, they would all be indexed with this same exact content because Google would see them all as good 200 pages.
Long story short, 404 means page not found. If you customize it, make sure the bots, as well as your users, know that the page is still "not found".
I disagree with the assertion "drop the 404". There are two audiences for an error page, first the customer who gets it, and second the tech support guy who has to figure out why the customer got it. The main reason to show users error codes is to help tech support figure out what happened. Customer are notoriously bad at giving an accurate description of a problem, but they can generally pass along an error code verbatim.
Is there an IIS or Apache add-on that goes through server logs and reports 404s (and/or 500s)? Or does one just create a custom dynamic (aspx/jsp/php) 404 that logs stuff to a DB and sends an email if necessary?
Never thought about it, but I admit youre right. Except:
1. The number 404 should be on the page. It will not disturb the user but help advanced users and crawlers to recognize the error.
2. The 404 page shouldt be in simple english, but in simple whatever the websites language is. Better: bring it in the language of the user.
You think IE's default "friendly" error pages are a good idea? Aside from lumping together completely different errors (like, say, DNS error and connection timeout), they also make it impossible to troubleshoot a transient error.
User calls you to say they can't access a web app. You ask for the error message. After a few false starts, you figure out "friendly" error pages are on and walk the user through turning them off. User tries again and this time it works. There's nothing in the application log because the server blew up before hitting the app, and the server admin can't find any trace of the error in the event log, and thanks to IE's default "you're a moron" configuration, you've lost your chance to try to figure out what's happening.
I'll add my "me too" to the cries for leaving "404" on the error page. It's not just geeks who understand it -- a lot of users have been around long enough to recognize it explicitly, even though they'd be quite confused by some of these attempts at "user-friendly" 404 error pages.
there is the classic
Once upon a midnight dreary, while I websurfed, weak and weary,
...Over many a strange and spurious website of 'hot chicks galore',
...While I clicked my fav'rite bookmark, suddenly there came a warning,
...And my heart was filled with mourning, mourning for my dear amour.
..."'Tis not possible," I muttered, "give me back my cheap hardcore!" -
Quoth the server, "404".
Including the number 404 on the page serves one useful and important purpose - if a user complains to his local support staff, they can ask "What error did you get back" and 404's a lot more identifiable than "Oh, it was some page not found or failed or something message".
Putting the numbers 404 on the page doesn't necessarily complicate matters for the user - it's no more intrusive than a chapter or section number next to a heading, for example - but it does help support staff a lot.
Brilliant, thank you so much for an article which sorely needed to be written, so much so in face that after reading it, I went and followed 'most' of your advice. Check it out:
I'm so much happier now and my users (the one's that are always getting lost), can have a laugh, but also see what recently happened on the site, so hopefully a few will get pulled back into reading more. Great stuff.
I don't know...posting this before doing his own seems smart to me. He gets feedback on his suggestions now (such as removing the 404).
I have a personal dislike of rambling "funny" 404's. Fair enough, add some humour but please don't make me read a solid paragraph of "Oh you've lost your way have you?" to find out the problem was a 404/moved page.
Hey Mark, I didn't take your comments as harsh, altho they were a bit bluntly stated. Nonetheless, I appreciate the pointers. Sure enough, there were some glaring missteps errors that needed to be tended to:
* The tabs should look more like tabs now rather.
* The tooltip that appears when you hover over the Marketplace link has always advised that the link opens in another window. I'm working on a better (in-site) solution...
* 2Dolphins is purely a personal not-intended-to-turn-a-profit site. I've replaced the "Contact Us" tab/page with an "About" tab/page to provide a bit more description regarding the site its purpose.
I always wanted to have a cool 404 page and finally put one up on my site.
Ok, it's not that useful but some people find it fun amusing and it's hit on purpose quite often. Eventually I will come up with an idea for a 'prize' to award the user for winning.
* Don't drop the "404 Error". It should be prominent in the page text near the top so that users understand they have reached an error page and can take appropriate action. Most users that spend any time on the web at least understand this error message.
* Don't redirect the user unless you know for sure what page they were trying to reach (i.e. casing issue, htm vs. html, site reorganization, etc.) The user needs to be able to fix the URL.
* By all means offer the additional information if you want, but the page should not look like the rest of the site... it should look like an error page so that the user or linking website will fix their mistake!
* Offer links to Google Cache and the Wayback machine in case the page has actually been moved or removed.
Well, me problem is this, lads: I don't host my own domains (the wife doesn't want that much computer hardware in the house), so how am I supposed to provide custom 404's?
It's great to have a helpful error message, but I think we really need to examine the root of the problem: URLS are being used to pages that don't exist. There are only two reasons why this can happen:
1a. User made a typo entering the URL manually
1b. Someone made a typo when writing an a href=... element in an HTML page.
2. You used to have a page at that URL but deleted or moved it.
The only way to address 1a. is to provide some helpful suggestions to the user on fixing his typo or finding the page he really meant.
The only way to address 1b. is to fundamentally change HTML and HTTP, or for every web author to use tools that automatically do their links for them.
But, 2. is unexusable. Once a URL exists, it should Never Ever go away, except for a good reason-- and then, ideally all references to it would also be disabled; or the URL would still resolve, it would just go to a page explaining why the old page is gone, or redirects automatically (see Jeff's previous entries about URL rewriting for the best way to do this).
Remember, a URL does *not* point to a "file" on your webserver- it is an identifier for a document that will be sent to the user's browser. That those documents happen to be in files that are in directories, and might have some kind of filename extension like ".html" or ".htm" are implementation details that should be hidden.
"Is there an IIS or Apache add-on that goes through server logs and reports 404s (and/or 500s)? "
Yup. "grep" :)
And any kind of web logs analysis software really ought to have it too. This includes Google Webmaster tools and/or Google analytics, I think.
Whatever you do, don't drop the HTTP 404 header response code!. Even if you don't want your users to see it (with which I disagree to, although not as strongly), please let the poor robots notice that this page is an error, so that they can remove the invalid URL from their indices and such. The so-called "soft 404s" are the bane of the HTTP ecosystem.
The 404 page at www.homestarrunner.com, mentioned above, is one of my favorites.
Maybe not user friendly in the typical sense, but it's got several things going for it. It's obvious, it explains the problem, it's not overly technical, and while not aesthetically pleasing in the traditional sense the whole thing is one big awesome fan-service.
As for getting it indexed because it returns 200 OK... I'm sure the Brothers Chaps aren't too broken up about it. It's not just a "page not found" error message. It's another piece of comedy and fan-service they've authored.
I hate to say it, but I love it when a website just sends you to the main .com instead of even showing the error, 99% of the time you're one or two clicks away from what you meant to type the first time.
I may have stated my position a little too unequivocally. It's fair to have the error code in the message somewhere, as long as it's not the focus of the message.
The IE7 "friendly" error page is a good example of this-- see the little HTTP 404 in the upper right-hand corner of the screenshot?
Don't forget that it's better if your 404-error page actually returns the 404-error code in the HTTP header, might be useful (for Google Analytics and other stats services for instance). If you want to check this, you can use this site: http://www.rexswain.com/httpview.html among others.
Great article by the way!
@Reed: You forgot the third reason for 404s. Intentional exploration to find hidden pages (URL-hacking). For these, you definitely don't want to help the user along and perform expensive searches.
I cant believe no-one mentioned the language issues yet
404 works in any language, even if someones reading the page through google translate
"@Reed: You forgot the third reason for 404s. Intentional exploration to find hidden pages (URL-hacking). For these, you definitely don't want to help the user along and perform expensive searches."
Yes, thank you, I'd forgotten about that. In effect, though, it ends up being the same as 1. I wasn't proposing doing an automatic search for every nonexistent URL, but it could be an option on the custom 404 page.
Spidering, though, is another issue. We can detect antisocial spidering by putting a script in robots.txt, and then blacklisting any sites that access it regardless.
Anyway, the primary problem remains that we don't use good URLs and it's too easy to break URLs already in use simply by renaming or moving files on the webserver or switching to a new CMS system.
Babar K. Zafar is the kinda of guy who buys a new dictionary, and the first thing he does is look up the word dictionary.
If rule #1 is to NOT include the characters 404 on the 404 page, how can your recommend useit.com's 404 page?
I actually disagree with your idea about not printing "404" on the error page. Almost every "good" article that you link to as well as the title of your own blog calls these pages "404 pages". Why? Because that's what WE know them as.
I'm all for "friendly" error pages, but for God's sake, embed some hidden text in there (or maybe put it in the page's footer) saying that this is a 404 error. It's always nice (for developers and other non-nontechnical people) to know exactly what the error is. I'll admit, this isn't SO important for 404's, but for 401's it's critical. 401.1 and 401.2 are worlds apart in when it comes to trying to debug authentication woes.
I find it ironic that codinghorror.com finds the information in this article infomational enough to post on their site, but they don't find it informational enough to take its direction. Go to http://codinghorror.com/asdfkljahpqwhadf.htm. They use one of the 404 pages that was recommended to not be used.
http://www.gudmagazine.com/codinghorror_404 -- maybe "File not Found" is too much the center of the message, still? But I think it's good to let the user know up front and unequivicably that the page they got is NOT the page they were looking for. My "standard" for corporate sites is to just reuse the "sitemap" page, with a little extra information. One thing I'd like to have that's missing is a search bar. Some day? Maybe after this post. ;)
Interesting to know what the history behind the 404 error code is:
(Give it 5 seconds to load the page instead of the error code displayed)
Something to consider about automatically redirecting: I open lots of links in other tabs as I read. By the time I get to the other tabs, I often don't remember where I opened the tabs from. If something is redirected and the original URL isn't showing in the address bar, I have basically no chance to figure out where I was trying to go.
I finally put up the 404 page for this site, so we can lay that criticism to rest. :P
Hi Jeff - I have a question, maybe someone will know the answer.
I moved hosts in January, after completely redesigning my site and changing the structure from .html pages to Wordpress.
The problem is that months later I am still getting tons of 404 hits for pages and files that no longer exist on the new version of my site. My host, Media Temple, is typically great, however I am getting dinged in for using resources when these attempts to access these long gone files are accessed. I have created an .htaccess file to prevent hotlinking. I've created a lite custom 404 page. Is there anything else I can do?
Thanks for reading.
Hey Jeff, your 404 doesn't seem to be kicking in...
It looks fine.
I just made 404 page and it works fine,
I think some people are missing the point when it comes to custom 404 pages.
First, let's look at why they come up. They come up because someone or something called for a page that simply cannot be loaded for some reason. This may have been accidental, or intentional. They may not even truly be generated by a person.
So first thing would be to look at the type of site you offer, then at the type of traffic you are trying to generate. If you are running a simply one page site, that gets 1 hit a month, then worrying about 404 pages should not be a concern.
If however you are running a 1000 page site, generating $10,000 a week in revenue, and millios of visits a year, then make sure that your 404 pages are both of high quality and informative to your target audience.
This does not mean that it has to be a sales page, or redirect to another page, or that it should not contain an error message. The best options might be to include a little of both. Heck, even make then useful. Include an error message stating the page they were looking for was not found, offer a handful of suggestion or a sitemap, and give them some valuable info about your company or products.
The 404 is still a page on your website. If you put forth the effort to make every other page look so good, then you should concentrate some time to making your 404 both informative to your visitor, and useful to you as the provider. Try to shoot for the best of both world.
useit's 404 page is a joke. classic example of function overpowering form. 1976 is better but not best. just because it meets all the criteria does not make it the best.