Gazette #214: Oct 20, 2004 ... Barn Swallows, Goldfinches, and SEO

Topics in this issue

· Barn Swallows, Goldfinches, and SEO
· Increasing Web Site Effectiveness
· Part Two: The Death Of Meta Tags
· SEF Spotlight
· Tech Talk - To WWW or Not to WWW
· Moving Forward
· Payment Due Notice
· How To Unsubscribe

New Blood

BARN SWALLOWS, GOLDFINCHES, AND SEO

By Ron Carnell

Had someone told me, ten years ago, that I would one day develop an interest in birds, I suspect I would have just laughed at them. Computers were quite geeky enough for me, thank you, without adding bird watching to my resume. Besides, sitting still long enough for a bird to land near me wasn't very likely back then.

Then I retired.

In 1997, I sold my business, and moved from California back to my home state of Michigan to be near my ailing parents. As some already know, I ended up pretty much in the middle of no where, seven miles outside a one-road farming village and thirty miles from anything big enough to be called a city. People 'round here like to fish and spend lazy afternoons watching the corn grow.

This story begins last Spring. I left my garage door up a few days too long, as rural folk sometimes tend to do in the absence of inner-city crime, only to go out one morning and discover a bird's nest built on the protruding door handle. A little research in trusty Google eventually identified the culprits as a couple of barn swallows. At first, I was a little irritated, being faced with the choice to either destroy five tiny eggs or leave my garage open for the next few months. My irritation turned to horror when the eggs hatched and the droppings beneath their nest grew daily. But I adjusted (with the help of a handy garden hose) and eventually began to appreciate the unforeseen benefits. Barn swallows, like their slightly larger and very popular brothers, the martins, eat insects by catching them in mid-air. One swallow, while nesting, can consume up to 8,000 insects a day. As the fledglings left the nest, I learned to enjoy their graceful aerobatics as they criss-crossed my two-acre yard every day, often swooping with a few feet of me, and I learned LOVE the absence of mosquitoes and wasps.

Fast forward to late Summer.

Barn swallows winter in South America, migrating nearly 8,000 miles every year, and are typically one of the first birds in Michigan to disappear from the morning sky. Even before they left, I had already decided I wanted them back next year ... but preferably NOT on my garage door. So, I had a twenty-foot overhang built onto the front of the garage, complete with open rafters and spaced L-brackets to take the place of my garage door handle. I even strung an electrical extension cord (unplugged, of course!) from one end to other for them to perch on, because that's what they seemed to prefer in my garage.

Almost as an afterthought, I also decided to put out a few bird feeders to see what other kinds of avian critters I could attract to my yard. And THAT is when my frustrations truly began.

Although I watched carefully, perhaps even eagerly, from my back window, my initial offerings went pretty much ignored. I switched from a generic mixed bird seed to a more expensive black oil sunflower seed. I bought different feeders. I put out something called suet cakes, which seemed to be nasty gunk embedded in highly concentrated fat. I tried peanuts. More feeders, this time for a tiny little seed called thistle. I read birds liked the sound of running water, which made sense since a river is good place to find food, so I put in a big fountain. When I discovered the running water was a little too robust to let the little song birds drink, I put in a small bird bath. Which soon led to two larger bird baths, each at a different height to accommodate different birds. As September and Summer drew to a close, I had a landscaper put in three scarlet maples, each about twelve foot tall, to surround my growing collection of feeders and bird baths.

If you were walk into my back yard today, the sky would momentarily turn dark as literally hundreds of birds took to panicked flight. Most of them would be goldfinches, often called the wild canary because of their coloring and song, with a good handful of larger house finches thrown in for good measure. You'd likely see a few mourning doves laboriously winging away, fairly ponderous ground eaters who clean up what the finches have dropped. I have a family of about ten very pretty bluebirds who come in about an hour before dusk every day, not to eat seeds because they mainly live on fruit and insects they can find on the ground or in trees, but rather to take their nightly bath. I've seen colorful (and very noisy) blue jays, cardinals, orioles, red-winged blackbirds, and tiny, fragile wrens.

