Yahoo! Keyword Selector Tool

As part of my site redesign plan, I decided to do some research on keywords. The first one I tried was Yahoo’s. Yahoo! Has a tool called “Keyword Selector Tool” that gives information on related searches that include your term and also the number of times that term was searched for during the last month. When I first built my site, I had assumed that important keywords would be “Psychotherapy” and “Atlanta”. I didn’t really need a large or a wide audience, but I did need for people wanting a therapist in Atlanta to be able to find me.

I entered “psychotherapy” in the Keyword Selector Tool. There had been 34053 searches for “psychotherapy” in January, 2007. The related terms were interesting. Many of them were things like “theory and practice of . . . “ which probably represented students and/or researches looking for resources. Others were things like “the complete adult treatment planner” which probably represented other clinicians looking for resources.

Then I entered “psychotherapy Atlanta” and “psychotherapy in Atlanta, Ga” and was surprised to find that NO one had searched for either of those terms in January, 2007. Hmm. I have some work to do here. The keywords I have been trying to promote for my site aren’t ones that people search for.

I tried “psychologist”. 102454 searches in January. Now we’re getting somewhere. Evidently people search for the word “psychologist” almost 3 times more than they search for psychotherapy. And also, many of the people who do search for the term psychotherapy are other professionals, which isn’t the audience I hope to target. Hey! And 586 people searched for “psychologist Atlanta”! Here’s another thing that surprised me – only 28 people searched for “psychologist in Atlanta” which suggests that most people are computer saavy enough to know that you don’t have to list all the little words when you do a search.

NicheBot

I decided to compare the results I got on Yahoo!’s Keyword Selector Tool with other similar tools. I went to NicheBot and frankly, I was so confused and turned off by their site that I left in frustration after about 15 minutes of poking around. It’s VERY wordy and looks like spam. Sort of hard to take it seriously even though it’s supposed to have a good reputation. Every time I clicked on one of their tools (and they have a wide variety), I got a page wanting me to log in. That’s cool – I was willing to do that – but when I clicked on the link to register, the page was totally overwhelming. Just for fun, I copied it and put it into a Word doc. Turned out to be 26 pages and over 12,300 + words. I have no idea what that page (or rather, those 26 pages) were trying to tell me. I left the site and decided to move on to WordTracker.

WordTracker

Ah. WordTracker is like a soothing balm after NicheBot. The site looks professional and right up top and easy to see is a “Take a Free Trial” link. I have to admit I feel a bit of trepidation when I see that they, too, want me to sign up. However, they assure me that they won’t bombard me with email and their site looks pretty respectable so I take the plunge.

I am not disappointed. WordTracker’s goal seems to be to help me find words that are related to my keywords. I entered “psychotherapy” and got this list of related keywords:

1. psychotherapy
2. therapy
3. psychology
4. Psychotherapy
5. mental health
6. therapist
7. psychiatry
8. counseling
9. psychologist
10. depression
11. psychotherapist
12. anxiety
13. family therapy
14. trauma
15. Depression

Clicking on the various terms on the list confirms that people search for “psychology” (1811 Dogpile & Metacrawler searches in the last 90 days) more than “psychotherapy” (222 similar searches). Also, “psychologist” got 540 hits.

This has been an extremely helpful exercise and one I wouldn’t have thought to do on my own. Basically, I learned that the keywords I thought might bring me the most hits were a bit off-track, AND I got a good idea of which ones to try instead.

One thing I ran across while looking for the best way to minimize search engine dips when doing site redesigns is the notion of a 301 redirect. I had never heard of a 301 before but the more deeply I dug into my research, the more it became clear that I was going to have to have at least a preliminary idea of what a 301 is.

Basically, a 301 redirect is some code you can put in your .htaccess file for servers running Apache. It tells spiders that a page has moved permanently, giving both the old and new URLs. 301s can be used for entire sites or for specific files within a site.

People seem to agree that a 301 is the best way to go when changing domain names or relocating or renaming certain pages on your site. With domain name changes, an older domain name will generally fare better than a newer one, but even so, having a 301 in place will help minimize the impact of the change.

