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
