Site decor

Righting Ranking Wrongs

Tuesday, March 9, 2010


Right now I'm doing some on-site search engine optimization (that is, fixing up the content) for a large and successful logistics company. They're always on those lists of Top 50 Companies and Companies to Watch and stuff like that. They're also on the lists of Best Places to Work and Green Businesses. I like to work with companies like that.

I also had a call yesterday from a small roofing company that's been in business in their town for 30 years. They pride themselves on the quality of their work and the way they treat their workers. They won't take a customer's check until the job is done to that customer's satisfaction. The caller was the son of the founder of the business. He called from his truck on a job site, with his laptop by his side. I also like to work with companies like this.

Not everyone would see what these two companies have in common. To me, though, they both are businesses that ought to be ranking very well on the search engines, and aren't. When you look for logistics, you ought to find that up and coming company. When you look for a roofer in Blue Springs, you ought to find that roofing company. People who find these companies when they search for them will be happy; they'll get exactly what they need.

In both cases, you don't find them.

While there is certainly a fun aspect to getting some bold start up to a top rank against the odds, there's even more satisfaction in getting companies the rankings they truly deserve. It makes me feel like I'm Righting Wrongs. (That's me up there on the white horse.)

So I hope that when you think about getting top rankings for your company, you think about what your company is best at. What you ought to be ranking for, because you really are the best choice for people who search for those terms. What Google would really like to be offering you for, if only they knew.

Usually, getting those rankings is mostly about fixing the problems with your website. The two companies I mentioned have something else in common: their sites have problems, both in the content on the screen, and in the stuff under the hood. Once we get them fixed up, the search engines will probably fall upon them with metaphorical glad cries.

And I can ride off into the sunset, conscious of having restored the balance of the universe, if only in a small way.

Labels: ,


How Good Does Your Website Have to Be?

Monday, March 8, 2010

A local restaurant has finally gotten a website up, and it's one of the worst websites I've ever seen. Its spelling is so creative that -- well, it includes words like "propetisioness" and "prok." The overall quality of the writing is what you would expect of a website using the word "propetisioness." It has no meta tags at all. Its design suggests that a bunch of random images were just stuck together till the space was filled. The basic information, such as hours and phone number, aren't on the home page at all. The code is poor.

The question is: does this matter? The menu's there, the phone number is on the Contact page, I went there and called and ordered food, regardless of how bad the website might be, so who cares what it looks like?

Well, Google seems to care.

This website is below the fold for my personal search for the name of the restaurant, even though both the URL and the title use the name of the restaurant, and even though I a) live just up the road and b) have been to the site before.

Google, we're assured, doesn't penalize for bad code, bad design, or bad writing. But they don't have to make a direct penalty for these things to get in the way of good search results. Here's why:
  • Google's goal is to choose quality. While there are fairly bad sites high on search for some things, a good site would quickly take their places if someone made one. In the case of this example, the restaurant's own social media accounts, as well as all the directories they're listed in, are above their own website. Google is, essentially, offering readers everything else it can find before offering this site. 
  • Links to your site affect your rankings, and people don't choose to link to bad sites. I recently complained about having to link to bad math sites because I couldn't find good ones. If someone puts up a good math site, will I rush over and change my links? You know it. A bad website just doesn't entice visitors to link to it. If it's bad enough, good directories will refuse it, too.
  • People who can't build a good-looking website won't be able to build you a well-optimized website. The opposite isn't always true, since there are web artists who know nothing about SEO. But someone without the skills to write and code your site correctly won't have the more specialized skills it takes to build an optimized site. The site I've been telling you about made a 14 at Hubspot's Website Grader, one of the lowest scores I've ever seen. They have a Moz rank of 0, no inbound links, and they're not indexed. The people who built this site shouldn't be calling themselves web designers.

Beyond that, there are physical-world issues connected with having a poor quality website. If you can fry chicken well enough (and this restaurant can) people who know about your chicken will come get that chicken no matter how bad your website is. People who don't know about your chicken, however, won't chance it. They'll go to the place with a website that makes the chicken look good.

Labels: , ,


Does It Matter Where You Put Your Keywords?

Friday, March 5, 2010

I've written before about the dangers of following simple formulae telling you where to put your keywords. It is more important -- and Google's Matt Cutts confimed this in his broadcast from SMX yesterday -- to have good, natural content for your human visitors than to try to game the system with arbitrary guesses about the algorithms.

Still, I always like to put the keywords right up at the beginning, where search engines can catch them quickly before they get a false impression.

Now I have some nice, current data that supports this view. I'm doing a rewrite for a client, a large third-party logistics firm. They have four pages of success stories, a good thing to have. Each story tells how the logistics firm was able to help a particular client company. Each story naturally includes a good proportion of key search terms, such as "third party logistics," "logistics solutions," "warehousing logistics," and so forth.

In looking at their analytics, I was able to see that one of those pages had significant traffic from search, while the rest had none.

