The only thing is, since we live in south Florida, it’s really not cool enough yet for a fire. We had to open all the windows and turn on the ceiling fan to get the living room cool enough to have a fire.

Years ago, there was a tourism campaign — I think it was sponsored by the Florida Tourism Bureau or some-such quasi-governmental agency. The tagline was “Florida: The Rules Are Different Here.”

That campaign was pretty lame, and it was widely ridiculed and lampooned. This was during the 1980s drug-running heyday, and the “Rules” tourism campaign came to be associated with that. But the message about different rules could be applied to website development. “The Web: The Rules Are Different Here.”

I frequently see sites — and am sometimes asked by new clients for re-designs of sites — that were obviously designed/developed/coded by someone with a background in print design who hasn’t yet learned that the rules are different here.

They use huge graphics that take forever to load. They use rigid, inflexible designs that fall apart when you resize the text in your browser, or when you have a browser window that’s larger or smaller than the window the designer tested in when developing the site. They use drag-and-drop WYSINWYG (What You See Is NOT What You Get) software programs that write code that’s invalid, that displays improperly in some browsers, and that often makes use of javascript or Flash buttons for links — making those all-important links invisible to the search engines.

They don’t understand that the web is not a fixed canvas, like paper. They don’t understand that some of the most important types of visitors are search engines, which are essentially deaf and blind users with browsers that have neither Flash nor Javascript.

Many — probably most — print designers are perfectly capable of learning the “rules of the web” and how it’s different from print work. But all too many of them don’t.

I’m currently participating in a discussion on the SitePoint forums in which the topic of discussion is a web site developer who offers “SEO friendly CMS” (content management system) — but this developer builds his clients’ sites in frames. Not only does he use frames, but the framed content is actually hosted on his domain, not his clients.

There are many, many reasons this is a terrible idea. I won’t go into those here.

What I want to talk about is the statement by one forum member who wrote, “When the pages are indexed, yes they’ll show his domain but unless the client has specifically asked for that not to happen it’s not unethical.”

That’s completely wrongheaded thinking, in my opinion. Clients should not have to know enough about the website building process, the architecture of html pages and framesets, and the inner workings of search engines to request that the developer avoid certain practices that would be bad for the client’s site.

The client hires the web developer because the web developer allegedly has expertise in this area. Any monkey can peck at keys on a keyboard; it’s not the web developer’s time-on-keyboard the client is in need of. It’s the web developer’s expertise.

When I hire professionals or specialists to perform a service for me, I rely on their expertise. I don’t think I should have to study up so that I can tell my mechanic how much torque to use when tightening the tires on my car, or tell my plumber what not to do in order to avoid damaging my plumbing system, or tell my doctor which medicines are contraindicated, or provide my lawyer with the exact wording necessary for a business contract. I hire those people because they supposedly know what they’re doing. They’re supposed to know how to do the things they’re hired to do, and they’re supposed to know what techniques and processes to avoid due to potential damage.

In a similar vein, I believe that anyone who holds him or herself out as a professional website developer — and particularly one who claims “SEO friendly” anything — has a responsibility to perform the promised service using industry-accepted “best practices” without regard to whether the client has sufficient knowledge to request those best practices specifically.

I believe, in fact, that it is unethical for a website developer to engage in the types of practices discussed in the SitePoint forum thread, and in many other practices as well.

But unfortunately, from the client’s point of view, I don’t have a solution to offer. The client, who is usually not an expert in these things, doesn’t even know the right questions to ask, much less have any way of evaluating the answers. It’s all too easy for the unethical developers to give impressive-sounding, baffle-’em-with-bullshit, high-falutin’ answers. It’s easy to talk the talk; but how does the client assess whether the developer walks the walk?

A lot of the things the client should be assessing aren’t obvious from looking at the developer’s portfolio, unless the client himself becomes an expert on web technology. It’s not rocket science, but in my experience, most clients just don’t have the time or the inclination to do that. They’re too busy running their businesses.

