We've seen a lot of beautiful custom error pages for server errors such as 404 and 503, but it seems like each site or app has just has one for whatever page you cannot reach.

Is it in anyway helpful to users if we have another level of customisation for 404 pages that are specific to the type of event.

So for a meetings service, is it worth having a - 404 for meeting not found - 404 for recording not found - 404 for attached document not found

I am wondering whether if we made such pages, can we reduce the friction for the user to find a solution? Would people read and be benefitted from this?

  • 6
    At the point where you have multiple 404 pages, you might end up needing a 404 page for when the correct 404 page isn't found. "40404 Error: Couldn't find the page you were looking for. Or the page you weren't looking for."
    – aslum
    Jan 21, 2015 at 17:34
  • 3
    If you think you need multiple 404 pages, then maybe you need to think about redesigning the site? Or, there might be a more appropriate error code. Also, perhaps use analytics to see what people are looking for?
    – Anonsage
    Jan 22, 2015 at 0:37
  • A single dynamic 404 page would be a better idea than multiple ones, so you could use a server-side language to figure out what to show the user. but how could you divine what they were actually looking for? the only time you could be certain is when it's a request that was sent by the webapp, not by the user, who could mistype a URL. for instance clicking the "Join Meeting" button.
    – jammypeach
    Jan 22, 2015 at 14:24
  • How did the user get a bad URL? If you created it, don't. If the user asked for customer 27 when there are only 24, you failed to do your job of input verification. In this case you SHOULD NOT give them a bad URL but display an error message and allow them to try again.
    – msw
    Jan 22, 2015 at 16:29

7 Answers 7


Treat a 404 page like an error message, which it basically is. A good error message offers the users way to overcome the problem. In your example, a 404 for meetings could offer possible matches for meetings, a 404 for recordings could offer recordings, and the same for documents. The possible solutions are different for each type of entity, and the reasons for the mistake could also be different - e.g. a meeting can be outdated, but a recording can't. So yes, it would be helpful to have specific 404 pages, as long as they offer real solutions and not just say "Ooops, the page that you were trying to reach doesn't exist".

  • 11
    This is rather outdated thinking. If I follow a link to specific content and it is not there then the chance of finding the specific content that I wanted in a search is very low and putting the user into a loop between search and 404 is not useful. Don't link to things that don't exist, use permanent links that will never have to move, if something is cancelled or deleted confirm to the user that it has been so they can stop searching rather then send them to a 404.
    – JamesRyan
    Jan 21, 2015 at 11:31
  • I highly agree with @JamesRyan. It seems redundant and stressful for the user to stumble on "I didn't find anything" when in fact it is: "I did, but it's just not there and I didn't know."
    – UXerUIer
    Jan 21, 2015 at 15:09
  • 1
    @JamesRyan Outdated or not, it's a fact that 404 pages exist. The question wasn't whether they should be used - I agree that it's best to avoid them whenever possible. The question was how to use them, as long as they are already being used. Also, your assumption about the uselessness of search is unwarranted in many cases, especially in the case of webapps, which is what the OP explicitly asked about. And I actually never mentioned search :). Jan 21, 2015 at 16:46
  • @VitalyMijiritsky I did not say search is useless, I said it is not helpful at that late stage. The fact is in a webapp you should never end up at a 404 page.
    – JamesRyan
    Jan 21, 2015 at 16:50
  • 1
    I guess we have different definitions of "fact" then :). gmail.com/lkjhlkj, facebook.com/lkuhkl. Jan 21, 2015 at 16:56

The first problem with having multiple 404 pages, each dedicated to a particular area is that you assume users were in the right part of the website at the point when they fell on to the 404.

Bearing in mind that many links come from search engines and not necessarily from within the website, then I don't think you can guarantee that a dedicated 404 is always going to be the most helpful option for all users.

The second problem with multiple 404's is you are immediately increasing or duplicating the number of places you need to keep up to date or maintain. At some point you'll almost certainly have to decide that you'll have dedicated 404's about specific topics A, B, C, but have a generic 404 for 'everything else' and this generic 404 should probably include topics A,B,C anyway!

Apple's take on the 404 groups the possible forward options into the same group structure as the top level navigational structure.

So yes you come to one page, whatever the location that the error happened. But that's ok because it's easy to see links related to the section you were in, or wanted to be in. You can also easily see what the other sections are about in case this helps give a higher level picture.

In fact - Apple's 404 is so helpful, I'm almost tempted to bookmark it and deliberately go to Apple's 404 page in order to kick start my way around the site! It's not as long or detailed as their sitemap but is (in my opinion) easier than browsing via their top menus which aren't drop downs.

enter image description here

EDIT: Compare Apple with Bloomberg's 404 for example, which totally puts a lot of effort concentrated on the absolute wrong thing to display. It's animated so you have to see it to believe it. Weird!

