Web servers are a lot like baseball umpires: when they’re doing their jobs properly, you’re barely aware of their existence. Of course, while watching a baseball game, you know that there are umps, calling balls and strikes and determining whether a runner is out or safe. But when the umps are really on their game, fans can safely focus on the players and the action itself. Similarly, I suspect that most web users understand that sites are hosted on some far-away computer, but this fact should never be brought to their attention while browsing the web, which is exactly what happens when error pages appear. When an umpire blows a call, his presence on (and off) the field is glaringly obvious. Managers and players get ejected. Columnists across the country throw their two cents in. Fans boo. And one of the most common reactions typically sounds something like: nobody pays to see umpires.
And nobody (well, _almost_ nobody), wants to be aware of what’s going on with a site’s server. On the internet, the ‘blown calls’ become obvious when users see HTTP error pages. These pages appear when, for a variety of reasons, the server can’t figure out how to show the user what they are trying to find. Neither users nor search engines like to find error pages; they’re frustrating and significantly hurt the user’s browsing experience. If you own a site, you really do need to know exactly how, when, and why error pages are showing up for your clients. And most importantly, you need to know at least a little bit about what is causing the problem, so any issues can be addressed. Unfortunately, like a lot of aspects of information technology, error pages weren’t designed with much consideration into making them understandable. By default, most modern servers return a page with a cryptic 3-number code, and some jargon about the nature of the error. But unless you have a decent amount of training in systems administration, these messages probably aren’t of much use. To help make these codes more understandable for non-geeks, I’ve summarized some of the most common error codes that you might see on a site, as well as steps that you can take to fix the errors.
Probably the most common error page on the web, a 404 error means that the server can’t find a particular file. Most commonly, this is the result of one of two things: the URL of a page has been changed or there was a typo in the link that led a user to a page. In the first case, this can happen if you rename a file or move it to a new directory. For example, if you change a URL from www.yoursite.com/awesome_page.html to www.yoursite.com/awesome_pages/page.html, without making any other adjustments, anyone going to the old link will see an error page. The second instance should mostly speak for itself: going to an incorrect URL simply won’t let you find what you’re looking for.
The best way to limit 404 errors is to avoid changing filenames and URLs for the pages on your site whenever possible. Unless there’s a compelling reason to change the URL of a page–because of a change in a blogging platform, for instance–it’s best to not change the URL of any page on your site after it has gone live. However, if it is absolutely necessary to change a URL, you will need to have a systems administrator set up what’s known as a 301 redirect. In spite of its totally uninformative and official sounding name, a 301 redirect is really quite simple: it works exactly like a Change of Address form that you fill out when moving to a new home. The only difference is that a 301 redirect is a small piece of code that tells visitors, rather than a mail carrier, that the information that they are looking for can be found in a new location. If properly implemented, 301 redirects are completely invisible to most users. They will simply be redirected to the new version of the page, and won’t be exposed to the frustrations of not finding the exact page they’re looking for the first time around.
Both 401 and 403 Errors occur when the server thinks that a page that a user is trying to access should be password-protected. These errors show that server either thinks that the visitor has not logged in (401), or is logged in but doesn’t have the proper verification to view a page (403). Sometimes, these errors aren’t really server problems at all. If your site is _supposed_ to be password protected, and unauthorized people are trying to access it, you would definitely want these pages to show up. Other times, however, these pages might indicate that there is a problem with the server’s settings.
If you are seeing a 401 or 403 error on your site on pages that don’t need to be password protected, ask your systems administrator, web host, or developer to take a look at the server settings. Chances are that this is the result of a very minor mistake, and should be quick and easy to remedy.
Any error page that starts with the number 5 is an indication that there is a problem with the server. These are typically going to be more complex issues, and aren’t going to be related to filenames or anything that a site owner would typically access.
The good news about the 500 errors are that they are almost never your fault. The bad news is that they can have complex causes and usually need to be addressed by a web host or systems administrator. If you see one of these errors on your own site, don’t panic. Wait a few minutes, and try to access the page again. If the problem continues, it’s probably time to call out the big guns.
While addressing many of these issues will generally take some level of web expertise, I hope that this guide will at least help you understand what might be causing the errors that you might come across on your site. While it might not be possible to prevent 100% of all errors from occurring on your site, understanding common causes for errors should help prevent many–if not most–of them.