Developing a new web site — or re-developing an old one, for that matter — typically involves consulting with the client to determine the site’s target audience and primary objective, creating an attractive and functional design, turning the design into properly coded, valid html, building out the pages of content, and writing the server-side programming to perform whatever dynamic features are needed. But there are several steps that are frequently overlooked before a site “goes live.”

A custom “404 not found” page should be created. At minimum, it should incorporate the site’s overall design and navigation links, and might also include a search form, links to the most popular sections of the site, and/or a way to contact the site owner or webmaster for assistance. And make sure that requests for non-existent pages actually get a “404 page not found” server response. If any other server response is returned — particularly a “200 OK” response — the site could easily become persona non grata in the search engines, among other problems.
A robots.txt file should be created to tell the search engine spiders what pages or parts of the site should not be spidered. Even if you want every page to be spidered, a robots.txt file should be placed in the document root of the site, so as to avoid filling up the site’s error logs with “not found” entries for a non-existent robots.txt. This makes it much easier to spot errors resulting from actual bad links when you examine the error logs.

A canonical URL redirect should be implemented to send all site traffic to your desired canonical URL — either www.example.com, or just example.com (without the www). Whichever you prefer, your should make sure that all traffic to the other form is redirected via a proper 301 redirect.

Test all forms and other interactive features. Submit every form. Attempt to submit forms without required information, or with invalid information. Try to break them. Try really really hard to break them. And make sure that whatever is supposed to be done after the form is submitted actually happens. If an e-mail is supposed to be sent to the site owner, test it, and make sure the owner gets that e-mail with all the appropriate information. If there’s a search engine, search for some things. If the site relies on cron jobs, set them up ahead of time, and make sure they’re running as scheduled and performing as expected.

Test all redirects and rewrites. If the site uses Apache’s mod_rewrite module to present search-engine-friendly URLs, test them all, and test the non-search-engine-friendly versions, to make sure that every bit of content can only be reached by one unique URL.

Check subdirectories for directory listings. Make sure that directory indexes are turned off, and/or for any subdirectory that doesn’t have an index page, plop one in there.

Test all internal links and all outgoing links. Make absolutely sure that every single link leads to the right place. We don’t need to stinkin’ dead links!

There’s simply no excuse for ever launching a site without having completed each of these steps.

Web sites need to contain good content. It doesn’t matter how many people “ooh” and “aah” over how pretty your site is. If visitors don’t find what they’re looking for, they’ll go elsewhere.

Web sites need to be functional and usable. If your site contains exactly what your visitors are looking for, but they can’t find it because of a random, incomplete, or incoherent navigational structure, they’ll go elsewhere. If visitors find what they’re looking for, but when they fill out your contact form and hit “submit” they get an incomprehensible error message, they’ll go elsewhere.

Web sites need to be spiderable by search engine spiders, so that they can be found. If your site is extremely functional and usable, and contains great content, but your potential clients/customers can’t find you when they search for your product or service, they’ll go elsewhere.

Each of these factors can — and do — have entire books written about them. And there’s much more. In this brief post I’ve barely touched on the essential components of an effective web site. The web site owner shouldn’t need to become an expert in all of these things. But the web site developer should absolutely have more than a passing familiarity with all of the aspects of effective web site development, or should work with people who do.

Every day I see web sites developed by so-called “professionals,” for paying clients, that don’t even come close. I see sites in which every single page is a giant sliced-up graphic exported in toto out of Photoshop. I see sites that use Flash for all internal site navigation. I see sites that use frames and iframes for all or most of the site’s primary content. I see sites that have the same title and description for every single page. I see sites that return a “200 OK” header instead of a “404 Not Found” for non-existent pages. I see sites with plenty of pretty pages but virtually no content. Sometimes I see all of these things in a single site!

Attention, web site owners, and those in need of web sites: Tropical Web Works is not the only web site development firm that can develop an effective, functional site for your business. But please bear these points in mind and ensure that whoever you do hire understands these basic concepts.

But sometimes that’s simply not possible. Particularly when the potential client is looking for improved search engine performance or better usability.