enter image description here

  • Roger, touche :) Jan 21, 2015 at 11:00
  • 1
    A specific message on the 404 page would be very helpful in cases in which content was removed or expired. In those cases you might want to consider a "410 Gone" status instead of 404 though. Jan 21, 2015 at 14:56
  • @StephenOstermiller The average user will just about know what 404 means. So, yes, use a 410 Gone response, but as far as the UI goes, simply state that the content has been deleted, and don't bother the user with 'magic' numbers like 410. If similar content is helpful, do display this, but generally this is not the case
    – Sanchises
    Jan 21, 2015 at 20:14
  • 1
    The status code matters for non-human visitors such as search engine bots. Google for example expunges 410 gone pages more quickly than 404 pages which makes it less likely that users would get to such pages. The magic numbers do matter. Jan 21, 2015 at 21:05
  • A better URL would be apple.com/404 to go to the 404 page on the apple website. This really states that you want the 404 page and not 'itues'. With enough visits, they may redirect 'itues' to 'itunes' and you are left without your precious 404 page. Jan 22, 2015 at 10:04

I designed a 404 page sometime back with a function you might find interesting. it was using a recommendation engine module suggesting products the user might like and what they previously viewed. not sure what kind of website you are asking this in context to, but a golden rule i stick to is never to bring the user to a dead end.


I'm going to answer this from the perspective of a webmaster who is familiar with the error codes that your web app should produce.

A 404 Not found error is a very general error for the case when a URL was entered that cannot be parsed. You may not know what area of the site the user was looking for. There may even be nonsense in the URL like /xyszes/thau. Were they looking for a meeting? Who knows. At the very least you need some generic 404 page for the case in which your server can't make heads or tails of the URL.

A 410 Gone is a page that I often customize for different content types. When you remove a meeting, you should return a 410 status with a custom message like This meeting was yesterday, click here to schedule a new meeting.

For URLs that are almost correct, you should use a 301 Moved Permanantly status to take the user directly to the correct page. You might want to take advantage of modules like mod_speling (sic) that can correct misspelled URLs. You should also implement redirects manually for pages or sections of your website that have actually moved to a new URL. I find it useful to implement a custom 404 script that tries the words from the URL in site search and then redirects to the first result if there is one.


I agree with Vitaly, the 404 page shouldn't be an end to the users route it should give them help on why this page might not be here and relevent ways to procceed.

In your example, suggesting things like "Is this the meeting you are looking for?" then listing relevent results helps the using keep moving forward rather than backtracking


I think the simplest answer is how much time are you willing to devote to this one portion of your website? The second question is about the clientele that you're serving. The answer to those two questions will be a starting point. If you have lots of time and your clientele is not savvy then do separate pages. If your time is short and your clientele is savvy then leave it basic.



It can be a security risk to do so, and for the example you give isn't really appropriate anyway.

If I try to find a particular meeting - even from a direct link - and it doesn't exist, why throw an error in my face? I'd much prefer a site that displayed a basic "This meeting doesn't exist" message, and then displayed a list of other meetings, for example.

In this manner you can treat it exactly like a search - if a user searched for something that didn't exist, you certainly wouldn't want to render a 404! So I would suggest one of two search-based pages instead:

  • Treat it like an empty search with a short "not found" error message: list all available meetings|recordings|documents as applicable
  • Treat it like a very specific search: instead of showing a single meeting|recording|document page, use your existing search to enter the title given in the URL, which will presumably result in the standard 'no results found' message
  • 2
    You say no" but then the error message you propose is actually specific to meeting as opposed to other types. I think you mean "yes", but be careful what you put on those pages. Jan 21, 2015 at 14:37
  • @Stephen - I say no to 404. Propose specific non-404 message rather than failing ungracefully with a server error.
    – OJFord
    Jan 21, 2015 at 14:52
  • 3
    You also contradict yourself by saying something like 'don't show a 404 error - show a "not found" error instead'. That's exactly what the 404 error is for. If you are saying you should not use http codes when appropriate, that is bad advice. Whether you should actually display the error code or not is a totally different matter, if that is what you meant.
    – kapex
    Jan 21, 2015 at 14:55
  • 1
    @OllieFord Ok, for an empty search result an http error code would not be right. But then I don't really see why clicking a link should be treated as some kind of search in the first place. The user tries to get a resource identified by a particular url - when that resource is missing, a 404 "not found" is a appropriate response. Responding with no error code could mess with search engine crawlers and hurt seo. Adding some kind of search result when visiting a dead link is not mutually exclusive with using correct error codes though. You can respond with 404 and show a search result.
    – kapex
    Jan 21, 2015 at 15:27
  • 4
    As a software developer, anything other than a 404 error when a page isn't found is absolutely fatal. You are thinking from the point of view of a web server; there are many other applications. Playing games with standard error codes makes people want to kill the person who designed this.
    – gnasher729
    Jan 21, 2015 at 18:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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