10 Things (in no particular order) that a web developer should do for the client (or their own website), as part of the job. Of course, you all know this stuff and I'm just putting it out there to be found by those not in-the-know.
The basic rules here are:
1. Make and set up a 404 error page (and any other likely error messages/handlers)
The default 404 error page on most sites is abysmal offering absolutely no help to the user.
On most decent web hosts/ISPs, assigning custom error pages is either part of the set-up (maybe the control panel) or the default error message files are included within your website. Make sure you make all links to images, stylesheets and pages on this page based from the root of the site as the error can come from a directory deep within the site.
If the ISP/web host doesn't have the facilities to customise at least your 404 error page, change web hosts. Alistapart beat me to this bit. http://www.alistapart.com/articles/perfect404/
This is especially important if you have redone their/your site and made structural changes as there will probably be traffic to the old structure, even if it's just robots.
If it's a ColdFusion site, make sure you have a nice, helpful error handler for (500) server errors as well. I'm sure there is a similar beast in PHP.
If in doubt, ask your host's support team about it and they should be able to help you.
2. Install a favicon.
Even if it's a generic one though it's much more impressive for the client of you actually create one from their logo. Why important? Saves 404 errors in the logs and looks nice as well (on Mozilla and Opera anyway, IE seems to have lost the plot on this even though they used to have it right).
Don't have a generic one, make your own by getting the software from http://favicon.com/.
Also, even though the default filename that browsers look for is favicon.ico, put it in your metadata as well. As we run three different sites (with three different icons) from the same codebase, we rely on the meta tags to get the correct icon for each site and the default is for old IE browsers that ignore the meta tag.
3. Install a robots.txt file
Again, even if it just has "User-agent: *" (or even just a # comment) it will at least save the 404 errors from robots looking for it. Better still add the dirs or files you don't want indexed by robots to it.
What a robot will look for is http://whatever.com/robots.txt so don't be creative and name it something else or try and hide it deeper in your site structure. It won't work unless it is named correctly and sits in the root directory.
See http://www.robotstxt.org/wc/robots.html for further details.
4. When setting up the DNS, check it to see that there are no errors.
It's amazing how many errors are out there in DNS records. Here's a great free tool for you to play with. http://dnsreport.com/
Take a look at http://dnsreport.com/tools/dnsreport.ch?domain=webstandardsgroup.org to see the minimum warnings we allow (and no red errors) on sites we host. Then try your own domain and see what you get.
5. Set up the email server correctly.
Following on from the above, make sure that postmaster@ and abuse@ both actually receive mail. Also make sure that there is a reverse DNS entry for the MX record. Many server-side spam blocking tools will block email that comes from servers that fail a reverse DNS lookup. And most important, make sure the mail server isn't an open relay.
6. Domain forwarding and email addresses.
If your client has a domain name that has domain forwarding turned on to take the user to their free ISP web space (e.g. http://members.ozemail.com.au/~businessname/ ) and they are probably also using their ISP email address (like businessname@ozemail.com.au), advise them that it's very unprofessional. They have the domain name, so they should be using it properly. Hosting a website and email properly isn't a big deal or a big expense, especially compared to buying a .au domain.
It's very important that businesses (no matter how small) don't use hotmail or yahoo or excite addresses. I can't tell you how many business related cars and trucks I see with things like joe_plumber_syd_37@hotmail.com in their signwriting. Or the business cards I've been handed with similarly embarrassing email addresses. This is especially important for a web developer. Cringe... really sorry but I really don't like freemail addresses used by people claiming to be internet professionals. I can understand it if they are using it just for mailing lists to have a good out plan when spam becomes an issue. Did I save it? Probably not.
I'll even go as far as giving you a really cheap solution (and I hate plugs but hopefully you'll see the point and I won't link to them). Domain names are about as cheap as a good lunch. Try any of the tucows affiliates like 123cheapdomains for as little as US$13.95 (and there are even cheaper ones out there), and then point it to a base level account at somewhere like Crystaltech where you can host from as little as US$7.95 per month with email, stats, PHP etc. all included. These are not costs that will break a small business and hopefully can even be afforded by web developer students and amateurs.
7. Metadata
Make sure all your metadata is in place and where required unique on every page in the site. This is a workflow and template issue. We have a base template that we start every site with, or at least take the essentials from. This includes a valid doctype (and for brevity I have used a short one here), charset, basic metadata tags and not much else. You can set the default template in Homesite or Dreamweaver (and I assume most decent editors) to what you want it to be. Something like:
The stuff in UPPER CASE is what you need to fill in for each page. The DC ones are not required but I believe are a good investment for the future. Don't litter the metadata with your own stuff like "Built by webboy.net". Nobody cares (and yes I've done it too).
Oh, and if it's an error page or some other page that you don't want indexed, change the robots metadata to so that a search engine or other robot doesn't index the page (they are smarter than that but use the technology). This overrides the base rules set up in robots.txt.
8. Validate the whole site (a bit obvious?).
Most small business websites are under 50 pages so take advantage of the WDG validator to trawl the site. Most of us validate some pages but I doubt anyone manually validates every page in a new site and some of us don't know about this feature of the WDG validator. http://www.htmlhelp.com/cgi-bin/validate.cgi
See the link at the bottom of http://webstandardsgroup.org/ for an example. If the site is bigger than 50 pages, then it's probably going to be CMS driven and you can work out your own testing based on your knowledge of the system. If not, at least you have the first 50 to deal with.
9. Document your code if appropriate, at least indent it clearly.
You may not be the next person that has to edit this. You may have an accident, or just lose the client. Don't let them think badly of you by having to unravel your shonky code. Let them be impressed by your professionalism. It also makes it easier for yourself to work on the site next time. We never assume that we'll retain the client forever.
10. Statistics
If your web host doesn't give you analysis of your logs, find one that does. It's the best way to see what errors are occuring on the site (and then you fix them if you can) as well as providing useful data about the site and the users. It's just common sense. If you host the site internally, make sure that you get some analysis tools (there are free ones available but you generally get what you pay for) and make a habit of looking at it once a month, even if it's just in the errors section.
If you're not familiar with stats, there are stats available for the WSG site that you can take a look at from within the members section http://webstandardsgroup.org/manage/reports/
The live stats are from SmarterStats and you can drill back a long time in the site's history (though it takes a bit of learning).
Peter Firminger
23-July-2005
The Perfect 404 (Alistapart)
Robots.txt Details
DNS Report
HTML Validator
Copyright © 2009, the members of Web Standards Group
Contact Russ: memberhelp @ webstandardsgroup.org