It was a little frustrating at times, but I eventually succeeded. In retrospect, it should have been a lot easier. I spent a month trying all these different seeds and feeder combinations, but it wasn't until I added water to the mix that anything started happening. Okay, can you say, "Duh?" Birds need food, water, and shelter, just like you and I and a few hundred thousand other species. The right seed, obtainable fresh water, a few trees, and the willingness to run off an occasional cat with a well aimed garden hose was a pretty simple recipe for success.

In short, all I really ever had to do was cover all the basics, in something at least approaching the right combinations.

Which is exactly why attracting birds is an awful lot like search engine optimization. It's not rocket science, but it does take some attention to detail and a bit of time to find the right combination of basics. Food, water and shelter easily translate to good content, crawlable links, and a server configuration that isn't too terribly inhospitable to digital arachnids.

Good content, in spite of what many pundits claim, will always be the most important ingredient. While visitors and search engines don't always like exactly the same food (engines need theirs vitamin-enriched with keywords), they necessarily must be SATISFIED by the same food. If you're serving birdseed that isn't palatable to your visitors, it won't be palatable for the spiders, either.

Just as I discovered that birds ignore food in the absence of obtainable water, spiders will largely ignore your great content in the absence of crawlable links. Yea, that means getting other sites to link to yours. That sometimes takes time, but if you've got good content, it'll eventually happen. Even more important than inbound links, however, are your own internal links. The spider has to be able to move from page to page easily. But that's not rocket science, either. Avoid links that depend on JavaScript, session IDs, cookies, or passing more than two or three dynamic parameters and the itty bitty spiders will crawl your site all day and night.

Server configuration is both the easiest, because you have to work to mess it up, and the hardest, because when it does get out of whack most of us feel helpless trying to fix it. Some of the things that can make your server inhospitable include robots.txt files that are wrong, server redirects that lie, just about anything in an .htaccess file that isn't friendly, and sometimes even the names of folders or files with non-standard characters than can cause a poor spider to choke.

There's a whole lot of different combination to consider, but mostly it's a matter of avoiding silly mistakes. It's easy to do like I did, spending weeks experimenting with the seed when all I really needed to do was give them some water, and it's even easier to waste all our energy just plain over-thinking everything. Stick to the basics, exercise a little bit of patience, and the spiders will soon be eating out of your hand.

Maybe next issue, we'll explore why plagiarism is a feline we want to keep out of our aviary, and how to best to aim your garden hose? :-)

INCREASING WEB SITE EFFECTIVENESS

Guest Article by Diane Vigil

Whatever your website offers, it's a given that it needs not only to attract visitors but also to convert those visitors to customers. In most cases, the more professional your website looks, the better it will perform for you. One of the things Jim did so well was to highlight new "finds" and utilities to help webmasters to improve their sites and online promotion. Here are a few of my favorites that, while not new, can be of great help in improving websites and thereby increasing conversions.

Learn Programs the Easy Way

Most of us have any number of programs for designing and dealing with websites ... but, if you're like me, the last thing you feel like doing is curling up with an owner's manual. While there may be sites containing specific tips, the likelihood is that you probably aren't familiar with everything your program(s) can do, nor the easy/professional way to do them. Lynda.com to the rescue ( http://lynda.com ). You may recall Lynda.com as the ones with the web design clinic in Ojai, California; they've now switched to providing "lessons" in CD ROM and book format and -- my favorite -- online QuickTime tutorials broken into sections. If you've ever wanted a professional to "just explain it to me", this is your answer, and prices are great, too.

Website Color Schemes

Ever designed a site that had all the "pieces" but just didn't look right? The answer may be your color scheme. A color scheme that is a bit "off" (or way off) can make a site look disjointed and incomplete, while a properly harmonized color scheme can bring it all together and make the same site look pleasing and professional. Unfortunately, this can be difficult and time-consuming to do by eye. While there are a number of color tools and utilities available, my favorite can help you to select, adjust and harmonize color schemes, select colors from *anything* on your computer screen (like a logo), and save the results for later use. The name? Color Schemer ( http://colorschemer.com )

Screen Ruler

Screen Ruler is an old Jim favorite that displays horizontally and vertically in pixels and other measurements. Make short work of determining how many pixels your page elements need to be moved or whether they're truly aligned. Get it at Microfox.com ( http://microfox.com/ ). Cheap, too.

