No, I'm not trying to convince you to switch to frames. I myself use tables and am not going to change my layout. The only problem is that over time, sites tend to grow. It just might be possible to edit around 20 pages when you want to change something, but when we start talking 50 or over one hundred, it just doesn't seem like a good idea. Unless you are prepared to spend hours trying to keep your navigation menu up to date, you have to come up with a better way of doing things.

SSI's to Rescue ===================

If your host supports Server Side Includes and is running Apache, you can use this article to make your table design as easy to maintain as it would be if you were using frames. The best part is that visitors won't even notice that you have changed anything. After new system is in place, they will see exactly same design and HTML code as before, but you will be saved from hours of monotonous work.

Server Side Includes, or SSI's, can be used in many ways. With them you can execute CGI programs, display current date & time on your page and do plenty of other things as well. In this article, we use them for including external files to your HTML. The idea is to create a separate file from your navigation menu and use SSI's to point to it, requiring you to merely edit one file when you wish to change navigation.

What is this problem I'm talking about? Well, it is quite simple. Usually when a server encounters a 404 error, it records details about event into its log file. Should you suddenly notice that log shows multiple 404 errors due to a page named "abutme.html" not being found, you can deduct that you've probably accidentally linked to "abutme.html" somewhere on your pages instead of using correct filename "aboutme.html". As you can see from above, functionality offered by log files makes them a great help in tracking down such simple mistakes and enables you to keep your site relatively free of in-site broken links.

However, if you happen to have replaced standard 404 error with your own HTML 404 error page, you can't utilize this useful feature. Yes, you will still see that a 404 error has occurred, but you won't get any further details that would help you figure out what exactly happened. Finding and fixing these errors becomes nearly impossible, causing them to pile up over time and deteriorate professional image of your site. Now you're facing tough choice of either showing your visitors a very unfriendly error message that drives them away or accepting fact that your stylish custom 404 error page will become an all too familiar sight to those who click around your site.

All hope is not lost ====================

After reading above, you must be feeling pretty down. I sure know I did after having installed my own 404 page only to notice that I had corrected one problem, but caused another one while doing it. Still, there is a solution to every difficult situation and this one is no exception. If you want to keep your 404 page and still get informed when you mess things up and create a broken link, you'll be pleased to hear that I happen to have just thing for job. Before we begin, please take into account that in order to use this fix, your host has to be running Apache with support for .htaccess files, Server Side Includes (SSI) and CGI. Contact your technical support for information on whether you have access to these valuable features or not.

Without further ado, let's roll up our sleeves and get to work. The first thing you will need is a CGI script that will log errors and let you know about them. There are several ones out there that you can use, but I personally prefer Matrix Vault's free 404 Helper that can be found at http://www.pixelwarehouse.com/cgi/404helper.shtml . Download source code to your hard drive and open it in a text editor. You can get free editors from Net, but old MS-DOS Edit supplied with just about every version of Windows will do just fine. To run Edit, go to Start, Run, type "edit" without quotes into box and click OK.

Before you start editing file, you'll need to know where your host has installed Perl interpreter and Sendmail. Once you have figured it out, check if paths used in CGI script match those your host uses. The Perl interpreter's location is set to /usr/bin/perl in first row and location of Sendmail is set to /usr/lib/sendmail in 21st row. Make changes, if necessary.