One solution to this that might be the best of both worlds might be to go ahead and build the new site, 301 the new pages to the old, wait a year, then 301 the old pages to the new. For example, for my page

http://www.bend-in-the-river.com/qapersonality.html

I could build basically the same page in my new site (with the domain name alias reversed as discussed in previous posts), and, to help with findability, change the URL to

http://www.susanlitton.com/personality-disorders-questions.html.

I could then put a 301 on the susanlitton page to redirect it to the bend-in-the-river page. After a year, I could switch it: 301 the bend-in-the-river page to the susanlitton page.

Writing 301s doesn’t appear to be difficult. For specifics on how to write the code, I found this article helpful:

Giving search engine spiders direction with a 301 redirect

I’ve had fun and a fair amount of success in tracking down the answers to my questions about how a total overhaul of my site will affect my search engine rankings. In some cases, the answers are straightforward; in other cases, an answer has lead to another question. Here’s what I have so far:

Q: I’ve been wanting to transfer my site to a different hosting company but I haven’t known how (or if) that will affect my site’s search engine ratings.

A: The answer to this seems to be “No”. That answer told me an important piece of information I hadn’t had, namely that search engines search by domain name, not IP address.

Q: When I first created the site, the domain name I chose was bend-in-the-river.com. I published the site with that domain and then a bit later, decided to also use susanlitton.com. Since the site was already up, I ended up putting susanlitton.com as an alias. I’d like to switch that out — have susanlitton.com as the main domain name and bend-in-the-river as the alias. Will that change affect my ratings?

A: A tentative answer to this seems to be “Yes” with the added bit of info that an older domain will fare better than a newer domain. However, there seemed to be some disagreement and/or lack of clarity about how an alias actually works. I solved this dilemma by writing to my hosting company. Here’s their response:

The alias works via redirection from the zone records.
Zone records are basically a table that resolves domain names to i.p. addresses.
Thus, susanlitton.com has a zone record that tells servers looking for susanlitton.com to go to bend-in-the-river.com. The advantage of having an alias is that all e-mails going to susanlitton.com get forwarded to bend-in-the-river.com.

To show it visually…

bend-in-the-river.com has 66.113.130.214 as it’s i.p. address.

susanlitton.com also has 66.113.130.214 as it’s i.p. address.

I don’t know if all hosting companies do an alias this way, but I was happy to at least see how one company handles it. A solution to this concern seems to be to use a 301 redirect. More about this in another post.

Q: I also thought that at some point, I’d like to convert the site from HTML to PHP, but again, I haven’t known if that would mess things up.

A: Again, this question got a bit of a mixed review. However, people seem to agree that to a search engine, index.php is seen as the same as index.html. If you have any doubts, though, it seems that adding the trailing slash at the end of the URL will clear it up as well as possibly speed up your site a bit. (See waferbaby’s Slash Forward (Some URLs are Better Than Others))

Q: If I decide to include the site in my portfolio, it’s going to need major overhaul. In fact, although the content and the overall site architecture are still OK and I’d keep most of the images, I’d probably have to do pretty much everything else from scratch. How will that affect the ratings?

A: Short answer is that there will be a dip. Again, a 301 redirect will help here and I’ll explore that in my second post tonight.

Q: I’d like to use some of the tips and tools we’ve been studying in class to find out all I can about what is and what isn’t working to help people find my site.

A: The only thing I’ve done on this so far is sign up for Mint. I think it will be way cool to log some of these early stats and compare them throughout the process of my redesign. But see . . . even this brings up a question for me. I signed up for Mint using the main domain (www.bend-in-the-river.com). Since I now know that my alias has the same IP address, will Mint automatically give me stats for both or do I need to buy a separate package for www.susanlitton.com? I haven’t had a chance to look at Mint yet or figure out how to use it so hopefully when I crack it open, that answer will be obvious.

The first step in applying what we’re learning about findability to my psychotherapy site seems to be to compare my site to the nuts and bolts findability techniques. No tools or analytics or cool stuff yet, just the basics:

The Good

