This post is mainly aimed at small to medium businesses that are just starting out and are keen to get something going, or have just gone live. I can't tell you how many times I have taught people over the past few years just a handful of strategically important things. So...here goes again, this time in a way that I can now simply refer to. As for my credibility - I would rather not divulge that here, read my Web Site Optimisation Rules and you decide. They are, after all, common sense, and common knowledge....like most things I blog about!
My number 2 rule: Good page & sub-directory names
Reasoning:
1. What is "good"? Good is quite hard to explain concisely. It is a collection of decisions that combine to effectively target your audience, as well as search engine spiders. "Good" should align as closely as possible to how your target audience would think, and how they would submit keywords and phrases in order to find your content, in order to find what you are offering. This is very hard to do - there is a branch of study called "Information Architecture" that is working on this, as are the real search engine scientists. It is simplist for me to illustrate with clear examples..
2. Examples of bad names:
http://your.site.com/i.html
http://your.site.com/b/a/d.html
http://your.site.com/bestpracticeagilesoftwaredevelopment.html
http://your.site.com/agilesoftwaredevelopmentbestpractice.html
3. Examples of good names:
http://your.site.com/best-practice/agile-software-development.html
http://your.site.com/agile-software-development/best-practice.html
4. I chose the good example carefully as I also wanted to illustrate some of the subtleties involved in choosing good names. And this is where Competitive Advantage and a bit of luck truly takes its course. I can imagine someone using a search engine would enter things like:
"best practice for agile software development"
"best practices of agile software development"
as well as
"agile software development best practice"
"agile software development best practices"
Depending on your research, depending on how you interact with your industry, depending on how you speak to your clients and how they in turn speak to you, these are factors that determine how you should name your pages and sub-directories. Of course, if you have a new web site, and you have not had much exposure to your target client base, then you are playing the guessing game, which is okay! Do not panic - make sure that you realise that, and reduce your risk by running experiments and monitoring the results! (see my previous rule about how to measure your web site ROI very simply)
5. Did you notice above that I also replaced the spaces in potential search phrases with "-" in my page and sub-directory names? As much as possible your web site structure must reflect natural language usage....
6. Did you also notice that well chosen sub-directories quickly give visitors insight into what other content might be in a particular sub-directory? Make sure your themes in each of your well structured sub-directories are consistent. Consistency, relating things that are similar, linking them, and linking to external related sites and external related sites linking back to your pages are things that all add up and count in your search engine rating against your competitor web sites. (synergy!)
And that is my Rule 2. I will be uploading the others as time allows!
Thursday, 10 July 2008
Monday, 7 July 2008
Basics of Web Site Optimisation - Rule 1
This post is mainly aimed at small to medium businesses that are just starting out and are keen to get something going, or have just gone live. I can't tell you how many times I have taught people over the past few years just a handful of strategically important things. So...here goes again, this time in a way that I can now simply refer to. As for my credibility - I would rather not divulge that here, read my Web Site Optimisation Rules and you decide. They are, after all, common sense, and common knowledge....like most things I blog about!
My number 1 rule: No email addresses on the web site
Reasoning:
1. SPAM, SPAM, and more SPAM. Any email address on the web site, which is not sitting on some kind of island (most people with a web site actually want to be found...right?), will be picked up by the email scraper web bots that spammers (or their suppliers) use and will subsequently be mail-bombed by them (even though it is illegal)
2. If it happens to be a personal email address, then frequently all the above spamming, or other events such as the person being on leave, or being absent, or leaving the company, will result in potentially very important emails lying in an Inbox for an unacceptable amount of time, and result in a bad image of the company (unacceptable web time is getting less and less almost daily it seems - I would say 1/2 hour these days is pushing the limit for modern web users). The result of closing a spammed-to-death email address account is also a very painful IT process, especially if it is tied to the user's LAN account as frequently is the case.
3. If it happens to be a organisational email address (eg info, help, request), this is slightly better than number 2 above, at least more than 1 (non-administrator) person can access the account should they need to, and such "1 way" email accounts can be created and deleted and easily replaced as they become spammed-to-death.
So what is the better way? I recommend using a standard HTML form (or a handful of them, as per your needs - based on the categorisation of queries that you are hoping will be submitted via your site)
Reasoning:
1. Forms, via the web server behind them, can be set up to email a organisational email address very easily - same benefit as having an email address on the site!
2. You can put a few very simple fields on the form that will help with eventual processing of the query (very useful once things start getting busier, trust me I have a couple of T-shirts on this one - things, if they go as planned, get very busy much quicker than someone can be found to assist!)
3. You can add some very lightweight validation to the form to assist clients to give you the information you need in as few correspondences as possible (again, the busier you get, the less time you have for this, the more time clients need to wait between first submission, and final conclusion)
4. Forms can be submitted by anyone who is browsing your site, whereas email facilities might not be available to someone browsing your site from their phone, internet cafe, library, free kiosk for instance
5. Many people are using web based email accounts these days, and it requires some effort to get your email address over into their web mail client
6. The fastest way to actually get a client to submit something usable to you has to be a competitive advantage - fewer distractions, fewer potential glitches, fewer context switches, fewer Window switches, etc!
7. You get automatic Return On Investment (ROI) tracking as forms can have unique names, and submitted forms can also have unique names. This allows you, by hand, or with basic web traffic reporting systems, to see how many visitors (not visits!) your web site received, how many times your enquiry form was opened (= number of people who considered sending you a query) and compare those figures with how many actually submitted the form - how many times the submitted form was opened. (= visitors that wanted to become your client). e.g.: 1000 visitors, enquiry form opened 100 times, submission form opened 10 times would mean that 1% of your traffic resulted in sales leads. Possible interpretations would be that SEO is attracting the wrong kind of visitor, and/or the enquiry form is too difficult to be used or does not inspire sufficient confidence to be submitted, etc.
8. In all online systems I have worked with or advised, there is always a manager who also wants to have some idea of the amount of work coming in, and how quickly it is processed, and an ability to be able to do something if something goes wrong. Forms can be posted to multiple email addresses - or the email server can create backups and/or copies - all online, all at the manager's finger tips: in his/her Inbox (or rule-based sub folder)
9. The email server can also send auto-responses to the client so long as an email address is entered into a field that can be easily processed (this is good as the potential client will then give you more time than average to follow up with a real response, especially if you send the vital information that the submitted form has been received, will be processed, as soon as possible, between office hours of 8:00 to 18:00 GMT+2, for instance) (and thank you for your submission, we appreciate you, very very very much! thank you, thank you, and by the way, here is another backup email address you can reply to if you do not hear anything within 1 working day, quoting this reference number) (the email server and/or script doing the emailing can also generate the reference tracking number for you)
Nice, I think. This approach has always worked very well for me. Perhaps for you to.
What to do if you absolutely still must have an email address on the web site? And, to be honest, everyone using the forms method above, still does..
1. Create a tidy image of an organisational address, and use that instead
2. It is possible to get "clever" with some javascript to essentially fake or provide the user with a clickable html version of the email address on demand which spam bots can't get to, or less "clever" to generate and then paste into their email client. (there are plenty of places to download and customise such scripts or any javascript programmer could put it together (or download it) for you in a few minutes)
That's the way I do it. There is another way some use:
3. Obfuscate (lightly scramble) the email address so that the scraper-bots can not detect that it is an email address and use that. People try all sorts of techniques, but I am unsure how effective they really are - eg joeATsoapDOTcom, joeRemoveThis@soapRemoveThisToo.com
And that is my Rule 1. I will be uploading the others as time allows!
My number 1 rule: No email addresses on the web site
Reasoning:
1. SPAM, SPAM, and more SPAM. Any email address on the web site, which is not sitting on some kind of island (most people with a web site actually want to be found...right?), will be picked up by the email scraper web bots that spammers (or their suppliers) use and will subsequently be mail-bombed by them (even though it is illegal)
2. If it happens to be a personal email address, then frequently all the above spamming, or other events such as the person being on leave, or being absent, or leaving the company, will result in potentially very important emails lying in an Inbox for an unacceptable amount of time, and result in a bad image of the company (unacceptable web time is getting less and less almost daily it seems - I would say 1/2 hour these days is pushing the limit for modern web users). The result of closing a spammed-to-death email address account is also a very painful IT process, especially if it is tied to the user's LAN account as frequently is the case.
3. If it happens to be a organisational email address (eg info, help, request), this is slightly better than number 2 above, at least more than 1 (non-administrator) person can access the account should they need to, and such "1 way" email accounts can be created and deleted and easily replaced as they become spammed-to-death.
So what is the better way? I recommend using a standard HTML form (or a handful of them, as per your needs - based on the categorisation of queries that you are hoping will be submitted via your site)
Reasoning:
1. Forms, via the web server behind them, can be set up to email a organisational email address very easily - same benefit as having an email address on the site!
2. You can put a few very simple fields on the form that will help with eventual processing of the query (very useful once things start getting busier, trust me I have a couple of T-shirts on this one - things, if they go as planned, get very busy much quicker than someone can be found to assist!)
3. You can add some very lightweight validation to the form to assist clients to give you the information you need in as few correspondences as possible (again, the busier you get, the less time you have for this, the more time clients need to wait between first submission, and final conclusion)
4. Forms can be submitted by anyone who is browsing your site, whereas email facilities might not be available to someone browsing your site from their phone, internet cafe, library, free kiosk for instance
5. Many people are using web based email accounts these days, and it requires some effort to get your email address over into their web mail client
6. The fastest way to actually get a client to submit something usable to you has to be a competitive advantage - fewer distractions, fewer potential glitches, fewer context switches, fewer Window switches, etc!
7. You get automatic Return On Investment (ROI) tracking as forms can have unique names, and submitted forms can also have unique names. This allows you, by hand, or with basic web traffic reporting systems, to see how many visitors (not visits!) your web site received, how many times your enquiry form was opened (= number of people who considered sending you a query) and compare those figures with how many actually submitted the form - how many times the submitted form was opened. (= visitors that wanted to become your client). e.g.: 1000 visitors, enquiry form opened 100 times, submission form opened 10 times would mean that 1% of your traffic resulted in sales leads. Possible interpretations would be that SEO is attracting the wrong kind of visitor, and/or the enquiry form is too difficult to be used or does not inspire sufficient confidence to be submitted, etc.
8. In all online systems I have worked with or advised, there is always a manager who also wants to have some idea of the amount of work coming in, and how quickly it is processed, and an ability to be able to do something if something goes wrong. Forms can be posted to multiple email addresses - or the email server can create backups and/or copies - all online, all at the manager's finger tips: in his/her Inbox (or rule-based sub folder)
9. The email server can also send auto-responses to the client so long as an email address is entered into a field that can be easily processed (this is good as the potential client will then give you more time than average to follow up with a real response, especially if you send the vital information that the submitted form has been received, will be processed, as soon as possible, between office hours of 8:00 to 18:00 GMT+2, for instance) (and thank you for your submission, we appreciate you, very very very much! thank you, thank you, and by the way, here is another backup email address you can reply to if you do not hear anything within 1 working day, quoting this reference number) (the email server and/or script doing the emailing can also generate the reference tracking number for you)
Nice, I think. This approach has always worked very well for me. Perhaps for you to.
What to do if you absolutely still must have an email address on the web site? And, to be honest, everyone using the forms method above, still does..
1. Create a tidy image of an organisational address, and use that instead
2. It is possible to get "clever" with some javascript to essentially fake or provide the user with a clickable html version of the email address on demand which spam bots can't get to, or less "clever" to generate and then paste into their email client. (there are plenty of places to download and customise such scripts or any javascript programmer could put it together (or download it) for you in a few minutes)
That's the way I do it. There is another way some use:
3. Obfuscate (lightly scramble) the email address so that the scraper-bots can not detect that it is an email address and use that. People try all sorts of techniques, but I am unsure how effective they really are - eg joeATsoapDOTcom, joeRemoveThis@soapRemoveThisToo.com
And that is my Rule 1. I will be uploading the others as time allows!
Subscribe to:
Posts (Atom)
