The web server cannot find the file or script you asked for. Please check the URL to ensure that the path is correct.
Please contact the server’s administrator if this problem persists.
Ha! I bet you thought this page wasn’t here. Ha ha! Hooo! Yeah.
That 404 message above is familiar enough to most people to stimulate a Pavlovian click of the Back button. Which means it’s doing its job. 404 Not Found is the most famous of the HTTP status codes. These status codes are three-digit responses that an HTTP server returns when given a request. These codes fall into three series:2xx, which means success, 3xx, which means partial success (redirection), and 4xx/5xx, for errors on the part of the client and the server respectively. Some highlights include 200 OK, which is the most common, but rarely seen in the flesh — it just means everything worked; 401 Unauthorized, when HTTP authorization has blocked a request; 500 Internal Error, when the server somehow couldn’t provide the requested page. 404 is the one that pops up when the client asks for a page that isn’t there.
So what does your average web surfer do when she hits a 404 page? At best, she trims the URL layer by layer until she finds what she’s looking for, or returns to the home page and searches. At worst, she goes elsewhere and never returns to your site.
Either way, 404s represent a major bleed-off of traffic and source of user frustration, which, as hospitable web providers, we want to do our best to avoid. So what can be done?
Ideally, we want to set things up so Sue User never hits a 404 error at all. It is a good policy to go through your server logs on a regular basis and grep for lines indicating that a user has encountered a 404. If you notice a disturbing trend (say, a lot of failed hits to “contnets.html”), it’s quite likely that users are following an incorrect link that points to that nonexistent page. If the bad link is on your site, no problem:fix it. If the users are all being misdirected by some other site, email that site’s webmaster ASAP, using the referrer info from your server log. If you have no referrer info in your server log, you can search on Google for the source of a broken link, by typing the following into their search box:
This will show every page indexed by Google that contains a link to that nonexistent page. Other search engines offer a similar feature. Also, there are a number of third-party link auditing tools that you may find useful.
You may also want to create an interim “contnets.html” page that redirects users to the correct location.
If you shift things around on your site and break links on a regular basis, then stop doing that immediately. Even if you update all your internal links correctly, users may have bookmarked pages and will get very confused and depressed when their bookmarks cease to work as expected. If you just can’t help it, at least leave a marker page at the old location of a moved file, explaining what’s happened and why, and redirecting users to the new file location, like a friendly Detour sign.
Note that dynamically generated links can be a subtle but pernicious source of errors. Good site planning can avert most such difficulties. Finally, use common sense. If you have short, simple URLs, users are more likely to type them in correctly the first time. Remember that URLs are case-sensitive!
Try as we may to steer users exactly where we want them, it’s inevitable that they will hit the occasional 404 page. When that happens, the ball is once again in our court. So let’s take a swing at the problem.
Corrective Measures (Apache, IIS, Other)
When a web server encounters a 404 error, it calls a particular file, as specified in its configuration. By default, this file looks more or less like the one at the top of this article. But that’s about as unhelpful as a 404 page can be. Nice minimal design, but little else to recommend it. Much better to design your own.
If You’re Using Apache
You probably have a .htaccess file in your web root directory already, controlling various Apache functions. If you don’t have such a file, you need to create one. You can do this whether you are in charge of the server or just one of a number of people who use it.
To serve a custom 404 page, the .htaccess file should contain a line like this:
ErrorDocument 404 /errordocs/404.html
where “/errordocs/404.html” is the name of the file you want to serve. This doesn’t have to be a flat HTML file. It can be PHP, ASP, SHTML, or whatever you like. Also note that the file can contain a series of ErrorDocument lines, using the same syntax to serve custom pages for various other errors: 401, 500, whatever you like, just by replacing “404″ with the relevant number.
If You’re Using IIS
Open the Properties of the web service. Click the Custom Errors tab, select “404″, and click “Edit Properties”. Select “URL” for Message Type, and input the location of your custom error page.
Setting up a custom error page on IIS requires access to the server’s MMC interface. If you don’t have this access, Port 80 Software offers a third-party solution that you can buy.
If you’re running some other web server, I’m sure it’s not too hard to set up custom error pages. If you don’t control your own web server, read the documentation provided by your web host. Many ISPs have their own proprietary interfaces for changing error documents.
NOTE: Microsoft, in its unerring wisdom, has implemented a “feature” since Internet Explorer 5 that displays its own built-in error page rather than the 404 page the server sends. This override is also present in Google Toolbar and other downloadable browser toolbars. To circumvent this helpful feature in IE and Google Toolbar, your custom 404 page has to be bigger than 512 bytes. So drop in a JPEG of your shining mug or something, especially if a good number of your users are visiting your site using Internet Explorer — which is standard issue on several of Jupiter’s moons.
Basics of 404 Page Design
There are a number of improvements you can make to the standard 404 page. These vary in complexity, server and programmer overhead, and effectiveness. The most basic — so basic that no site should be without it — is to replace the generic 404 page with one that has your site’s logo and design scheme, and a link to the home page, if not a full-blown navigation bar. It should also express clearly what has gone wrong, and what the hapless user can do about it, something that the standard 404 page does very badly.
This can be expanded with links to a site map or other important parts of the site. A mailto link or form to notify the site administrator of the problem can also be a helpful addition.
If you feel the need to move beyond the basics, there are a number of significant improvements you can make. Adding a search box to your 404 page can be dramatically helpful to the user, and redirect a lot of traffic that would otherwise be lost. If your site already has search functionality, it is of course trivially easy to add a box to 404.html. If not, you can get good old Google to do the job for you.
If your site has one basic function, like a dictionary lookup or package tracking, you might want to put an input box for that function right on the 404 page.
Bonus 404 Baubles
If you want to invest a bit more effort in your 404 functionality, and you run Apache, you can have your web server check for misspelled URLs on the fly. Apache’s mod_speling (yes, one l) module is designed to do just that. It’s not compiled in by default, so you will have to recompile Apache (or convince your web host to do so) if you want to have access to this feature.
With mod_speling compiled as a module in your Apache installation, you can turn it on by including the directive …
… in your .htaccess file.
The behavior of this function is:Apache compares the incorrect URL to all the available files on the site. If Apache finds a single match for a misspelled URL, it automatically redirects the user to the correct page; if it finds more than one possibility, it presents a list of choices to the user.
By default, the list is presented in simple Apache style. You can spruce it up, parse it, et cetera for your users if you like, though, with a bit of code. When Apache finds a misspelled URL, it sends status code 300. You can trap this and handle it yourself with an .htaccess line like:
ErrorDocument 300 /errordocs/300.php
The list of possible correct spellings of an URL is contained in the environment variable $REDIRECT_VARIANTS. Grab this variable and parse it for your users with a script you call 300.php, and you can have a beautiful “Maybe you meant” list, formatted as you like it, with your logo at the top and a search box at the bottom, and meanwhile you can log common misspellings.
If you want mod_speling-type functionality on an IIS site, it’s Port 80 to the rescue once again. Its URLSpellCheck product provides a similar service to Microsoft-driven sites, at a much smaller cost.
Last, but most emphatically not least, if you crave attention, you can always make your 404 page fun. Blundering around the Web, one can find 404 pages with random pictures, arcade games, interactive fiction, animation, haiku, and heaven knows what other millions of brilliant ideas.
Here are a bunch, well-designed informative ones as well as entertaining ones. There’s something pleasingly perverse about having your page-not-found page be the main attraction on your site, isn’t there?