That's it for this issue. Here's wishing you better designing and conversions.

------

Diane Vigil (best known as DianeV in the forums) has been coaching others in the industry for a number of years, and is founder of DianeV. Web Design Studio ( http://dianev.com ) in Los Angeles. She is a long-time proponent of what is today called "holistic web design" - the use of a variety of disciplines to create effective market-oriented websites.

PART TWO: THE DEATH OF META TAGS

By Ron Carnell

… as we discovered in our last issue, has been greatly exaggerated. :-)

In our last issue ( http://www.jimworld.com/gazette/issue-213/ ), we looked at the keywords meta tag and concluded it might still be alive and kicking for many of us. This time around, we'll be examining the impact of the meta-keyword's little sister, the description meta tag.

<META NAME="Description" CONTENT="Describe the Page here">

That's the accepted format for the description meta tag, which should be placed anywhere in the <HEAD> area of your document (order doesn't generally matter). How long should the description be? Depends on whom you ask. You'll hear 150 characters bandied about, but that number goes back to the old Hotbot search engine, which isn't a really big concern to most of us these days. Today, neither Yahoo! nor Google specify a maximum or even recommended length. In my opinion, the meta-description should be as long as it needs to be, but no longer. Mine generally run two to five hundred characters, but I wouldn't hesitate to use up to a thousand if I thought it necessary.

Historically, there are two purposes behind the description meta tag.

At one time, in the old Alta Vista and Excite days of the Internet, the meta-description counted more heavily in ranking a page than did the body text. This meant you could stuff your description full of repetitive keywords and gain some real benefits. Unfortunately, many did exactly that, with the inevitable result that the search engines stopped believing us. Today, none of the major search engines give the description meta tag preferential treatment for ranking purposes. Google appears to ignore it completely for ranking, while Yahoo! and MSN give it no more (and possibly less) weight than any of your on-page text.

The second purpose of the description meta tag is to, duh, describe the page to search engine visitors. In the old days, all of the search engines displayed the meta-description when your site came up in the results for a search. Google, bless her little heart, changed all that.

From the very start, Google displayed what we've come to call "snippets" instead of your carefully worded meta-description. If someone searched for "bright red zebras," Google would try to find the same search phrase somewhere on the page and "snip" a sentence or two that actually included those words to use as the description. In retrospect, this was a brilliant move, because it gave the searcher a much better idea of whether the page was actually relevant for them. It was such a good idea, in fact, that pretty much all of the search engines have since followed Google's example.

Which, for us web masters, was a darn shame.

One of the first things Pay Per Click (PPC) subscribers realize, whether at Overture or AdWords or another smaller engines, is that the description is at least as important as the keywords they select, and potentially even more so. Coming up in the results, after all, is only the first step in acquiring a visitor. You're sitting there with at least ten other sites that came up in the results, sometimes many more, and you still have to get someone to click on your link instead of your competitor's link. Position counts, but beyond position, the description displayed with your site becomes your "Call to Action" and plays a VITAL role in getting the click. That's true in the pay side of the SE market, and it's equally true on the organic side.

Okay, so the description meta tag is no longer much used today, either for ranking or, unfortunately, for describing your page to the search engine visitor. If that doesn't make the tag pretty much dead, it must at least be pretty darn anemic?

Not really.

Turns out the search engines are not really ignoring your description meta tag. They're, instead, simply looking for any text that will match the phrase being used by the searcher and will, generally, use the first snippet they can find that does match. If the first match found happens to come from your meta description, the search engine WILL USE IT!

That's important, so let me repeat it. If a searcher is looking for "bright red zebras," and you have "bright red zebras" in your meta-description, all of the major search engines today will generally build their snippet from your description instead of from on-page text. Some (Yahoo!) will use more of your description than others (Google), but in almost every case, you've just regained control over what Call to Action will be displayed with your link.

