SEO - from a coders view

This article comes in response from a Information Architect asking how a coder can better Search engine Optimization. These are my impressions of SEO, typically developers may have different opinions, as after all there are many ways to crack an egg. I have provided a few links to where others have supported my thoughts and or discussed the practice. SEO goes hand in hand with accessibility a few aspects of which I highlight below.

Separation

XHTML should be written from a legal point of view and should preferably have little to no reference to how the content will finally render as per the designers creative. We should code trying to use the full array of XHTML tags to make the most semantic use of the copy provided. For example we would like to use <h1> to <h6> for headings and title’s; <ul> & <dl> for lists like navigation and definitions; and <em> and <strong> for italics and bolds.

The creative elements which depict width, colour, images and layout should be applied in a separate CSS document, where we should try to apply styles as natively as possible, so by only using class’s and Id’s in areas of division and irregularity. Segmenting the code into Divisions of Header, footer and Navigation can be applied while making best use of wrapping and the box model techniques (meaning no self closing divisions).

Finally JavaScript can be used to bind behaviour to the documents establishing segmentation of structure, presentation and behaviour considered to be the model-view-controller architecture. Although in respect for JavaScript we should always provide an accessible backup to an onclick event by retuning false and adding a server side operation in a href on an anchor.

Layout

Typically you would expect elements to appear in right to left and top to bottom structure in the code as they do in the creative. However this is not very SEO. Consider the navigation; it will always appear near the top and left on every page. We don’t want to expect Google to churn through it each time just to reach the content (a bit like munching on a jam donut). We would rather have the content as close to the top as possible and then have the template navigation at the bottom. This keeps it fresh and clean. Likewise if required inline (preferably in an external file) JavaScript should not dominate the top, we should have it at the bottom of the page. Restricting of the document can be handled using CSS, as explained here but be sure to use scalable dimensions and relative positioning to maintain accessibility.

Interestingly the subject here has done a bad job or effective separation, the comments mixed, some praise it for its lack of tables where others point out critical flaws like dimensions and lack of semantic XHTML. Here I would say is a good example, but bare in mind it’s an incomplete development, but its parent site now gets to number 1 on Google which uses not all of my explained techniques. Peter Bui discusses and shows of some good examples on his post about SEO.

Rules

The standard rules of XHTML should of course be followed. A Valid page is always going to behave better than an invalid page across devices. But we should also consider practices such as the order and use of headings and titles. Titles should be specific to each page and not be generic, they should be to the point and descriptive of the content in the page and not to long (saw 90 characters with spaces). Meta tags should be relevant and never to many. Every page should make effective use of Headings.

<h1>
possibly the brand or logo
<h2>
the title of the page specific content
<h3>
a subheading and so forth.

We should never skip levels (e.g., <h1> directly to <h3>) and have more than one <h1> or <h2>.

Furthermore we have some of the obvious ones to note that are inline images (only included if the image is relevant to the content and not to the style) should contain descriptive alt tags. Form data should appear in a <fieldset> with a <legend> (I find using an unordered list as well helps layout a form easily). Use semantic class names and Id’s (Orange-Header is not very useful if we want to change the colour, and we should already know it’s a header because its using a heading tag right?) Finally Use tables (try not to nest tables) for tabular data including <thead>, <th>, <tfoot> and a description attribute on the table declaration. There are many more to note which are all in the many of the different guidelines depending on platform and doctype but these are issues I face regularly.

Happy Coding, Please tell me what you think

6 Comments »

  1. Ruth J said,

    March 7, 2008 @ 1:30 pm

    Thanks for this. It’s super-useful!

    Am I right in thinking it’s more from a usability point of view? When clients ask us to SEO something, they mean more than just make it easy for search engines to look through. They mean cram it with key search words, in the places search engines like to look. They want their pages as close to the top of as many natural searches as possible. Our developers seemed hot on putting their keywords in H1, H2 and H3 tags, in links and in navigation as well as in 4-11% of the body copy. Do you think they’re only into keywords in nav when it’s at the top of the code? Or do search engine spiders give precedence to navigation?

    Does this make sense? Am I barking up the wrong tree?

  2. Martina Costello said,

    March 7, 2008 @ 3:57 pm

    I find this really useful from an usability and IA point of view. It gives me a really thorough understanding of the coding standards that are required to be SEO compliant. I can now go forth and provide a set of instructions in my schematics for both coders and copywriters.

    BTW love the jam donut analogy -it really hits the nail on the head. Keep up the good work.

  3. Nick said,

    March 7, 2008 @ 4:34 pm

    Search engines weight things according to the tag which they sit. Items in a

    are less important than when in a because its more likely to be an appropriate keyword match. Likewise with the nav, but as I said we want to disregard the nav as its on every page and thus hardly page specific because that keyword is now on every page.

    The spiders are after the jam at the end of the day (the juicy filling in the doughnut, the quicker they get there the better), after all a doughnut is always the same but sometimes the filling is different, jam.. chocolate etc

    Is my analogy barking mad?

  4. new york health insurance said,

    March 10, 2008 @ 12:11 pm

    I can find many things that I look for here! Thank you very much!

  5. Anthony Frey said,

    March 10, 2008 @ 4:10 pm

    Nice article, I love it. I just had an argument a week ago with one of the tech managers because i said SEO and accessibility almost go hand in hand. By that i ment, acomplishing one usually acomplishes the other, but ofcouse that doesnt go for color and contrast types of accessibility, but for the most part they are very similiar. I further tried to expain that search engines were pretty much just like people with severe disabilities, and coding for one will normally benefit the other. Anyway, thanks for the article!

  6. Peter Bui said,

    April 14, 2008 @ 4:34 am

    Hey there, I noticed that you referenced an article that I wrote on semantic web design. http://peter.pbwebdev.com.au/2008/03/semantic-web-layouts-optimised.html

    I’ve just updated my website using a new CMS.

    Can you update your link please to

    http://peter.pbwebdev.com.au/design/semantic-web-design.html

RSS feed for comments on this post · TrackBack URI

Leave a Comment