How a website can boost traditional marketing techniques
What is an e-strategy? Good question, I have to admit it is a rather vague notion. One way to describe it is to say that it’s about mixing technology with traditional marketing strategies. As these approaches interconnect, they compliment or magnify each other, thus producing an affect where the whole is greater than the sum of it’s parts.
In more specific terms, an e-strategy is the business strategy applied to an online presence. It generally does not focus on technology comparisons, but rather is geared towards presenting the best possible approach for achieving an organisation’s goals.
Why would a business want to develop an e-strategy? The main reason is because it’s a game plan for how to get the most out of their web presence. The idea is to exploit the Internet and emergent technologies in order to increase revenue or reduce operating costs. A common way of reducing costs would be by automating as many activities as possible. For example; an online book store which does just-in-time printing could send an automatic communiqué directly to the printing company when a book is purchased (the book would then be printed and mailed off to the buyer).
Part of an e-strategy is to make it clear that good technology in itself is not enough, a holistic approach is what is needed. Traditional business techniques also need to be used in order to produce growth and out-do competitors.
As part of this process, a few key questions need to be answered; what role can the Internet play in the business strategy? What is the driving force behind the business? How are customer or target market needs fulfilled? What does the future hold for the business domain and how is change going to be handled?
There are many ways that the Internet can help a business. The examples I have here are by no means an exhaustive list, I’m sure some lateral (creative) thinking would reveal even more options.
Demand Aggregation – as the size of a company’s patronage grows, so to does its ability to secure a good deal for its customers via buying power (e.g. a driving range could buy golf balls in bulk to sell to club members at a better then retail price).
Producer Direct – a business which sells products online can bypass the cost of having a physical store-front. This allows them to pass on savings or ‘perceived value’ to customers (e.g. eBay or Amazon).
Product Re-bundling – having a multitude of customers that grow in an organic manner opens up the potential for related but separate products or services to be offered in combination. This would not normally be possible on a stand-alone basis (e.g. a gym could approach a sports store and strike-up a synergy where-by gym members received discounts on sporting goods).
Customer Self-service – technology can be used to reduce the amount of time staff spend directly interacting with customers for simple tasks or enquiries. A classic example of this is a customer researching a product online rather then phoning a store to ask a shop assistant about the item.
One-to-one Marketing – this strategy emphasises personalising interactions with customers. Having a customer’s full name at the top of an email is a simple implementation of this approach. This increases the likelihood of them actually looking at the email rather then discarding it as junk mail. A more effective usage would be a website where customer demographic information such as age is tracked. This could then be used to target promotional advertising more effectively (e.g. there’s no point showing home loan packages to teenagers).
Channel Integration - this is about having a number of different ways to communicate with your customer or fulfil their needs (e.g. phone, product brochures, direct mail, physical store-fronts, etc). A popular implementation of this approach on websites is to ask a person if they want to receive promotional material via email during a sign-up process.
An e-strategy needs to explain how technology can serve a business’ goals (e.g. to have products on supermarket shelves by the end of the year, to raise skin cancer awareness, etc). This is done by determining how business objectives can be linked to an Internet-based solution such as a website.
Without an e-strategy, technology-based solutions developed reactively may produce short-term benefits, but turn-out to be ineffective and expensive in the long run. For example; if you wanted to develop a mobile-device interface for a social networking website, you could produce BlackBerry and MS Windows Mobile applications, or you could try and capture a far greater audience by targeting just the Symbian OS considering it’s installed on 72% of all smart-phones (Source: www.itwire.com/content/view/14348/127/).
24 September, 2008
16 September, 2008
'Maintenance Blocks' - Managing Change Requests
An equitable system for maintaining and upgrading client work after launch.
What Are ‘Maintenance Blocks’? It’s an idea I developed which is meant to provide a fair system for undertaking bug fixes or upgrades on client work. In simple terms; they are pre-paid units of maintenance.
It never felt quite right to round-up 15 minutes of work to one hour (for the purpose of creating an invoice). However, I wasn’t happy about doing work for free for a client just because it was a small task (e.g. creating a new email account, adding Google Analytics to a website, etc).
One of the major advantages of maintenance blocks for clients is that a lower rate is locked-in for future work. There is also a degree of convenience since invoices aren’t being sent out for small pieces of work. In addition, maintenance blocks are very flexible since they can be used for either bug fixes or upgrades to a client’s existing project.
Maintenance blocks are also about mutual obligation. Having a client pre-pay for maintenance work ahead of time is a sign of good faith. In return, I give a guarantee on turn-around time (generally 48 hours from the time the request is acknowledged). If I don’t respond within the agreed amount of time, the client gets their work done for free.
I designed maintenance blocks to be purchased in ‘packs’, generally eight or sixteen blocks, with each block being equivalent to 15 minutes of work. Depending on the complexity of the task (be it an upgrade or bug fix), varying amounts of blocks are consumed. Generally speaking, a minor change would use 1 block, an intermediate change would consume 2-3 blocks, and a major change will use 4 or more blocks (nb. minor or intermediate changes are most common).
I generally have it so blocks do expire, but the amount of time they stay valid is quite long (e.g. 6 months for eight blocks).
The way a client uses maintenance blocks is quite simple. They would email a request for change via email, I then let the client know how many blocks need to be used for the change and how many maintenance blocks they will have left after the change (e.g. “you have 3 maintenance blocks remaining, the change you are requesting will use 2 of those blocks - leaving you with 1 block”). The client then confirms their agreement or raises any questions they may have.
The system is squarely aimed at small bug fixes or changes. For example; “the positioning of the logo on my website looks funny in Google’s new browser, can you fix it?” or “please add a new menu item and page to my website called 'Customer Feedback'.” The system is not meant to cover major changes (e.g. adding online shopping facilities, re-vamping the layout of a website, etc). Generally, if a change is more then 16 blocks in size (i.e. more then 4 hours), I consider it to be beyond the scope of the maintenance blocks system, and therefore would require a separate contract to be negotiated.
Why do maintenance blocks get used for bug fixes you may ask? When a project is still under ‘software warranty’ (typically, for a period of 6 months after completion), blocks don’t get consumed for bug fixes. But after the warranty period has expired, I do charge clients for fixes on their projects even if they are my fault. With the work I do, most bugs are found during the QA cycle, with few emerging past the 6 month point (but it still can happen).
Lastly, I don’t ‘force’ clients to use the maintenance block system if they don’t want to. The alternative is to negotiate a charge-out-rate and turn-around time whenever work needs to be done. At it’s core, the system was created to make everyones' life easier. Costs are settled before-hand, thus allowing us to get on with what’s important; the work.
What Are ‘Maintenance Blocks’? It’s an idea I developed which is meant to provide a fair system for undertaking bug fixes or upgrades on client work. In simple terms; they are pre-paid units of maintenance.
It never felt quite right to round-up 15 minutes of work to one hour (for the purpose of creating an invoice). However, I wasn’t happy about doing work for free for a client just because it was a small task (e.g. creating a new email account, adding Google Analytics to a website, etc).
One of the major advantages of maintenance blocks for clients is that a lower rate is locked-in for future work. There is also a degree of convenience since invoices aren’t being sent out for small pieces of work. In addition, maintenance blocks are very flexible since they can be used for either bug fixes or upgrades to a client’s existing project.
Maintenance blocks are also about mutual obligation. Having a client pre-pay for maintenance work ahead of time is a sign of good faith. In return, I give a guarantee on turn-around time (generally 48 hours from the time the request is acknowledged). If I don’t respond within the agreed amount of time, the client gets their work done for free.
I designed maintenance blocks to be purchased in ‘packs’, generally eight or sixteen blocks, with each block being equivalent to 15 minutes of work. Depending on the complexity of the task (be it an upgrade or bug fix), varying amounts of blocks are consumed. Generally speaking, a minor change would use 1 block, an intermediate change would consume 2-3 blocks, and a major change will use 4 or more blocks (nb. minor or intermediate changes are most common).
I generally have it so blocks do expire, but the amount of time they stay valid is quite long (e.g. 6 months for eight blocks).
The way a client uses maintenance blocks is quite simple. They would email a request for change via email, I then let the client know how many blocks need to be used for the change and how many maintenance blocks they will have left after the change (e.g. “you have 3 maintenance blocks remaining, the change you are requesting will use 2 of those blocks - leaving you with 1 block”). The client then confirms their agreement or raises any questions they may have.
The system is squarely aimed at small bug fixes or changes. For example; “the positioning of the logo on my website looks funny in Google’s new browser, can you fix it?” or “please add a new menu item and page to my website called 'Customer Feedback'.” The system is not meant to cover major changes (e.g. adding online shopping facilities, re-vamping the layout of a website, etc). Generally, if a change is more then 16 blocks in size (i.e. more then 4 hours), I consider it to be beyond the scope of the maintenance blocks system, and therefore would require a separate contract to be negotiated.
Why do maintenance blocks get used for bug fixes you may ask? When a project is still under ‘software warranty’ (typically, for a period of 6 months after completion), blocks don’t get consumed for bug fixes. But after the warranty period has expired, I do charge clients for fixes on their projects even if they are my fault. With the work I do, most bugs are found during the QA cycle, with few emerging past the 6 month point (but it still can happen).
Lastly, I don’t ‘force’ clients to use the maintenance block system if they don’t want to. The alternative is to negotiate a charge-out-rate and turn-around time whenever work needs to be done. At it’s core, the system was created to make everyones' life easier. Costs are settled before-hand, thus allowing us to get on with what’s important; the work.
09 September, 2008
Managers, Programmers, and Designers
How managers interact with technical staff to produce software.
Depending on the structure of your organization, the project manager is most likely the person who interacts with the broadest range of stake-holders. Sure the managing director will intermingle with project managers, business development, maybe even the client at early stages. But a project manager will interact with all these people and more; most notably, technical staff such as programmers and graphic designers. And let’s not forget the client; a project manager will probably spend the largest amount of time with them compared to anyone else.
Every now-and-then someone comes along with a ground breaking theory or universal law that’s so simple its mind-blowing; Maslow’s Hierarchy of Needs, Covey's 7 Habits of Highly Effective People, and of course the three business personalities described in Michael Gerber’s classic book The E-Myth (i.e. entrepreneur, manager, and technician).
For those not familiar with the book, what follows is a brief summary of the personality types:
The E-Myth is about much more then just these personality types. It’s about the pitfalls of starting your own business, and how to build a business which allows you to live the kind of lifestyle you want.
We are all combinations of these characters to different degrees. Some of us are half manager half technician, others are very entrepreneurial, and so on. Understanding these archetypes can be very helpful when working in a team environment.
I am about to make some generalizations, and as with most generalizations they should be taken with a grain of salt since there are always exceptions. Programmers and designers commonly fit squarely into the role of technician, perhaps with a splash of manager (nb. by designer, I mean graphic designer).
There are a number of contrasts between programmers and designers, even though both are fundamentally creative disciplines. Perhaps this is because the work of a designer is visual and more apparent to users, whilst a programmer’s output is functional and more ‘under the hood’.
I interviewed a professional graphic designer to find out her thoughts on the interaction between managers and technical staff, here is what I found:
A pattern I have noticed with graphic designers which does not seem as prevalent in programmers is that it can be quite an upheaval to suggest a change, or even worse, to go ahead and make a change without their prior knowledge (a move rarely conducive to harmony within a team). Perhaps the reason this phenomenon is more prominent in designers is because artistic endeavour is so subjective; what looks good to one person may look uninspiring to another. When a programmer is asked to make a change in functionality, it generally has a tangible and visible affect, something people can agree on.
When working directly with designers, I will often make suggestions based on my strong usability background. Even though I have seen graphic designers violate well established best-practice usability guidelines (e.g. using ‘|’ as a breadcrumb hierarchy separator instead of ‘->’), I never insist on a change. What I generally say is something along these lines: “have you thought about changing this to this because...?” If they don’t want to change it, I don’t push the issue.
To me it’s beside the point whether I think I know better, the designer’s work is their dominion and their responsibility. The only time I would revisit the topic is if the client wasn’t happy with it, then I would come back to the designer and say “well, regardless of whether the change is right or wrong, the client wants it the way they want it”.
“Those convinced against their will are of the same opinion still."
- Dale Carnegie
- Dale Carnegie
Depending on the structure of your organization, the project manager is most likely the person who interacts with the broadest range of stake-holders. Sure the managing director will intermingle with project managers, business development, maybe even the client at early stages. But a project manager will interact with all these people and more; most notably, technical staff such as programmers and graphic designers. And let’s not forget the client; a project manager will probably spend the largest amount of time with them compared to anyone else.
Every now-and-then someone comes along with a ground breaking theory or universal law that’s so simple its mind-blowing; Maslow’s Hierarchy of Needs, Covey's 7 Habits of Highly Effective People, and of course the three business personalities described in Michael Gerber’s classic book The E-Myth (i.e. entrepreneur, manager, and technician).
For those not familiar with the book, what follows is a brief summary of the personality types:
The entrepreneur's work is strategic in nature, involves focusing on the future and developing a vision of where they want to take the business.
The manager's work is both strategic and tactical. The manager's focus is on the present and achieving results through others. They are concept to reality facilitators.
The technician follows the guidance of the manager to get the work done. They focus on the present and are hands-on.
The manager's work is both strategic and tactical. The manager's focus is on the present and achieving results through others. They are concept to reality facilitators.
The technician follows the guidance of the manager to get the work done. They focus on the present and are hands-on.
The E-Myth is about much more then just these personality types. It’s about the pitfalls of starting your own business, and how to build a business which allows you to live the kind of lifestyle you want.
We are all combinations of these characters to different degrees. Some of us are half manager half technician, others are very entrepreneurial, and so on. Understanding these archetypes can be very helpful when working in a team environment.
I am about to make some generalizations, and as with most generalizations they should be taken with a grain of salt since there are always exceptions. Programmers and designers commonly fit squarely into the role of technician, perhaps with a splash of manager (nb. by designer, I mean graphic designer).
There are a number of contrasts between programmers and designers, even though both are fundamentally creative disciplines. Perhaps this is because the work of a designer is visual and more apparent to users, whilst a programmer’s output is functional and more ‘under the hood’.
I interviewed a professional graphic designer to find out her thoughts on the interaction between managers and technical staff, here is what I found:
Q. “How do designers differ from programmers?”
A. “Programming is objective, design is subjective. Designers work with imagination [whilst programmers are more academic].”
Q. “How should a manager go about asking a designer to make changes to their work?”
A. “[Managers should refrain from] involving themselves in the design process. Changes need to make sense and be based on solid reasoning. [Berating comments should be avoided].”
Q. “How can a manager’s input be counter-productive to the design process?”
A. “There is nothing more frustrating then a manager trying to be a designer. [There needs to be] concrete reasoning behind the suggested correction.”
Q. “What are the most common issues between designers and managers?”
A. “When a manager shuts down creative flow by being too overbearing. [Micro-managing or meddling] is a common problem.”
Q. “Should a manager’s opinion on visual design hold less weight then a designer’s?”
A. “Unless working in a small business, [managers don’t] need to involve themselves in design. Opinions and feedback are always welcome, [but emotive recommendations should be kept to a minimum].”
Q. “Would it bother you if someone changed your work without asking you first?”
A. “[I would] not be happy. [Managers wouldn’t like their processes being bypassed without being consulted first].”
- Vera Babenko, Lead Web Designer, ANZ Bank.
Note: I have shortened or paraphrased the interviewee’s answers. The changes have been checked by the interviewee to ensure the original message has not been lost.
A. “Programming is objective, design is subjective. Designers work with imagination [whilst programmers are more academic].”
Q. “How should a manager go about asking a designer to make changes to their work?”
A. “[Managers should refrain from] involving themselves in the design process. Changes need to make sense and be based on solid reasoning. [Berating comments should be avoided].”
Q. “How can a manager’s input be counter-productive to the design process?”
A. “There is nothing more frustrating then a manager trying to be a designer. [There needs to be] concrete reasoning behind the suggested correction.”
Q. “What are the most common issues between designers and managers?”
A. “When a manager shuts down creative flow by being too overbearing. [Micro-managing or meddling] is a common problem.”
Q. “Should a manager’s opinion on visual design hold less weight then a designer’s?”
A. “Unless working in a small business, [managers don’t] need to involve themselves in design. Opinions and feedback are always welcome, [but emotive recommendations should be kept to a minimum].”
Q. “Would it bother you if someone changed your work without asking you first?”
A. “[I would] not be happy. [Managers wouldn’t like their processes being bypassed without being consulted first].”
- Vera Babenko, Lead Web Designer, ANZ Bank.
Note: I have shortened or paraphrased the interviewee’s answers. The changes have been checked by the interviewee to ensure the original message has not been lost.
A pattern I have noticed with graphic designers which does not seem as prevalent in programmers is that it can be quite an upheaval to suggest a change, or even worse, to go ahead and make a change without their prior knowledge (a move rarely conducive to harmony within a team). Perhaps the reason this phenomenon is more prominent in designers is because artistic endeavour is so subjective; what looks good to one person may look uninspiring to another. When a programmer is asked to make a change in functionality, it generally has a tangible and visible affect, something people can agree on.
When working directly with designers, I will often make suggestions based on my strong usability background. Even though I have seen graphic designers violate well established best-practice usability guidelines (e.g. using ‘|’ as a breadcrumb hierarchy separator instead of ‘->’), I never insist on a change. What I generally say is something along these lines: “have you thought about changing this to this because...?” If they don’t want to change it, I don’t push the issue.
To me it’s beside the point whether I think I know better, the designer’s work is their dominion and their responsibility. The only time I would revisit the topic is if the client wasn’t happy with it, then I would come back to the designer and say “well, regardless of whether the change is right or wrong, the client wants it the way they want it”.
01 September, 2008
Bare Minimum On-Page SEO
A checklist of basic Search Engine Optimization considerations
In 2004 I was part of a team that developed a shopping website complete with credit card payment facilities. The site allowed people to trade-in their old Xbox or Playstation 2 games as well as buy new ones.
Fast forward to 2007. The client we produced the shopping site for contacts us and says the website has serious SEO issues. Three years had passed since I worked on the site, so I needed to go back and have a look at it again. Sure enough, the site did in fact suffer from a number of SEO short-comings. For example, it didn’t show the product’s name in the browser title.
Because so much time had passed, there was no obligation to go back and fix it (I wasn’t even at that company anymore). The result; the site closed down since it had no chance of challenging its competitors in terms of search engine ranking. The client was not willing to pay to have the site upgraded either.
An unfortunate chain of events, but in the client’s mind, we had 'dropped the ball' on this one. At the time, a SEO checklist would of been handy. Just a basic list of the bare minimum on-page SEO we needed to do in order to call ourselves professionals. In the last few years, I have developed just such a list. I periodically update it to keep current with SEO trends.
I should quickly explain what is meant by On-page Optimisation. Basically, these are things a programmer can do in code to improve a site’s chances of ranking high on search engines. Off-page Optimisation would be strategies like negotiating reciprocal linking with another popular website that is complimentary to what you do (e.g. website A sells posters, website B sells frames, both companies could improve their search engine ranking by promoting each other).
I don’t claim to be an expert in SEO, I have however been lucky enough to work with one, so I know what the real thing looks like. The list I use is quite simple and only takes about 10-15 minutes to run through.
Obviously there is no shortage of SEO articles on the web, but I’ve found that they are often prescriptive; in that they tell you what you should do, but not why you should do it. So I will attempt to explain the reasoning behind the various SEO safeguards on the checklist.
HTML frames aren’t used - other then being very old school (circa 1997), search engines don’t crawl frame-based sites very well (some like AltaVista ignore the site completely). There are also usability issues with frames (i.e. screen readers may have trouble interpreting them).
There's no significant content contained inside Flash – obviously, if you have text embedded inside a Flash animation, search engines wont be able to get to it.
The navigation mechanism doesn't use JavaScript - search engines have trouble traversing navigation mechanisms which employ JavaScript, the result is most of the site wont be spidered (HTML lists formatted with CSS are commonly used instaed).
A sitemap is available if JavaScript or Flash navigation are present – if you really must use Flash or JavaScript-based navigation, then a hyperlink to a sitemap will help search engines successfully complete their mission.
There is minimal redundant HTML tags - if you want a good example of this, just take a look at what Microsoft FrontPage produces, it does things like encase images in bold tags. Proper use of CSS will also help minimise the amount of HTML tags needed.
If there's a lot of JavaScript, it’s kept in an external include file - this is because search engines give more weight to content appearing towards the top of the page. By moving JavaScript, or CSS for that matter, to external files, you are increasing the prominence of your content.
The amount of text content exceeds the amount of HTML code – if a website is bloated with loads of HTML code, it becomes difficult for a search engine to figure out what a page is all about. In fact, a search engine will actually give up and move on if it finds a page is to difficult to traverse.
Each page has a unique browser page title – this is considered one of the most important factors for high page ranking. There is also a connection between the title and the content of the page (e.g. if the page title is ‘The Simpsons - Season 1 DVD’ then the page should actually focus on that topic).
Page titles aren't longer then 6-10 words - a web page title that is too long is almost as bad as no title at all. Overly long titles don’t help readability. I have also seen material which says search engines truncate long titles. Keyword density also comes into play here (i.e. having keywords amongst lots of other non-keywords results in lower keyword density) .
Page titles are keyword rich - keyword density is a measure of page relevance. Keywords appearing in page titles have a greater weighting then those appearing further down the page (as a rule of thumb, 5-10 keywords should be concentrated on).
Standard HTML heading tags are used (i.e. H1, H2, H3) – using heading elements is a method for giving prominence to keywords. They help make it clear to search engines what the topic of a section is meant to be.
Images have short yet descriptive ALT tags - as a rule of thumb, the ALT tag should describe the image in a way that would make sense to a visitor using a voice-based browser. Sensible ALT tags also help a search engine understand the structure and content of your site (e.g. a search engine can’t ‘see’ a picture of a balloon, you have to tell it what it is).
URLs aren't overly long (i.e. under 100 characters) - some say short URLs have no impact on page ranking, and that it’s more important to have keyword rich URLs. But, according to Matt Cutts of Google, if there are more then 5 words in a URL, “[Google] algorithms typically will just weight those words less and just not give you as much credit.” Short URLs also tend to get about twice as many click-throughs on search result pages.
Hyphens are used in page file names rather then underscores – there is no penalty for using underscores, but Google interprets hyphens as separating words. For example, if you have a page called ‘posters_frames.aspx’ then it can only be found if a person searches for ‘posters_frames’, if you have a page called ‘posters-frames.aspx’, then it can be found by searching for either ‘posters’ or ‘frames’.
The domain name is relevant to the business/website – a website about posters should have the word posters somewhere in the domain name (e.g. www.posters.com). Having a number of major keywords in the URL is even better (e.g. www.poster-framing.com).
Physical page file names are short, descriptive, and keyword rich – search engines often give ranking preference to pages with keyword rich file names (e.g. www.../post-frames-pricing.aspx is much better then www.../article.aspx?id=19).
Metatags are used - the general consensus among SEO experts is that metatags are dead with regard to their role in page ranking (i.e.
Hyperlinks make use of the title tag - the title attribute can inform a search engine about the connection between a link and a relevant phrase (e.g. title="Online frames")
No pages are more then four clicks deep (max. 4 tier-navigation) – as far as search engines are concerned, less clicks means higher importance (i.e. important information is easier to reach). On a related topic, having files deep within the directory structure can also be detrimental.
Page file size does not exceed 150 kilobytes – web pages greater then 150 KB are generally not cached. Search engines do this in an effort to reduce index size, bandwidth requirements and server utilization. Also consider that small file size means faster downloads for visitors.
Are there other significant SEO checks you could do? Definitely. For instance; directory naming, keyword rich hyperlinks, keyword prominence (i.e. the order in which keywords appear), time-stamping content, HTML/CSS validity, and the list goes on. There is nothing to stop you from expanding my list.
If you really want to get deep into the topic, grab yourself a big cup of coffee and take a look at SEOmoz’s article Beginner’s Guide to SEO, its a good place to start.
In 2004 I was part of a team that developed a shopping website complete with credit card payment facilities. The site allowed people to trade-in their old Xbox or Playstation 2 games as well as buy new ones.
Fast forward to 2007. The client we produced the shopping site for contacts us and says the website has serious SEO issues. Three years had passed since I worked on the site, so I needed to go back and have a look at it again. Sure enough, the site did in fact suffer from a number of SEO short-comings. For example, it didn’t show the product’s name in the browser title.
Because so much time had passed, there was no obligation to go back and fix it (I wasn’t even at that company anymore). The result; the site closed down since it had no chance of challenging its competitors in terms of search engine ranking. The client was not willing to pay to have the site upgraded either.
An unfortunate chain of events, but in the client’s mind, we had 'dropped the ball' on this one. At the time, a SEO checklist would of been handy. Just a basic list of the bare minimum on-page SEO we needed to do in order to call ourselves professionals. In the last few years, I have developed just such a list. I periodically update it to keep current with SEO trends.
I should quickly explain what is meant by On-page Optimisation. Basically, these are things a programmer can do in code to improve a site’s chances of ranking high on search engines. Off-page Optimisation would be strategies like negotiating reciprocal linking with another popular website that is complimentary to what you do (e.g. website A sells posters, website B sells frames, both companies could improve their search engine ranking by promoting each other).
I don’t claim to be an expert in SEO, I have however been lucky enough to work with one, so I know what the real thing looks like. The list I use is quite simple and only takes about 10-15 minutes to run through.
Obviously there is no shortage of SEO articles on the web, but I’ve found that they are often prescriptive; in that they tell you what you should do, but not why you should do it. So I will attempt to explain the reasoning behind the various SEO safeguards on the checklist.
HTML frames aren’t used - other then being very old school (circa 1997), search engines don’t crawl frame-based sites very well (some like AltaVista ignore the site completely). There are also usability issues with frames (i.e. screen readers may have trouble interpreting them).
There's no significant content contained inside Flash – obviously, if you have text embedded inside a Flash animation, search engines wont be able to get to it.
The navigation mechanism doesn't use JavaScript - search engines have trouble traversing navigation mechanisms which employ JavaScript, the result is most of the site wont be spidered (HTML lists formatted with CSS are commonly used instaed).
A sitemap is available if JavaScript or Flash navigation are present – if you really must use Flash or JavaScript-based navigation, then a hyperlink to a sitemap will help search engines successfully complete their mission.
There is minimal redundant HTML tags - if you want a good example of this, just take a look at what Microsoft FrontPage produces, it does things like encase images in bold tags. Proper use of CSS will also help minimise the amount of HTML tags needed.
If there's a lot of JavaScript, it’s kept in an external include file - this is because search engines give more weight to content appearing towards the top of the page. By moving JavaScript, or CSS for that matter, to external files, you are increasing the prominence of your content.
The amount of text content exceeds the amount of HTML code – if a website is bloated with loads of HTML code, it becomes difficult for a search engine to figure out what a page is all about. In fact, a search engine will actually give up and move on if it finds a page is to difficult to traverse.
Each page has a unique browser page title – this is considered one of the most important factors for high page ranking. There is also a connection between the title and the content of the page (e.g. if the page title is ‘The Simpsons - Season 1 DVD’ then the page should actually focus on that topic).
Page titles aren't longer then 6-10 words - a web page title that is too long is almost as bad as no title at all. Overly long titles don’t help readability. I have also seen material which says search engines truncate long titles. Keyword density also comes into play here (i.e. having keywords amongst lots of other non-keywords results in lower keyword density) .
Page titles are keyword rich - keyword density is a measure of page relevance. Keywords appearing in page titles have a greater weighting then those appearing further down the page (as a rule of thumb, 5-10 keywords should be concentrated on).
Standard HTML heading tags are used (i.e. H1, H2, H3) – using heading elements is a method for giving prominence to keywords. They help make it clear to search engines what the topic of a section is meant to be.
Images have short yet descriptive ALT tags - as a rule of thumb, the ALT tag should describe the image in a way that would make sense to a visitor using a voice-based browser. Sensible ALT tags also help a search engine understand the structure and content of your site (e.g. a search engine can’t ‘see’ a picture of a balloon, you have to tell it what it is).
URLs aren't overly long (i.e. under 100 characters) - some say short URLs have no impact on page ranking, and that it’s more important to have keyword rich URLs. But, according to Matt Cutts of Google, if there are more then 5 words in a URL, “[Google] algorithms typically will just weight those words less and just not give you as much credit.” Short URLs also tend to get about twice as many click-throughs on search result pages.
Hyphens are used in page file names rather then underscores – there is no penalty for using underscores, but Google interprets hyphens as separating words. For example, if you have a page called ‘posters_frames.aspx’ then it can only be found if a person searches for ‘posters_frames’, if you have a page called ‘posters-frames.aspx’, then it can be found by searching for either ‘posters’ or ‘frames’.
The domain name is relevant to the business/website – a website about posters should have the word posters somewhere in the domain name (e.g. www.posters.com). Having a number of major keywords in the URL is even better (e.g. www.poster-framing.com).
Physical page file names are short, descriptive, and keyword rich – search engines often give ranking preference to pages with keyword rich file names (e.g. www.../post-frames-pricing.aspx is much better then www.../article.aspx?id=19).
Metatags are used - the general consensus among SEO experts is that metatags are dead with regard to their role in page ranking (i.e.
Hyperlinks make use of the title tag - the title attribute can inform a search engine about the connection between a link and a relevant phrase (e.g. title="Online frames")
No pages are more then four clicks deep (max. 4 tier-navigation) – as far as search engines are concerned, less clicks means higher importance (i.e. important information is easier to reach). On a related topic, having files deep within the directory structure can also be detrimental.
Page file size does not exceed 150 kilobytes – web pages greater then 150 KB are generally not cached. Search engines do this in an effort to reduce index size, bandwidth requirements and server utilization. Also consider that small file size means faster downloads for visitors.
Are there other significant SEO checks you could do? Definitely. For instance; directory naming, keyword rich hyperlinks, keyword prominence (i.e. the order in which keywords appear), time-stamping content, HTML/CSS validity, and the list goes on. There is nothing to stop you from expanding my list.
If you really want to get deep into the topic, grab yourself a big cup of coffee and take a look at SEOmoz’s article Beginner’s Guide to SEO, its a good place to start.
Subscribe to:
Posts (Atom)