Recipe 9.1. Handling Requests for Missing or Relocated Pages

Problem

You need to guide users through errors and keep them happily browsing your web site, even when things go wrong.

Solution

Missing pages accompanied by cryptic or meaningless error messages can turn visitors away from your site. Use a custom error page, HTML <meta> tag redirects, and web server Redirect directives and mod_rewrite rules to smoothly guide web surfers over rough patches on your site.

Also, make sure that the error messages your visitors encounter while browsing your site are helpful and user oriented. Here's a checklist to follow:

State the specific problem and (if at all possible) a solution. If there is no solution for a typical user, it's probably an error the user shouldn't see in the first place.
Keep the message brief, but include advice for avoiding the problem in the future.
Use a basic, straightforward design. The error message should be the most prominent, if not the only, element on the page.
Use friendly language and avoid strident language (including exclamation points) or "techy" words.

Discussion

An outdated bookmark, an old offsite link, or even a typo may lead web surfers to request a page that's not on your site. The HTTP error code for a missing page is 404, so in webmaster parlance a 404 page is the page visitors see when the requested page is not found.

A good web hosting provider will provide you with easy-to-read traffic statistics, where you can actively monitor bad links people are trying to load.

You can specify a custom 404 page in your Apache configuration file (htppd.conf) or with an .htaccess file in your web site's root directory. For more on creating and manipulating Apache configuration files, see Recipes 1.41.7.

Creating a custom error page

Your error page can be named anything you want, although typical choices are error.php or missing.html. The configuration line should look like this:

 ErrorDocument 404 /error.php

If you don't specify an error page, users will see the web server's default error message (shown in Figures 9-1 and 9-2).

Figure 9-1. Apache's default error page loads when the request page can't be found

Figure 9-2. The default missing page for Windows IIS loads when the webmaster has not created a user-friendly error page

Your custom error page should be the last safety net for web site visitors who request a missing page. There are other, more sophisticated methods for handling old bookmarks and links when you rearrange or rename files on your site, but this should always be your first step.

Figure 9-3 shows a sample error page that loads when a user requests a file that does not exist (foo.htm); obviously much better than what you saw in Figure 9-2!

Figure 9-3. A custom error page explains the problem concisely and offers a way for web site visitors to get back on track

Note that the requested URL remains in the browser location field, even though the page that actually gets displayed is error.php.

The headline states the problem, the first paragraph explains why it happened, and the second paragraph offers solutions in the form of links to a site search and site map. Since the error page is a PHP script, it includes a bit of code that emails a "404 Report" containing the requested and referring page URLs to the webmaster:

 mail("webmaster@daddison.com","404 Report",    "request: $REQUEST_URI\n\nreferrer: $HTTP_REFERER",    "From: webmaster@stardate.org\nX-Mailer: PHP/" . phpversion( ));

Redirecting users to a new page

When you move or rename pages on your web site, you should take steps to anticipate users clicking on old bookmarks and links, and respond to them by forwarding their request to the new or moved page. Your custom 404 page should not be what visitors see, especially when you've made changes to your site layoutthat's certainly not the fault of the user!

Say you have a file on your site named report.html and decide to convert it to a PHP file named report.php. With a customized version of your old report.html, you can catch visitors still requesting the old page and automatically redirect them to the new page (see Figure 9-4).

Figure 9-4. A page that notifies visitors of a change and automatically redirects them to the new page

On this page, the headline and first paragraph state the problem and why it occurred. The solution: the user needs to update their bookmarks and links.

The <head> section of this page also has a <meta> tag that will make good on the stated promise that the visitor's browser will be automatically forwarded:

 <meta HTTP-EQUIV="Refresh" content="10; URL=http://daddison.com/wscb/report.php">

After ten seconds, the HTTP-EQUIV="Refresh" attribute of this <meta> tag will load the new page in the visitor's browser.

Redirecting requests to a new directory

Now, let's imagine that you've done some wholesale remodeling on the site and you've moved all your reports from the /reports directory to /analysis/reports. In the old/reports directory, create or modify an .htaccess file with this line:

 Redirect /reports http://yoursite.com/analysis/reports

Note that the first, old directory name is relative to the web site root (/reports), while the destination of the redirect is a full URL (http://yourdomain.com/analysis/reports). Neither of these paths should have a trailing slash.

With the files relocated and the redirect in place, you can safely delete the files in the old directory.

Page-specific redirects

Apache redirects work from directory to directory, with the assumption that requests for files in the old directory can be fulfilled with same-named files in the new directory. For more complex redirectsfor example, when files get moved and renamedyou need to use rewrite rules that get executed by the mod_rewrite module (Recipe 1.6 has more on determining if mod_rewrite is available on your web server, and how to enable it if it's not).

The rewrite rules go in an .htaccess file in the old directorythe one from which the files have been relocated. If you have simply moved and replaced the .html suffix with .php on all your files, then this rule will make sure visitors get the new page:

 RewriteEngine On RewriteRule (.*).html$ /analysis/reports/$1.php

The filename in front of the suffix has to be the same for both the old and new file for this rule to work successfully. In other words, the server will respond to a request for http://yoursite.com/reports/PDAs.html with the page http://yoursite.com/analysis/reports/PDAs.php using this rule. The dollar sign in the code indicates a match only at the end of the URL. The $1 placeholder indicates the replacement location for the wildcard search in parentheses: The regular expression pattern .* stands for one or more instances of any character before the .html suffix of the filename.

If, for example, the PDAs.html report page has been expanded, moved, and renamed to mobiledevices.php, then Apache needs a more specific rule.

 RewriteRule PDAs.html$ /analysis/reports/mobiledevices.php

In this case, you might need to make a rewrite rule that maps each old filename to its successor.