9

In my website, if a user accesses an invalid URL, they are shown a custom 404 page. But now I'm questioning the value of this? It would be very easy for me to (instead of showing a 404 page) redirect them back to the home page and display an error message saying something like:

the page you requested could not be found

is this a better approach from the POV of usability?

  • What happens when they can't reach the homepage? – CJF May 22 '14 at 14:24
  • @CJFranken if they try to access any valid URL on my domain I can intercept the request and send them back to the homepage – Dónal May 22 '14 at 17:17
  • 2
    On my company's store site, a request for a missing page "mysite.com/widget-xyz" will redirect the user to a search for products related to "widgets" and "xyz". If the homepage is missing or down, they get a real 404 – David Wilkins May 22 '14 at 18:21
11

A 404 tells the user the page he requested doesn't exist. This is useful information for the user. Maybe he just made a typo and he has a clear expectation of the page he should get. Displaying the homepage instead, with or without error, could confuse the user.

However, I do agree that the standard 404 page doesn't add much value. A solution could be a custom 404-page. In this page you can display a link to the homepage or other interesting parts of your site (how do you know the home is the proper page). If you want to make it really advanced you could even consider to use parts of the URL as a search query and display the results on the 404-page.

4

I don't think it is. A user would want to know what is happening and why he is send back to the homepage. Since this way he might miss the display message completely and it would only leave him frustrated. More on confused users after redirecting here.

There is an article on uxbooth that goes more in depth on 404 pages.

4

Note that a 404 error is first and foremost an HTTP response code: http://en.wikipedia.org/wiki/HTTP_404

It's primary purpose is to communicate to the web browser (or web bot or what have you) that "hey, the server is working, but I can't find what you are looking for"

This is actually really important in a lot of situations. For instance, googlebot might get a 404 and then realize that content is no longer available, and then remove it from Google's servers.

So, indirectly, the server message is a pretty important UX feature.

Redirecting automatically can interfere with the purpose of the 404. You could, in theory, pause a bit, then redirect, but I don't know that the end-user gains a whole lot there. You could just as easily provide a link to the home page on the 404 and then the user, at their discretion, can decide if they need to update something on their end before heading to your home page.

2

There is more to the 404 page than just displaying to the user that it cannot be found. For example if they incorrectly input the web address you're going to need a 404 page there and you may not even be the one to set it up. As for your own navigation within your site you can do whatever you want to make it more user friendly. I like your idea of re-directing them back to your homepage with an error as it would make it a better more positive user experience.

By having them re-route to your homepage you can appear more in control to the user and they will hopefully have a more friendly experience with your non-existant page rather than getting a giant error page. Here is a website that offers good information on the 404 page and even speaks about other options 404 Page Best Practices. Just some suggestions hope this helps.

2

To add to Ruudt's response. Apple's website does a good job of enriching their 404 page by providing a sitemap style directory of links that the user may find useful.

Apple's 404 page

1

In my website, if a user accesses an invalid URL, they are shown a 404 page. But now I'm questioning the value of this? It would be very easy for me to (instead of showing a 404 page) redirect them back to the home page and display an error message saying something like:

the page you requested could not be found

is this a better approach from the POV of usability?

Actually, it is quite a horrible idea. What happens when the 404 is because the homepage is missing? You don't think that can happen? Well, it does. It shouldn't, but then again, in complex systems, snafus do happen. Something as simple as 404 handling should not throw users into an infinite HTTP 30X redirect loop.

The approach you suggested also requires the following:

  1. Having to code some intelligence into the home page to detect if it is coming off a 404 event.

  2. Implementing logic in your HTTP server (which might be distinct from your application engine if you have one) that "traps" a HTTP 404 and converts it into a HTTP 30X redirect.

    2.1 This implies that the HTTP 30X redirection needs to be parameterized with the missing URL that cause the 404 in the first place. How do you pass this? Via GET parameters, via POST parameters? Cookies? Vulcan mind meld? Some other mechanism that might be browser-dependent?

    2.2 And what happens to the original HTTP code? The user's browser actually uses those codes to track errors. We are replacing a HTTP 404 into a, say, HTTP 303, which when delivered successfully (when it does), gets replaced with a HTTP 200. For what?