• The site has a lot of content and the content tends to be fairly keyword rich. This is largely due to a 17-page Questions & Answers section.
• The titles of each page start with “Psychotherapy in Atlanta, GA: Susan C. Litton, Ph.D. — ” and then have the name of that section, e.g., Philosophy of Therapy, Articles, Questions & Answers: Attachment Disorders, Questions & Answers: Personality Disorders, etc.
• The URLs contain some form of the main word for each page, e.g., the URL for the Philosophy of Therapy page is http://www.susanlitton.com/philosophy.html.
• I built another psychotherapy site for all the therapists in our practice and my personal page on that site includes a back link to my main site.
• I have links to my site in a signature I use for a mental health message board I monitor for iVillage.com.
• There are meta tags for both keywords and descriptions for each page on the site.
• There are a fair number of internal links on the site and the text of the links tend to be keywords. Again, the best example of this tends to be on questions pages, e.g., Abuse Questions.

The Bad

• With a couple of minor exceptions, the only changes I’ve made in content to the site are the yearly updates to the copyright date. There have been years that I haven’t even gotten around to doing that.
• The URLs could be done a lot better. For example, in the Questions & Answers area, although the main keyword for the page does appear in the URL, the keyword for each question page is prefaced with “qa” and the keyword for each answer page is prefaced with “ans”. For example, the URL for the page of questions pertaining to abuse is:

• Headers for each page are graphics and although they do have ALT tags, the anchor tags don’t have title attributes.
• The layout was done with tables and the tags have none of the attributes that would help search engines locate content.
• There’s no sitemap.

The Downright Ugly

• The home page is in Flash. There is a link on the home page to a non-Flash version but I don’t know how effective it is.
• The site doesn’t validate. There’s some real scary stuff in there.
• The site doesn’t even give a nod toward accessibility standards.

As you can see, the site needs some serious help. Stay tuned next week for the upcoming installment in this findability project.

Our websites for this class have to meet Priority One accessibility standards. I didn’t know what those were so I decided to write a post about them. The first Google article I found was for the w3c, which is probably as it should be. However, trying to decipher those seemed a bit overwhelming so I looked for a site that had them broken down a bit. Found one! A site called The HTML Writers Guild has their own interpretation of the Priority One checkpoints and they seem to mirror the w3c standards but are easier to understand. Here’s their list followed by my explanations:

• Provide text equivalents for non-text elements.

Use alt, longdesc, etc. for images, imagemap areas, multimedia, etc.

• Don’t rely solely upon color.

Color useage is encouraged but you should also use strong tags or something else to identify text marked by a color change.

• Identify language changes.

Use the LANG attribute (and probably the SPAN element) to mark language changes. An example is:

<span lang=”fr”>Cette phrase est en français</span>.

• Make sure pages are usable without style sheets.>

Use of CSS is encouraged but you should check to make sure your pages still present well (and in order) when the CSS is turned off.

• Update equivalents for generated content.

If you have dynamic content, make sure images and other related items are in synch with the content.

• Don’t make the screen flicker.

Period.

• Use plain, understandable English.

If you use a technical term or jargon, provide a reference link.

• Use client-side imagemaps, not server-side.

“Server-side imagemaps may be used in addition to client-side maps, but should never replace them. A text equivalent list of links should be provided for all imagemaps.”

• Use HTML 4.0 table markup on data tables.

This one is a biggie and I’m not going to detail it here. In general, though, it means using stuff like THEAD, TBODY, COLGROUP, CAPTION etc. You can read about it in the HTML 4.0 Specification.

• Frames should have NOFRAMES and TITLEs.

(If you use frames)

• Don’t rely solely upon scripts and applets.

An example here is that if you’re using client-side validation for forms, make sure you also have a server-side script for users with JavaScript turned off.

• As a last resort, make an alternate page.

Try to avoid this if possible. The author of the HTML Writers Guild site noted that often, alternate pages aren’t updated like the original one, so they tend to get out of synch.

Here’s a trip: I was interested in learning more about how to make a URL more findable and when I Googled it (findability URLs), the 7th entry down was from Aarron’s blog! I read through his articles and found the general guidelines about URLs – i.e., adding keywords to your URLs make them more findable. I also found specific info suggesting incorporating the title of a blog post into the URL, and instructions on how to do that with WordPress. However, what I was interested in is something Aarron had mentioned in class that I didn’t catch – it was something about why you use hyphens in a URL as opposed to underlines.