Sometimes a site can be improved dramatically by minor tweaks: Add unique, custom title tags to each page, add alt text to images where needed, add text-based site navigation, beef up the content, and a few other improvements. Bang, I’m done, and the client can look for improved performance whenever the search engines see fit to recognize the changes to the site. (That might take days, it might be weeks, it might be months — I try to make sure the client is aware that I have no control over what the search engines do in that regard.)

But all too often the site is constructed so badly that nothing but a total redeveloment will do:

• Frames — frames-based sites are not only less usable for human visitors, but they still throw roadblocks in the path of the search engines trying to index the site.
• Frames Part Two — Even worse is sites that frame content from other sites. The framing site gets no credit in the SEs for the framed off-site content.
• All-Flash Sites — The search engines are working on their ability to index Flash sites, but your all-Flash site is unlikely to be the breakthrough. Flash elements should be used sparingly to add to the visitor’s experience, but Flash should not be the site.
• Search-engine-hostile Dynamic URLs– There are so many ways to go wrong here that it’s hard to list them all. Session IDs in URLs. Meaningless long numbers and section ids and category ids. URLs that display all the site’s content on the same page (using formats like “index.php?page=thispage”).It’s so easy to use the magic of server-side technology to write user-friendly and search-engine-friendly URLs, and to keep session IDs out of URLs. Which type of URL do you like better:
  • http://www.example.com/products/red-widgets.html, OR
  • http://www.example.com/index.php?cat=52 &section=355&prodid=125
&_trksid=p0.m570.l1313&hash=2394087lasmn8&sess_id=5348725987ofdj30487590fjglkae098t87q34085uofilajg

  Yeah, I thought so. Me too. The search engines like the first one better too.

• Lack of content — if there’s little or nothing for the search engines to spider, there’s little or no likelihood of any of the pages turning up in searches.
• Sites that requires the user to submit a form before seeing the content — Hey, search engine spiders don’t submit forms; they’ll never see all that great content on your site.
• Invalid tag soup — Badly coded sites with such badly formed html that it’s darn near impossible to work with the code. When I’m optimizing a site, I need to get down-and-dirty in the code, and pages with invalidly nested tables, invalidly nested divs, incomprehensible, invalid code everywhere — well, I just can’t work with it. It’s hard to even touch the code in a site like that, because you just don’t know what will happen.
• Rigid, inflexible design and code — This usually results from so-called “designers” who design a pretty image in Photoshop or Fireworks and then slice it up and export the entire thing from their image-editing program. The code for these sites is so rigid that you can’t make a single change without breaking the entire thing.
• Template sites based on some badly designed content management system — There are too many big companies out there who have built half-baked content management systems that allow anyone to “build their web site” with a few clicks of their mouse. Nice concept, but usually badly implemented. These sites are usually required to be hosted with the “big company” and runs off their database on their servers. These template sites often don’t allow custom title tags or custom descriptions for each page. They also don’t allow any access to the underlying code. This means I can’t make search-engine friendly URLs, and I can’t set up a 301 redirect, and I can’t eliminate the appearance of duplicate content, and I can’t do any of the easy tweaks that are needed.

All too often, I see sites that suffer from most or all of the above problems. I may be able to work around one or two of the above items, but when a site presents numerous serious technical problems, there’s just no point in attempting to patch the old wineskin.

It’s a shame when someone has paid good money for a site that is so badly constructed that it can’t be improved. But there are times that it makes more sense to throw out the old and build anew.

These factors aren’t important so much for their ability to rank a site highly, as they are for avoiding problems that can harm a site’s ranking.

Using standard href links rather than javascript links, and avoiding canonical URL problems by implementing a 301 redirect from non-www to www, won’t actually help your site rank better for any given search. But using all javascript links and having canonical URL problems can harm your site’s ability to rank well.

These technological factors fall under the “Do no harm” umbrella. Don’t throw obstacles in the path of high rankings. Removing the obstacles won’t cause you to win that race — but it will make winning possible.