Search Engine Musings

Does valid code matter?

You often see that question on SEO forums, and the wide diversity of replies shows how much confusion there is on this. It usually degenerates pretty quickly into an argument between those who fervently believe valid code helps search rankings and those who don’t. This misses the point completely.

My opinion, confirmed by numerous examples of building sites that rank quickly and well, is that code should certainly be as valid as possible but that more importantly it should be elegant and it should be suitable.

What exactly do I mean by elegant? Einstein said that things should be as simple as possible but no simpler. Really well structured code is so simple that it can read almost as easily in the browser source code as it can when it’s rendered. That is the result of good planning at the design stage - not rigid planning that goes for a specific effect but flexible planning that can allow for changes requested by clients and future development of the site.

By suitable I mean coding and programming that has been designed to accomplish the tasks that the site requires while fitting in with the overall design. Not something that has been borrowed from other sites and which then needs hacks and inline styles to fit in.

Read your source code and if you see complexity ask yourself why it’s there and is it necessary.

It’s very rare that you need to have code that has classes or span tags on every paragraph or heading - they should inherit their styling from their parent elements. It’s extremely rare that you need to use tables for anything other than tabular data.

Complex dynamic sites provide plenty of opportunity to go wrong because very often such a site’s different modules will be built by different programmers, and if no-one has an overall vision for the site and controls the architecture of it you’ll often find that parts of its coding structure are derived programmatically using inline tricks which produce poor HTML. Being a good programmer doesn’t mean being a good web designer and if there are multiple people working on a site there needs to be good communications between them.

This is also where the SEO knowledge has to come in if it hasn’t already, because it’s rare for programmers to have any understanding of it. That’s not to criticise them - they only require it if they are taking on a wider role than just programming.

When validity matters

Note that since the second paragraph I haven’t mentioned validity at all, let alone as a goal in itself. Elegant code will nearly always be valid pretty much automatically. However code can be valid and not elegant. It’s perfectly possible to write complex and convoluted code that is perfectly valid but not at all appropriate.

There are many different types of errors that can cause invalid code. Some are of very little importance, some may be important for cross-browser compatibility purposes but not be show stoppers otherwise, while others may be fundamentally important to HTML structure. Search engines may well be able to ignore many of the less important errors but may be unable to interpret the more structural ones. For instance I have seen cases where crucially placed duplicate IDs have caused spiders not to follow navigation systems. One site appeared perfectly ok in all other aspects and no-one could understand why it wasn’t being properly indexed until I pointed out this problem and corrected it; whereupon the missing pages suddenly began to appear in the indexes.

You won’t get prizes from the search engines for just having valid code but you will get benefits from well-designed, simple and elegant code; and that’s what you should be aiming for as both a web designer and an SEO.

I look at dozens of sites every week and one of the first things I do is check the code to see how they’ve been constructed and, amongst other things, whether the code is valid or not. What I see time and again is designers who don’t understand DOCTYPES and cause themselves and their clients problems. A lot of this stems from the defaults used in Dreamweaver and designers over-relying on it to do things for them.

Earlier versions used an HTML version 4 DOCTYPE but crucially ommitted the address, meaning that the pages were in quirks mode on most browsers. That meant lots of cross browser incompatibilities and problems rendering modern CSS properly. It was a well-known problem amongst the better web design forums and newsgroups but many never seen to have picked up on it. It’s easy enough to set up the various correct types as snippets, and it’s even quite easy to change the default in one of the internal template files.

Recent versions of Dreamweaver use an XHTML DOCTYPE by default and amongst the more stringent requirements of this is that you must close any tag that doesn’t naturally have a closing tag. This includes meta tags and image tags and you must add a trailing / before the closing > in order to be writing valid code. A good designer really should be aware of this but unfortunately a great many aren’t and this results in a lot of sites with a lot of validation errors. Some search engines are more forgiving of validation errors than others but why make it harder for them? All my experience says that cleaning up the code helps rankings; and of course valid code is the only real foundation for maintaining cross-browser compatibility and future-proofing your site.

Incidentally, Dreamweaver is a good product and certainly the best of the visually capable web editors, but like any program it has to be used with knowledge and understanding of the language it’s creating. It generally produces decent code but if you push it in the wrong directions or use it inappropriately then it can produce rubbish just like any other program.

Learn about the different DOCTYPES and the reason for using them at the Web Design Group site, and the W3C Recommended list of DTDs, and make your web designs a lot more professional and your sites a lot more search engine friendly.

Since I don’t currently have a blog on the web design site I thought I’d drop this one in here. After all, trying to do SEO on top of poor foundations is a thankless task. It was inspired by a blog item which I “think” I saw on SEOmoz entitled The 5 most underused HTML tags, though now I can’t seem to find it. (Good blog incidentally, recommend it.)

HTML has undergone many revisions and fashions in its short life, and there have been a number of blind alleys and wrong turnings on the way. This has resulted in the complete misuse / miscoding / misunderstanding of many of the tags which give the markup language its tools. By this I don’t mean those horrible tags like blink or marquee which made so many sites unbearable in the late 1990’s, but the ones that competent designers should know how to use.

Unfortunately some of the WYSIWYG programs which appeared when website building became popular were responsible for lulling people into thinking that they didn’t need a solid understanding of HTML. Some of them made it hard to even see the underlying code while many of them produced code that was at best convoluted and sometime completely invalid. Only the fact that the most popular browsers were far too forgiving of poor code allowed the resultant sites to get away with it.

So here we present:
The most mis-coded HTML tags
The most misused HTML tags
The most misunderstood HTML tags

The table tag

What’s so wrong with the table tag I hear you cry. Nothing much in itself, perfectly reasonable tag, I don’t even mind too much if you use it for positioning (though it wasn’t intended for such things) but please, don’t give it attributes that are invalid - mainly height. It’s not good code and mostly it proves you’ve used a WYSIWYG program without understanding what it does. Secondly, do try not to nest them more than 3 or 4 deep - if you do that then you are probably trying to create positioning that should be handled using CSS.
And for goodness sake don’t try and put an absolutely positioned div inside one.

The meta keywords tag

The spammers favourite. Stick every keyword you can think of in there, throw in Britney Spears, Paris Hilton, and the kitchen sink. Ignore the fact that everyone except Yahoo stopped paying attention to it (except to penalise spamming of it) years ago and even Yahoo check to see if your body text includes the terms and penalises you if it doesn’t.
Then wonder why your site doesn’t rank…

The font tag

C’mon guys, they announced that this was being deprecated back in the 90s. The occasional bit of in-line use might be forgiveable - building new sites using it all over the place for basic formatting in 2006 is just amateurish. If you can’t even learn CSS1 then stop claiming to be a web designer and then we can dump this one into the bin with “blink”.

The span tag

It’s not a div tag, you can’t have block level tags inside it. It’s for in-line styling within tags such as p tags. It’s for exceptions to the general rule, not to be used all over the place.

The form tag

Probably the single most miscoded tag in the world. If you must mix it with tables either put it inside a table cell (td tag) or outside a table tag - do not put it round a tr tag - not only will it throw up an error on that tag, it’ll produce knock-on errors that will have the validators running in circles. And it’ll make any attempt to use CSS to effectively style the form into a horrible mess.

Wouldn’t it be nice to see these being used properly in 2007!

Happy Hogmanay and a Good New Year to you all.