13

Most error pages on websites display http status codes in messages. Eg - "404 Not Found"

Is that status code really helpful for a user?

enter image description here

A previous question asked Are HTTP error codes user-friendly?. However, that question refers to a default error page for a web server. Here, I am asking about error pages that are designed by web a designer/developer in a production site.

Improve this question
3
  • 1
    @DA01 I don't think so: This question is about showing the code, that one is about showing a 404 document altogether.
    – Darkhogg
    May 23, 2014 at 16:50
  • 5
    Status codes have the major advantage of being language-independent and not needing translation.
    – keshlam
    May 24, 2014 at 0:41
  • So the 404 was not found? Then what am I looking at?
    – user
    May 24, 2014 at 19:30

8 Answers 8

Reset to default
16

404 and 500 are most common error codes and 404 is the most famous one. If your target audience have exposure to computer as educational basis or a mid level surfer he/she will understand as what 404 means and not much of other status codes. Still it is not a good practice to display error codes as only or prominent way of communicating technical problem/status to user. You can display the status code with less weight in the screen which is not prominent than the user friendly status message, so that the user can quote it to explain to the support executive of your website.

Improve this answer
11
  • 10
    Speaking as a former technical support person turned web developer/designer, the status codes really help! Some people write the entire error code on a piece of paper before they call support. Better to hear "I have this thing on the screen that is a 404 error" as opposed to "IT'S NOT WORKING".
    – Daryll Santos
    May 23, 2014 at 13:03
  • 4
    I disagree @corsiKa - because most "real world" applications have custom error codes, they don't just pop up the system default error code (or message). This way, when it comes to troubleshooting the error is easier to resolve because the code has special meaning for technical support. Hackers knowing you custom error codes and messages will not help them.
    – Burhan Khalid
    May 23, 2014 at 16:02
  • 9
    The HTTP error code will not give information to a hacker about systems and libraries on the server. Providing excessive information on the error page might, and certainly should be avoided, but 404 and 500 give no such information.
    – Dancrumb
    May 23, 2014 at 16:58
  • 7
    I'd like to point out these codes come from the web server as part of the HTTP request. Any hacker worth their salt could easily get the HTTP status code, even if it's not displayed on the page.
    – Jimmy Thompson
    May 23, 2014 at 22:46
  • 1
    It may not always be so obvious though. For example, the GitHub API, on receiving a request for a private repository, returns a "page not found" error instead of a "permission denied" error, because the latter would certify that the private repository exists. You have to be careful in these situations.
    – wchargin
    May 24, 2014 at 2:59
12

Error information should be tailored to the audience that needs to take action on the error.

  • If it is the user, the user needs to get a user-friendly or at least user-understandable accounting of what the error is and what is expected of him. Nobody would expect ALL users to know what "404" means.
  • If it is the systems administrator, or the network people, or anyone responsible for the infrastructure, an error code like "404" is precise, concise, and unambiguous. Here the expectation is the opposite, namely that the exact code "404" (and not say "410" which is the status "gone" and is different from the status "not found") is useful.

The problem is that 404 is in a grey area. 404 is not produced by the site, it is produced by the web server. Developers and systems administrators need this information, so showing it is crucial. However users might also get such a page if they enter a wrong address, so including a user-friendly explanation is also important. That's why most commercial websites who target users from the public at large will include both.

Improve this answer
11
  • 1
    +1 for mentioning how to mix easy-to-use and precise+concise for different users, but honestly your example ("404.1") confuses me a bit.
    – Alex P
    May 23, 2014 at 13:01
  • 1
    @AlexP I checked the spec and you are right, the codes are all integers. I've updated my answer based on your feedback.
    – Mishax
    May 23, 2014 at 13:19
  • 7
    404 does not mean "there is no site": it means "the page you asked for doesn't exist." That's precisely why 404 is useful: it's clear and unambiguous, rather than somebody's inaccurate attempt to describe what the problem was.
    – David Richerby
    May 23, 2014 at 13:42
  • @DavidRicherby You are right, that sentence from my answer was not well formulated. I've updated the answer based on your feedback.
    – Mishax
    May 23, 2014 at 13:58
  • 2
    Who says 404 is produced by the server rather than the site? Lots of sites will produce their own 404s, especially ones that use a lot of SEO slugs or have REST APIs or other complex routing rules. /products/hammers may be a valid page whereas /products/kittens may not. Only the site/application knows this, the underlying server infrastructure has no idea. It seems irrelevant regardless; every possible error is important to system administrators, and every possible error should probably result in a page that isn't a dead-end for users.
    – Aaronaught
    May 24, 2014 at 0:33
4

Like others have stated. There's nothing wrong with a 404 since it's practically common knowledge. It refers to a page not found.

Though you shouldn't show the default 404 page to a user, but rather design your own. And specifically add the text 'Page not found, so it's obvious for any users that are ahem not from this planet.

Great example: http://gchen.cn/blog/2014/09/01/blog-recover

EDIT:

404

Improve this answer
3

Generally, no, status codes are not the best thing to display to an end user. However, 404 entered the vernacular a long time ago, before such best practices were common, and enough people learned it that it's managed to stick around.

