Building a Successful Web Site: What NOT To do:

Written by Marc McDonald

These days, there's no shortage of "how to" guides and articles out there that purport to explain what one must do in order to become a successful Web site owner.

If you want to build a successful site, however, it's equally important that you also learn what NOT to do onrepparttar Web. Most experienced Webmasters are aware of a number of major no-nos to avoid. Examples include having a welcome page that takes forever to load. Or designing your site to accommodate only one type of browser.

However, there's a number of lesser-known, but still common, mistakes that many Webmasters consistently make. These include:

1. Not paying close attention to your visitors' feedback. Although many Webmasters don't realize it, feedback from your visitors is one ofrepparttar 134735 most important sources of information you have, if you're serious about building your traffic. If a visitor has takenrepparttar 134736 time to E-mail you, you should carefully consider anything that he or she has to say, whether it's positive or negative. True, if you've worked hard on your site, it can be annoying to have a visitor write in and criticize aspects of your site. But rather than feeling slighted, you should makerepparttar 134737 most of such feedback. I've found overrepparttar 134738 years that many ofrepparttar 134739 most valuable and useful features and changes on my sites were inspired by visitors' comments and critiques.

2. A second common blunder that a lot of site owners make is trying to build revenue before they've built a sizable, loyal audience. This is a bit like putting a cart before a horse. If you're trying to build your traffic, you severely damage your prospects by focusing too much onrepparttar 134740 revenue side of your operation atrepparttar 134741 outset. If your site isn't established yet, and you don't have a loyal, growing audience, then it's important to minimize your focus on making money. For example, you shouldn't be plastering banner ads all over your site---or pestering your visitors to sign up for an affiliate program. In short, forgetrepparttar 134742 revenue: at least atrepparttar 134743 outset. Instead, focus exclusively on promoting, developing and fine-tuning your site. The fact is, once you have built an audience,repparttar 134744 revenue will inevitably follow.

All hope is not lost - 404 Errors

Written by Lauri Harpf

In a previous article, I discussedrepparttar advantages of using a customized 404 error page on your site and gave instructions on how to create one. As I explained back then, these pages are highly useful because they enable you to benefit from traffic that would otherwise be lost. They however do have one dark side that can make maintaining your site significantly more difficult than what it has been before.

What is this problem I'm talking about? Well, it is quite simple. Usually when a server encounters a 404 error, it recordsrepparttar 134734 details aboutrepparttar 134735 event into its log file. Should you suddenly notice thatrepparttar 134736 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 usingrepparttar 134737 correct filename "aboutme.html". As you can see fromrepparttar 134738 above,repparttar 134739 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 replacedrepparttar 134740 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 deterioraterepparttar 134741 professional image of your site. Now you're facingrepparttar 134742 tough choice of either showing your visitors a very unfriendly error message that drives them away or acceptingrepparttar 134743 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 readingrepparttar 134744 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 justrepparttar 134745 thing forrepparttar 134746 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 logrepparttar 134747 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 . Downloadrepparttar 134748 source code to your hard drive and open it in a text editor. You can get free editors fromrepparttar 134749 Net, butrepparttar 134750 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" withoutrepparttar 134751 quotes intorepparttar 134752 box and click OK.

Before you start editingrepparttar 134753 file, you'll need to know where your host has installedrepparttar 134754 Perl interpreter and Sendmail. Once you have figured it out, check ifrepparttar 134755 paths used inrepparttar 134756 CGI script match those your host uses. The Perl interpreter's location is set to /usr/bin/perl inrepparttar 134757 first row andrepparttar 134758 location of Sendmail is set to /usr/lib/sendmail inrepparttar 134759 21st row. Make changes, if necessary.

After you have made sure thatrepparttar 134760 paths are correct, modifyrepparttar 134761 rest ofrepparttar 134762 script to suit your needs. Be sure to replacerepparttar 134763 E-mail address inrepparttar 134764 $email field withrepparttar 134765 one you wantrepparttar 134766 error report to be sent to. You might also wish to use a smaller value inrepparttar 134767 $mailon field thanrepparttar 134768 default of 10, as it can take quite a while for a small site to generate enough 404 errors to fill up a 10K log. I suggest using a value of 1 or 2 atrepparttar 134769 beginning and raising it later if you feel that you are receivingrepparttar 134770 error reports more often than you'd like to.

Cont'd on page 2 ==> © 2005
Terms of Use