That is an awful lot of unnecessary crap to replace what should be a custom static "404" page. A lot of unnecessary logic just to reduce the number of clicks a user needs to make (by one) when it goes to a missing/non-existing URL.

There is a lot more to web design (and development in general) than "usability". And there is more to usability than reducing the number of clicks IMO.

Follow standard practices (they are there for Darwinian reason, most of the time) IMO.

  • 1
    If the website is online it is inconceivable that the homepage would be missing. Also, you've wildly exaggerated how complex it would be for me to replace the 404 page with a redirect to the homepage that shows a message. I would basically just replace the one line of code that redirects them to the custom 404 page with 2 lines of code - one of which would add a message to the session and the the other would redirect them to the homepage – Dónal May 22 '14 at 22:35
  • If the website is online it is inconceivable that the homepage would be missing - unless the person in charge of deploying it makes a mistake. Say, your root index.html has a redirect to actual_home.html, and you test it and all goes well. But then either you or someone in your organization changes with root access accidentally changes your http server configuration to automatically assume any URL that ends with a /, say x/ gets resolved to x/index.htm instead of x/index.html. Then, bang, 404. Happens. All. The. Time. – luis.espinal May 23 '14 at 13:19
  • In my particular case, none of those scenarios are possible. The website is deployed as a single .war file, so either the whole website is deployed, or none of it is. Also there's nobody in the organisation with root access other than me. Finally, there is no HTTP server to configure, the app is deployed to a servlet container (Tomcat). – Dónal May 25 '14 at 13:35
  • In that case, and there will never be anyone else having to take care of it, go at it. But it still does not make any sense technically speaking. Standards exist for how to implement such things because 1) they work predictably, and 2) they form a common lingo that everyone understands. Now, you mention it is a single .war, so I'm assuming that users directly sending HTTP requests to the container directly (yuck) instead of passing them through a HTTP server (like Apache or ngix). If that ever changes, an accidental config change on the HTTP server would invalidate your pre-conditions. – luis.espinal May 27 '14 at 13:21
  • 1
    Think of it like this: I'm writing a document for internal use with myself and the sole audience. And then I decide to write "green" to refer to "red" and "red" to "green". It will make sense to me when I read it. It will not to someone else, and the change does not add any extra value worth considering. Same here with your changes on how to handle 404's. To each his own, so whatever works for you. You are asking if yours is a better approach, AND NO ONE has said yes. That should be a clue. Anything else is rationalization of a bad idea IMO. Good luck with whatever you try. – luis.espinal May 27 '14 at 13:26
0

The main purpose of a "hyperlink" is to allow the user the ability to move from one link to another. When a user clicks on a link, they are expecting to be taken to another page. The user experience in your scenario is someone on the home page looking to go to faqs or something similar, but what it ends up feeling like is a page refresh, and a message popping up saying that the page couldn't be found.

The issue is how you're going to let the user know through this "popup"? A message popping up could take up valuable screen space or detract from the aesthetics of the graphic design. I've encountered your solution a few times and all of them had a bright, off color that completely took away from the graphic design of the website. A real pop-up could be annoying. So, an easy solution is to lead to a 404 page which tells the user that the page they were traveling to is actually broken, so the next clear step is to take a step backward. Plus, a lot of these 404 pages are very playful in manner, which helps with branding/image/reputation of the company. IIRC, back in the day Youtube (and more currently, Mailchimp) showed a page that was like, "Oops, the page you were looking is broken, but a team of monkeys are about to go bananas on it and get it back up for you!"

I understand where you're coming from, and have seen what you're suggesting in practice before but in my experience it's slightly more annoying to see a page "refresh" and totally off-color bar (since you have to really work to get the user's attention) at the top telling me the page I was looking for is broken.

Hope that helps explain the industry standard a little more! :)

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