Make error pages an opportunity to help your users

I am planning a road-trip this weekend to see family in the midwest. My normal route is to drive to western Pennsylvania or possibly the Cleveland, Ohio area and stay overnight at a Red Roof Inn. Two reasons: first, they allow pets (in my case, a fluffball back seat driver named Frisket); second: they (usually) have T-Mobile wifi throughout the buildings.

So, I go to the website and plug in "Erie, PA" in the site search. And receive a 1 line error message, which I unfortunately for this post did not copy. The text was simple: This service is temporarily unavailable, followed by a 20-30 character identifier string, meaningless to anyone other than the technology team behind

More surfing around the site, this time attempting to get to a phone number, more errors. It appeared that anything which touched their ASP server was broken.

Each error message had a slightly different identifier number. This is probably incredibly useful to the technology team, but again not at all useful to the general consumer.

The failure to configure an appropriate, consumer focussed error message is a missed opportunity to placate a site's consumers.

Most web servers in the modern era (let's say, post NCSA 1.3) allow you to configure site-wide error message pages. Apache allows you to configure error pages on a directory by directory basis (using the ErrorDocument directive in a .htaccess file). If your site is hosted on a shared server you should be able to configure your own error message pages (if not, you should consider another web hosting provider).

For Apache, the directive is simple:

ErrorDocument code relative path to file

For example, on a site I run, I have the following in the .htaccess for the site (I used a shared server):

ErrorDocument 401 /lib/http/401.html ErrorDocument 403 /lib/http/403.html ErrorDocument 404 /lib/http/404.html ErrorDocument 500 /lib/http/500.html

I don't have messages for all possible error codes (I believe that technically you can replace the default "error" page for a 301 and 302 redirect code, but then you have to handle adding in the URL to redirect to in the body of the page). But these are the most common errors on the site (unfortunately, fat thumb syndrome tends to cause a number of "500" errors).

The most common error is a 404 error page, File Not Found. Rather than just tell the consumer that the file wasn't there, you can use the error page to give other options, include your site navigation, or even run a script to return other possible pages.

Now, I don't actually recommend the script option unless you know what you are doing as this could easily become a path for a denial-of-service attack against your site (since you have no guarantee that the user-agent receiving the error is a person).

Some sites even try monetizing their error pages with Google Adsense and other options.

In the case of Red Roof Inn, I'd recommend adding a custom error page for Server Error 500, giving people alternate methods of reaching Red Roof Inn (at least a reservations number).

Other examples:

  • Typepad returns a standard 404 error for non-existent sites. For example could return a sign-up page for TypePad, or other information about Six Apart. For existing TypePad sites, TypePad should include automatically generated 404 pages for their customers.
  • Microsoft returns a nice 404 page: It lists common links to get you back to the page you wanted, as well as a search box.
  • The 404 error from IBM's corporate site has less information than Microsoft, but does return the standard navigation, a search box, and an option to send an error report to IBM. When I was IBM's webmaster, we briefly tried tying the 404 page into a script which ran a search on the terms in the URL, returning the search results. While nice for the end-user, this became a resource hog. I believe we compromised and returned a static page with the recommended links for the top ten or twenty common mistaken URLs.
  • Jakob Nielsen's returns a nice, simple 404 error page.

The pages for Server Error 500 should probably be static, since your application engine may be down and be the root cause for the 500 in the first place.

Pages for 401 and 403 errors should include information about why access is being denied, and how to gain access to the resource (either a form for registration or a link to a registration page), assuming access can be granted.

In the course of writing this post, Red Roof Inn's web site came back to life and I managed to make a reservation for this weekend, so kudos to their web technology team for being on the ball and fixing the error quickly.


Additional resources:

Posted in Webmastery

202: Accepted Archives

Feed icon We use Feedburner to distribute our web feeds: 202 Accepted Feed

feedburner graphic

Copyright 2002–2011 Artific Consulting LLC.

Unless otherwise noted, content is licensed for reuse under the Creative Commons Attribution-ShareAlike 3.0 License. Please read and understand the license before repurposing content from this site.