All the pages had been created in the same way, with a content management system. All had messy code, some grammatical and spelling errors, and problems with layout. All had interesting points to make (at least if you're into warehousing and trasnport logistics).

What was different? Three started off with a paragraph describing the company. The one with the higher level of search traffic started with a statement about the company's logistics needs. The description came later.

By the time the search engines made it through that paragraph about beauty supplies and shea butter, they had apparently already decided that the page wasn't really about logistics.

Now, you may be wondering why the pages didn't come up for other keywords. The answer is that they probably did. Not high on search, probably, because it takes more than keywords to achieve that, but perhaps for a search on the companies being described. However, searchers then probably didn't choose to click through to a site for a third-party logistics firm -- the description made it clear that this wasn't the place to buy that shea butter preparation.

As I say, I've always favored putting keywords high on the page. I'm not trying to fool people when I write a web page; I want everyone, human and robot alike, to know what I'm talking about right away. But in this case, the analytics gives us a good data-driven answer to our question: yes, it does matter where we put our keywords. So let's get them right in the first sentence, where they'll do the most good.

Labels: , ,


Keeping Track of Your Web Projects

Thursday, March 4, 2010

Often a business owner will tell me that he or she has a web site being built. "I think so," they'll frown. "I haven't heard from them in five months..."

Sometimes websites take a long time, for various reasons, and sometimes that may be fine with you. A good web firm will keep you informed, making sure that you know where they are in the process and getting your approval at the expected points. The image above shows a mockup for a site Tom Hapgood and I are working on for Ozark Natural Foods. We've had the content approved, and now we've sent this on to the client for approval, and we've stayed in touch throughout the process. The client can trust us to be communicative, and they seem content.

But what if you want to keep up with the growth of your site on a day to day level?

You can of course call and email back and forth. There are some real disadvantages to this.
  • It's time-consuming. If you choose this method, I promise you that your team has said, at least once, "Do they want us to talk, or to work?" in exasperated voices.
  • It can be confusing. We've all scrolled through lots of emails trying to figure out which one is the most recent, or which one had that piece of information we've been looking for. Conversations can include a lot of, "Which document are we talking about?" and "I thought you changed your mind about that -- wait, I have your email here somewhere..."
  • It's easy to leave people out. It's equally easy to send people lots of information they don't want or need, in order to avoid leaving them out.

It's better to work in the cloud.

One way to do this is with a development site. I'm doing that with site changes for The Retreat at Skyridge and for Clevertech. The client has a link to the pages which aren't actually public yet, and we can communicate directly as the changes are made.

This approach still puts you at the mercy of phone and email, though. And it isn't comfortable for everyone. I work with some perfectionists who couldn't tolerate having people see their work before it's completely ready.

You can avoid these problems with a shared workspace, where people can upload what they're ready to share. One option is Basecamp, a 37signals product. The screenshot below shows the a page at the Basecamp workspace for Ozark Natural Foods' website. It's not very exciting to look at, but you may  be able to tell that we have conversations, our calendar with milestones, our files, our time logs, and everything else in there.

I use Basecamp with a lot of my clients, but there are other, similar tools. Solve360 combines the shared workspace with customer relationships management. OfficeLive is free, and it works well for me since I use Word and Excel, but not so well for designers using Mac and Adobe. Notable gives a space specifically for giving feedback on websites. oDesk lets you peep at your team's screens and upload files.

As you can imagine, there are pluses and minuses to all of these tools. Basecamp is the most versatile, but it has so much information in it that it may work perfectly for your team and not so well for you, as you slog through arcane discussions about boring things and wonder why there aren't any pictures yet. OfficeLive doesn't work well for everyone's software and operating systems. Notable lets you give feedback, but it doesn't have a place to keep content files. Solve360 may have too much sensitive information to allow everyone full access. oDesk only works if you hire your team through their system.

If you are relaxed and happy waiting for your website to emerge, that's great. If you can scarcely resist going into your team's offices and hanging over their shoulders, though, discuss the possibility of using a shared workspace. It might be just the ticket.

Labels:


Should Your Website Be Bilingual?

Wednesday, March 3, 2010


Pickaweb has started a new subscription program, and they're offering a month free. I'm one of the people involved in the process, so I was excited to hear that they've launched. I was also glad to have the chance to ask Tony about one particular aspect of the business. Pickaweb is a UK firm, but in Spain they're Merkaweb.

As you can see, they have both Spanish and English versions of their website.

A project I'm working on for a local client also has both Spanish and English versions of the site. Their analytics shows that few people visit the Spanish language site, so Shan and I were wondering whether it makes sense to keep both, and how best to optimize the Spanish language site if they keep it running.

With any web effort, it's always important to consider whether the return justifies the use of resources, and whether those resources could be better used another way. At the same time, when an asset isn't performing as well as you'd like, it makes sense to consider whether changes in the way you're using that asset might not help it pay its way.

So I asked Tony whether he felt that it made sense to have a site in two languages.

The first question is whether you have the audience in the second language. In Tony's case -- yes, of course he does, since his second site is in Spain. In the American client's case, the lack of traffic suggests that the audience may not be there. Census data suggests that there are some 35 million people in the United States who speak Spanish as a primary language, and that only half describe themselves as speaking English "very well." But the client's B2B site may not fill a need for those who are comfortable only in Spanish. There site's analytics show the typical Monday through Friday pattern of a site that is accessed from the workplace, and  English might be the usual language of the workplaces in question.

On the other hand, the use of Spanish in the United States is increasing, certainly here where our client is based, and in other areas of the country as well. Having the second language might be forward-looking if nothing else. 

We thought about auto-translation as an alternative. Tony confirmed that English to Spanish auto-translation doesn't always result in natural Spanish. Merkaweb, auto-translated to English, actually does quite well, producing only one rather odd sentence on the homepage: "Protects to identity on the internet!" As pages become more complex, though, more oddities creep in. Auto-translation is certainly helpful, but a Spanish language page will equally certainly provide a better experience. 

Or it can. If your translated page is poor, though, or not directed well toward your target audience, you may be doing yourself a disservice. Market research shows us that different linguistic and cultural groups in the U.S. have different buying patterns -- and different exploratory shopping patterns as well. We know, for example, that European American women are more price-sensitive in their shopping for cosmetics than Hispanic or Asian American women. Translating a web page selling cosmetics into Spanish or Japanese won't bring conversions if our focus is on how economical our product is. 

In our particular case, we clearly need to do some research about the particular audience our Spanish language pages ought to be targeting. Once we have completed that research, we'll be in a position to make useful decisions about how best to use that section of our website.

Labels: