Building a Good Author Web Site:

Dead Files (Forwarding the Browser)

by David Dvorkin

Why Files Die As your site grows, it's inevitable that some of the HTML files you started with will cease to exist - at least, under their original names and in their original locations. In some cases, you'll decide that you chose an awkward or misleading name for a file. It's not misleading for the site's users, who don't normally pay any attention to the name of the HTML file they're viewing. They're interested in the content, in what they see in their browser, not in the name you chose for a file. But a misleading or confusing name can cause problems for you. As the number of files increases, you'll find it increasingly difficult to remember what content is in what file. That's a reason to think carefully about what you want to name each new HTML file; don't fall into the trap of naming them, say, file1.html, file2.html, file3.html . . . Unless you're an unusually careful and wise person, you're bound to name at least one of your HTML files unfortunately and then later decide that you simply have to give it a better, more meaningful name before it drives you crazy. Sometimes, you'll simply delete an HTML file. Its content may have become irrelevant, perhaps because your Web site has changed its purpose or orientation with time. Or the original file may have been replaced by a group of files. For example, all of these pages about designing an author Web site started out as one HTML file because I thought it would be short. I soon had to replace that original file with a lot of files. Once you have created that group of files, the original one is no longer needed. (Such a group should be kept together in a separate directory. See the section titled Directory Structure.) Finally, as your site grows, you should start creating directories and moving related groups of files into them. This makes the whole thing much more manageable. (Again, see Directory Structure.) In all of these cases, the original file is no longer there. The content is presumably still on your Web site, but not in the HTML file where it originally resided. You may think that, since you haven't destroyed the content, visitors to your site should be just as interested in what you have to say as they were before. After all, you've been scrupulous about updating all of the links within your site to take account of the new file names and/or locations. And you'd better be sure you do just that. Think how annoyed you would be if, while reading one of the preceding paragraphs, you clicked on the link in the parenthetical remarks and, instead of seeing a page about directory structure in a Web site, you saw an error message saying that file didn't exist. The error message is what you would see if I had changed the name or location of the file in that link but neglected to update the link appropriately. Remember our mantra: happy visitors, not annoyed or confused ones. Tragic Aftereffects of File Death So internal links aren't a problem. But external links are, and you can't control those. If someone visited your site a month ago, let's say, and liked one of your pages enough to bookmark it in his browser, and if since then you've changed the name or location of that file, that bookmark is now invalid. Perhaps that visitor liked what you had to say in that file so much that he e-mailed the file's URL to a thousand friends. A thousand potential purchasers of your books! But if they try to use that URL, their browsers will now give them a file-missing error message, and they will turn into a thousand people who despise you and who will tell all their friends not to buy your books and even to refuse to read them if they're offered copies for free. A kind of external link that's more important to most of us in a business sense is the kind people see when they use a search engine, such as Google. When you do a Google search, you'll often find that some of the links returned by the search are dead: they return only file-not-found error messages. Perhaps the files have been moved or renamed, as we've discussed above. Or perhaps the Web sites themselves no longer exist. If any file has been on your site for more than a few days - three or four days are usually enough - it's probably already indexed on Google, Yahoo!, and the rest of them. That means that a link to that file can show up as the result of a search. And that means that if you delete or rename or move the file, someone clicking on that link will get an error message. As I've said, they might be annoyed by that. But it's also possible that they'll conclude that your Web site no longer exists. Coping with File Death None of this means that you should never delete, move, or rename an HTML file. As I explained above, you'll want or need to do all three of those quite often. But it does mean that you should take a fairly simple step to make sure that links to the original file still work, in the sense that they still take visitors to the same content. Actually, what I just said isn't true. Indeed, you should never delete, move, or rename an HTML file. Rather, you should make a copy of the file in the new place or under the new name. Or, if you're replacing the file with a group of files, you should create the new files while leaving the old one in place. In all cases, leave the old file where it was, with the same name. Just eviscerate it. After you've copied all the content to the new place, so that you're sure it's safe and where you want it, edit the original file and remove all of the HTML, leaving only something like this: <HTML> <HEAD> <TITLE>Unquenchable</TITLE> <META HTTP-EQUIV="REFRESH" CONTENT="1; URL=pob/unquench/unquench.htm"> </HEAD> <body> This file has been moved. <p> Your browser is being redirected to the <a href="pob/unquench/unquench.htm">new location</a>. </body> </HTML> Explanation The above file should display very briefly (for a second or so) in the user's browser, and then the browser should automatically switch to showing the new location for the original file. All of this is accomplished by the single line <META HTTP-EQUIV="REFRESH" CONTENT="1; URL=pob/unquench/unquench.htm"> The "1;" tells the browser to wait for one second and then refresh the browser display with the file specified after "URL=". Don't Leave Them Hanging So what about the HTML code in the body of the file? Why do we need that? That's intended as a backup, or safety feature. While the above file is displayed on the user's screen, before the browser switches over to the new file location, the user should see this message: This file has been moved. Your browser is being redirected to the new location. Just in case the user's browser doesn't switch over to the new location - and that's always a possibility - that link is provided to take him to the same place. That's assuming he realizes that something has gone wrong. Instead of the above message, some Web sites say something like, "If your browser is not redirected after five seconds, please click this link." Example To show you how this looks in practice, I created a small HTML file to demonstrate. It contains the HTML shown above, except that I changed it so that it redirects the browser back to this file, the file you're now reading. When that small file gets loaded into your browser, it displays for a second or so, and then your browser replaces it with the file you're reading now. To see what I mean, click here. Okay. So I lied. If I had done what I said above, the browser would have returned to this file, but it would have had it open at the top of the page, instead of down here, where you're reading. So in this file, just before the header "Example" above, I inserted a bookmark: <a name="deadeg"> </a> and then in the little file that the above link points to, the line of code that instructs the browser to switch back to where you are now actually looks like this: <META HTTP-EQUIV="REFRESH" CONTENT="1; URL=deadfiles.html#deadeg"> You wouldn't normally use this sort of trick. When you forward the user to a file's new location, you presumably want him to see the file from the top. But I thought you might find this interesting and useful, anyway.

	Web www.dvorkin.com