Hmm. Back to Google. . . this time, try: findability URLs hyphens.
Success! I found an article (‘Google test: hyphen and underscore’) that explained exactly what I was curious about. Here’s what I learned: If you separate words with hyphens (in either a URL or the body text), Google registers each word as a separate keyword. Thus, Google would see ‘red-rose’ as having ‘red’ as a keyword and also ‘rose’ as a keyword. However, Google reads an underscore as a way to connect the words. So red_rose would be seen as a single keyword: ‘red_rose’. Yea! I learned something!

Hey! I at least just found out how to make categories for my blog! Awesome! Ok, so now on to what I just learned that I thought was totally cool.

I’ve been reading about how search engines don’t spider JavaScript. That’s been sort of a meaningless, no-context, ho-hum statement to me. However, I just found this article on SitePoint that livened it up for me and suddenly transformed it into something that’s REALLY cool. The article is ‘Avoiding the 5 Most Common SEO Mistakes’ by Johnathon Smith. In the article, he provides a real-life example of a site that gathered hot “deals” from around the web and aggregated them in one place. It was a great site but because it was coded with JavaScript, no one was able to find it. What the author pointed out (which was brand new info for me) was that if the web developer had coded the same thing with a server side language such as PHP, the aggregating would take place on the server, leaving the page with spider-legible HTML. Now THAT’S a concrete example that brings it alive for me.

I was first introduced to HTML around 1995 or ’96 through some tutorial types of courses offered by America Online. Tables were used for layout and the font tag was applied liberally. Although CSS got an occasional nod, the topic of accessibility was almost completely ignored. If anyone dared ask about it, they were told that it was very complex, unsupported by browsers and in short, not worth messing with. My, how we’ve changed.

Andy Hagans has pointed out that accessibility is an important factor in findability. If a person who is physically challenged in some way can’t make sense of a website and find what they need, chances are that a search engine would not be able to, either.

The accessibility standards are presented in priorities:

Priority 1 checkpoints. These must be followed or one or more groups will find it impossible to access information on your site.

Priority 2 checkpoints. These should be followed or one or more groups will find it difficult to access your information.

Priority 3 checkpoints. These may be followed to improve access for one or more groups.

To be honest, the accessibility standards still seem complex – or at least, lengthy. However, with increasing browser support for the standards, it behooves us as web developers to roll up our sleeves and get a bit dirty as we figure out how to apply these standards to our sites.

Reference: W3C: Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0

To Find or Not to Find

This is a rather odd time. I find myself in a class on the topic of findability at the same time I’m trying to build an application that will hold sensitive data that specifically needs NOT to be found. Using the maxim that often one learns the most about a thing by trying to figure out how to avoid it, the posts in this blog will meander around in both territories: to find, or not to find. And if, perchance, I happen upon some outrageous fortune along the way (preferably without the slings and arrows), so much the better.

That said, a logical place to begin seems to be with a discussion of Web standards. Without this common foundation, neither findability nor unfinadability has much of a chance. The following steps are essential for good Web standards:

• Include the correct doctype: Doctype stands for Document Type Declaration (DTD) and its purpose is to tell the browser which version of (X)HTML was used in coding the page. It must appear at the top of each page and be exact in both spelling and case. The W3C has a list of recommended doctypes.
• Keep the following elements separated from one another:
  • Structure (HTML, XHTML, etc.)
  • Presentation (CSS)
  • Behaviors (JavaScript, PHP, etc.)
  • Content
  • This practice includes avoiding inline styles and inline JavaScript event handlers as much as possible. (The latter is called unobtrusive JavaScript.)
• Validate all code. Make sure all code you write is well-formed and passes the W3C’s validation tools.
• Use meaningful terms for id and class names. For example, using divs for the layout of the various sections of your page and giving them ids of header, leftNav, mainContent, and footer makes the structure of the page clear, just from reading the names of the ids.

This list is only a beginning but it’s an important one. Following these rules is essential to content that can be found as well as content that should remain hidden.