Improve this answer
8
  • 3
    I frequently see a 500 error presented as simply "Internal Error", without any mention of the "500". I regard that as poor practice, because people have a tendency to rephrase or misremember error messages, sometimes turning them into something else! (a different error message). A numeric code is much less likely to mutate when someone is reporting an error.
    – Phil Perry
    May 23, 2014 at 14:58
  • @PhilPerry, Not that "hey you got a 500 error" is especially useful... =/
    – Brian S
    May 23, 2014 at 15:06
  • 1
    "hey you got a 500 error" would not be useful. "You have a 500 (Internal Server) error" would be useful, which is what I was calling for. A user may muck up the text of the message, but is unlikely to turn 500 into 404. It's a bit of redundancy for a noisy communications channel.
    – Phil Perry
    May 23, 2014 at 15:35
  • 1
    While we're chatting about this, I've got to mention my pet peeve about the (default?) Apache setup. If you don't have a custom error page for a given error, Apache reports not only the (default message) for the error, but also a 404 for the "missing" error page. I see an incredible number of reports titled "I'm getting a 404 error" which upon deeper digging, turn out to be other errors. 500 errors where no number is given are especially bad, as people often leave out all mention of "Internal server error".
    – Phil Perry
    May 23, 2014 at 15:39
  • @PhilPerry: Actually, why is a message like "You have a 500 (Internal Server) error" more useful than "You have a 500 error" (assuming in both cases that users correctly interpret the 500 as the error code, or rephrasing the sentences to make that clearer)? Wouldn't users rather be put off by the "technical jargon" ("internal server")? If chances are that part of the message is going to be misremembered and the error code is everything support needs to know, why is the error code name necessary, as well?
    – O. R. Mapper
    May 24, 2014 at 17:23
2

I know this is going against the advice of other commenter's for this question, but I'd strongly advise against showing any stack, trace or other diagnostic messages on an error page. This is known as "information leakage" - to a regular user of the site the best thing you can say about it is that its little more than clutter on the page, at worst it's a source of confusion. More importantly this information can be used by a potential attacker to hack your site.

This sort of information is worth recording, a log file is probably the best place for it.

Improve this answer
8
  • 5
    So are you saying showing the 404 code is information leakage or are you referring to the actual debug info that some people forget to suppress? I don't think showing the error code would be considered information leakage. Google does it: google.com/foo.
    – Code Maverick
    May 23, 2014 at 14:17
  • 2
    @CodeMaverick, I don't think a HTML error code would constitute the same level of information leakage as - say - a stack trace. In Rails, Sinatra and Django applications you can get a complete stack trace of the issue, with code snippets, if you leave debug enabled. It's this kind of information that is being referred to in this answer.
    – Jimmy Thompson
    May 23, 2014 at 14:32
  • 2
    @JimmyThompson - I agree, I was just wanting Stormcloud to clarify.
    – Code Maverick
    May 23, 2014 at 14:38
  • So how much information is too much (of more value to a hacker than to diagnosing the problem)? I would think you would need (in addition to HTTP status/error code, and message) the full URL. Anything else? Is it practical to try to log any additional diagnostic information (especially if there are numerous errors, or the database is down, or the filesystem is full, or ...)?
    – Phil Perry
    May 23, 2014 at 15:03
  • @PhilPerry That kind of diagnostic information sounds like it's best logged to the server, not shown to the user.
    – Jimmy Thompson
    May 23, 2014 at 22:44
2

Many sites pay special attention on "code 404". Instead of boring messages, it is very refreshing for users to see some creative, witty page, like this error 404 on car sale website that displays celebrated Peugeot 404.

error 404 on car sale website

Improve this answer
0

For webapps and internal sites, I usually prefer to show both, a proper translation, which explains the error and possibly provides additional guidance, and the status or error codes plus additional details like stack traces.

This is especially true, if the set of codes is limited, because in those cases, there tend to be not just short messages, but properly translated pages for all status and error codes. The problem with those, however, is that translations are often not quite to the point, especially for technical, support or admin personnel, who actually form a second grouo of target users for status and error pages. Translations are often abbreviating or short-circuiting things slightly, which tends to confuse techies not accustomed to the message. For them, an actual code is very clear and typically undisputable.

That's why I prefer to show both, albeit the more technical codes in smaller print with additional details typically only visible on demand.

Improve this answer
0

Error pages are a real nuisance in the gluteus maximus, butt you most certainly can use them to your advantage.

Don't do this:

enter image description here

Your beautifully crafted design and UX flow destroyed in mere milliseconds.

Instead, you could do this:

  • Design error pages for the most common errors (404, 500, 403, ..?)
  • Provide a short and simple description of what went wrong
  • Add a 'back to previous page' button/link
  • Add a search bar
  • Add a sitemap
  • Display random pictures of kittens

All in all, let your users know something went wrong and then help them to fix it.

Improve this answer
2
  • 6
    OP is asking why we show the error code. Not about showing a themed page or not.
    – AKS
    May 23, 2014 at 11:31
  • 7
    Obviously, your server should be able to handle code 418 I'm a Teapot
    – Brian S
    May 23, 2014 at 15:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.