(I keep saying "generally" and "almost" because there's one important exception. If your site is listed in their directory, Yahoo! will display THAT description instead of your meta-description. Bummer, but what ya gonna do?)

In a perfect world, you already know what search terms you're targeting for each of your web pages. Put those terms in a really good Call to Action sentence in your description meta tag, and don't be surprised if you literally double or triple your SE traffic without even increasing your rankings. PPC advertisers expend serious effort testing, retesting, and refining their description because they know it will make or break their campaign. You should do the same thing with your Call to Action, fine tuning it until you are comfortable it is enticing as many searchers as possible to click on your link.

It's not a perfect world, of course, so there are still going to be times someone searches for a term you didn't necessarily target and gets an on-page snippet from the search engine instead of your well refined Call to Action. That's why it's important to examine your server logs from time to time and find out how people are finding your pages. If you see a search term being used you didn't expect, you should consider adding a new sentence to your meta-description to cover the new term.

Getting listed well in the search engines is important, but getting the click is always the real goal. The description meta tag, for all its apparent anemia, is still your best tool for enticing the searcher to your site. When someone tells you that you don't need a meta-description, or you shouldn't spend much time on it, I suggest you just nod and smile and continue refining your Calls to Action.

A page that turns up in the SE results without an appropriate description meta tag may have been optimized, but it certainly isn't optimal.

(Everyone here does know how to write a good Call to Action, right? No? That's not really my forte, but I have a few friends with a strong marketing background who know how to write truly dynamic Calls to Action. Write me at ronc@piptalk.com and maybe, together, we can talk one of them into writing an article for us.)

SEF SPOTLIGHT

By Ron Carnell

If you don't spend every waking moment in the Search Engine Forums (shame on you!), you should at least take a few minutes to check out these important threads.

Google Is Doomed Long Term
Ron: "What happens when MSN finally rolls out its new search engine, backed by the deep pockets only Microsoft has? This thread is one of the best discussions I've seen at SEF in quite a while, and I think, a good reminder that we shouldn't be putting all our eggs in one Googlebot basket."

Getting Re-instated in Yahoo!
Ron: "Last issue's Spotlight introduced the dangers of cross-linking on Yahoo!, so it's only fair this time we spotlight the solution. Or, uh, the lack of a solution?"

I Am Making My Meta Tags Today And Need Help
Ron: "Which meta tags should you include on each web page? In what order? A few of our JimGuides offer some good advice and a decent summary of what is known today."

Let's Lay It To Rest .... Keywords And Tags
Ron: "Using Header tags like H1 to give your keywords greater prominence is both potentially wise ... and possibly dangerous. The key to avoid being labeled a spammer is to use Headers as they were intended."

Google: Clean Code Helps How Much?
Ron: "Using good CSS and valid HTML is important. But how important? And to whom? This thread discusses how to make sure Google and others can read and interpret your pages as you intended."

Tech Talk - To WWW or Not to WWW

By Ron Carnell

... that is the question! And the answer isn't always a simple one.

Ten or twelve years ago, the World Wide Web was just one small part of the Internet, and our fastest PC's were based on the brain-dead 386 chip. They weren't very fast and couldn't handle much of a load, so we often had to put the different parts of our Internet on separate machines. We'd put Apache on one computer, for example, and our mail server on another, and probably an FTP server on yet another. Each of the computers would respond to a different IP address, but still answer to the same domain name. We differentiated the computers with what we called, back then, a "machine name," and thus ended up with www.domain.com, mail.domain.com, and ftp.domain.com. (Anyone old enough to remember gopher.domain.com?)

Today's computers, of course, are much more powerful and we can put all of the different "parts" of our Internet services on the same box. Indeed, we often cram several hundred domains, each with its own set of parts, onto the same server. A few years ago, I argued (rather vehemently) that www was antiquated and should be ignored. Trouble is, a lot of big directories (Yahoo! comes to mind) automatically list your www.domain.com even if you submit a simpler domain.com, and we have a few billion people in the populace who habitually type www before any domain name. When I got tired of beating my head against that particular wall, I started recommending that everyone promote www.domain.com and get rid of domain.com.

If ya can't beat 'em, join 'em.

The history, at least for me, is interesting, but the important thing to remember is that www.domain.com -- just like sub.domain.com -- is considered an entirely different entity than domain.com. A surfer or spider going to any of the three will receive the same 200 OK response code for a page request and won't readily be able to differentiate the domains.

As Google and link popularity have become more dominant factors in the SEO world, this has caused countless problems. If half of your inbound links are to domain.com and the other half go to www.domain.com, you risk splitting your Page Rank between what are technically two different sites. Not a good thing.

One common solution, often recommended especially for Google, is to use a server-side redirect to move all traffic from domain.com to www.domain.com. If someone tries to go to domain.com, they are sent a 301 response code instead of a 200 Okay, and their browser automatically will jump to www.domain.com (and show the change in the Location bar).

There are two advantages to this. First, it's more unlikely someone will ever link to domain.com since they can't even get there. Second, even if they do link to it, Google has promised it will only include www.domain.com in its index and, more importantly, will still count the domain.com links towards the PR for www.domain.com.

So, how do we establish a 301 redirect? Here's one way to do it, on one of the more common web servers, Apache. Open your favorite text editor, like Note Pad, and enter (or copy and paste) the following lines:

Options +FollowSymLinks RewriteEngine on RewriteCond %{HTTP_HOST} ^domain\.com RewriteRule ^(.*)$ http://www.domain.com/$1 [R=permanent,L]

Do a File/Save and enter the filename as ".htaccess" (with both the quotes and the leading period), then upload that file to the root directory of your web server. IF your server supports .htaccess (not all do), and IF your server supports mod_rewrite (not all do), any attempt to access a page on domain.com should automatically be redirected to www.domain.com.

While mod_rewrite is the most common way to handle the dichotomy between domain.com and www.domain.com, it's really not the best way, and for many of us, it won't even be a possible way. Why? Because in a perfect world, we really don't want a Redirect sitting between two Aliases.

What's the difference?

If someone yells "Ron!" across a crowded room, they're probably going to get my attention. If someone yells "Carnell" across the same room, I'm going to respond to that, too. That's because the two names, though entirely different, generally point to the same person. Over-simplifying a bit, we can say that Ron is essentially an Alias for Carnell.

If someone in that room walks up and addresses me as John, however, I'm probably going to look around, find John, and point him out as the one she's looking for (unless she's really cute, in which case I might lie.) Ron and John are two different names that point to two different people, so I need to Redirect the person's request to where it can be best answered.

On 99.9 percent of all server configurations, domain.com and www.domain.com point to exactly the same spot on the disk. One is just an alias for the other. Using a redirect makes about as much sense as someone calling me Ron, and me responding by pointing at my chest and saying, "No, you mean Carnell." Aliases and redirects don't mix very well.

Let's get technical for a minute, okay?

Creating an alias is generally accomplished at two levels. At the DNS level, we always have to create an entry for each, usually a CNAME for each, or possibly a CNAME for the primary and an A entry for the secondary. If the domain in question is on a static IP address, this is all we need to do to create the alias.

Most of us, however, share an IP address with other domains, so we have to move beyond the DNS level to the web server level to complete the Alias configuration. Using Apache as an example, an entry in the hpptd.conf (stripped down and simplified) might look something like this:



        <VirtualHost 192.xxx.xxx.xxx>

         ServerName domain.com

         DocumentRoot /home/domain/www

         ServerAlias www.domain.com

        </VirtualHost>

That's all we need. Anyone, surfer or spider, going to either domain.com or www.domain.com will get exactly the same pages. Our problem, however, is that the URL doesn't change in the address bar and the page requests will result in 200 OK responses regardless of which domain is being accessed. Remember, www.domain.com and sub.domain.com look exactly the same to a search engine. The spider must, at least initially, treat both domain.com and www.domain.com as separate entities, even though we know they are aliases.

Google is the first search engine to incorporate sophisticated duplicate content filters and the logic necessary to eventually merge domain.com and www.domain.com into the same entity. Unfortunately, there's some small emphasis in that sentence on the word "eventually."

If you use a DNS alias or a ServerAlias, Google will usually and eventually recognize the alias relationship and only show one in their SERPs. In most cases, when that happens there is ample evidence to suggest the PR from domain.com and www.domain.com will also be combined. Sadly, it usually takes several months to determine and, if you change your content frequently (meaning domain.com/page.htm and www.domain.com/page.htm, when spidered at different times might have different content), those several months can stretch out to a year or more. Who wants to wait? And when the guarantees are also pretty darn fragile, who wants to gamble?

It would seem none of the "big boys" want to either wait or gamble. Most of the PR 10 Sites we know about use only their www domain. If you try to access w3.org or adobe.com, you'll find your browser immediately redirected to the www version. It's not just an alias, because your location bar actually changes to the new www domain. We have to figure Google condones this, too, and not just because the big boys are doing it. Try going to google.com if you don't believe me. (Interestingly, most of the big boys use a Redirect 302. Only a handful, like w3.org, return a 301 status code.)

So, instead of relying on aliases and duplicate content filters, which at best will only work with Google, someone came up with the brilliant idea of redirecting one alias to another alias, which is essentially a redirect to self. The bad news is this still only works well with Google, though even with other engines it will at least discourage people from linking to both domains and should thus help avoid splitting your backlinks. The worse news, though, is that to create a redirect to self, we have to jump through a few technical hoops.

Enter mod_rewrite. We can't use a simple Redirect command because both domains share the same directory space and anything found in .htaccess has to apply to BOTH domains. A simple redirect would send our visitors in a viscous circle and eventually crash and burn. So, we need all those complicated Regular Expressions available in mod_rewrite just to do what should be simple and easy.

Let's try a slightly different server configuration, one you are very unlike to ever see.


        <VirtualHost 192.xxx.xxx.xxx>

         ServerName domain.com

         DocumentRoot /home/domain/www

        </VirtualHost>


        


        <VirtualHost 192.xxx.xxx.xxx>

         ServerName www.domain.com

         DocumentRoot /home/wwwdomain/www

        </VirtualHost>

Notice in this configuration, domain.com and www.domain.com point to different folders on the server and therefore are NOT aliases. We can now put an .htaccess file in the /home/wwwdomain/www folder without affecting anything in the /home/domain/www folder and use the simpler Redirect command to meet our goals.

Problem solved. Except, unfortunately, we're wasting a bit of disk space and very few hosts would do this without charging for the extra resources. That's why you won't see this configuration very often.

It does, however, suggest another possibility.


        <VirtualHost 192.xxx.xxx.xxx>

         ServerName www.domain.com

         DocumentRoot /home/domain/www

        </VirtualHost>


        


        <VirtualHost 192.xxx.xxx.xxx>

         ServerName domain.com

         Redirect 301 / http://www.domain.com/

        </VirtualHost>

We're still configuring domain.com and www.domain.com as separate entities (not aliases), but instead of defining a DocumentRoot for one, we simply insert our simple Redirect statement. We avoid the contradictions of trying to redirect an alias by never creating one.

The disadvantage to this method is that it will require more work for the host admin. He has to define two blocks instead of one, but more importantly, he has to maintain both blocks in unison. If one is removed or altered, the other needs to also be removed or altered, and this introduces the very real probability of human error. (The real reason he will balk is because none of his utilities, like Cpanel or Ensim, will automate the procedure for him. At least, not yet.)

The trick is going to be to convince your web host that the advantages TO THEM outweigh the disadvantages.

Your .htaccess file introduces overhead to the server. Every single page request made to your domain will result in a read operation for .htaccess and a parsing of the file. That constant re-reading and re-parsing is why you can change your .htaccess and have the changes take immediate effect. Now throw in all those Regular Expressions that have to be evaluated for every single page request, and then multiply all of that by the 200 to 500 other domains sitting on the server. Your web host is going to find they can put fewer and fewer domains on a single box if all those domains are jumping through technical hoops in order to accomplish a simple redirect.

A redirect placed in httpd.conf, however, requires no fancy RegEx evaluations and more importantly is read and parsed exactly ONCE. Apache reads httpd.conf when it is first booted, memorizes it, then ignores it until the next reboot. The processing is minimal and the load on the server even less so.

Redirecting an alias is a contradiction, and one that exists only because of the search engines. Everyone, including the big boys, including even Google, does it, but it will always be just a kludge. We need the redirect. A more elegant solution, IMO, is to avoid creating the alias in the first place. That it makes our servers run more efficiently is a nice side-benefit. :)

(Feel free to forward this newsletter to your hosting company, and then pull a Picard on them. "Make it so.")

Gazette #214: Oct 20, 2004 ... Barn Swallows, Goldfinches, and SEO

New Blood

Sponsored Links