This is a topic that has come up over and over again on WebProWorld– the use of hyphens in domain names for SEO. And it’s amazing it keeps coming up since the answer has been the same since Google was born. Hyphens in domain names are a bad idea, but, ironically, not because of the search engines, though there was a time back near the birth of the internet when they did actually do you some good from a Search Engine standpoint, though even then I would not have bought one.

It’s for one simple reason. People won’t remember to put them in when they’re trying to remember how to access your site. And since they are trying to remember your site, chances are you’ve just lost a qualified person who is interested enough in what you have to manually type in your domain name into the browser location bar. Which means they’ll end up at your competitor’s site, the domain name that has no hyphens in it, and if your competitor has what they want, you’ve just lost a sale.

It is much better to get an “off” TLD, such as dot net or dot info than to squander your dough on a domain name people will invariably screw up. It’s better to be a bit creative in coming up with domain names than it is to settle for the one that will lose you traffic. I’ve never had a problem finding great domain names, and most of my domain names are dot coms with just a few dot nets and a couple intentional dot orgs for my non-profit advocacy activities.

And since I’m all about making the most of the traffic I do get, no matter how it comes to me, I’m sure that I’ve eaten someone else’s lunch on a few occasions.

[tags]Hyphens in Domain Names[/tags]

** UPDATE!!! ** This theme has been tested, and works in WordPress 2.5.

Kickass-Limelight is released free for non-commercial use as long as the attribution/link to http://kickasswebdesign.com remains intact and visible to all. Please ask about licensing if you wish to use this for Commercial purposes. This theme works in WordPress versions 2.3.x and later.

You can tell I was dreaming spring dreams with this one, since this is all pale spring green colors.

The Kickass-Limelight WordPress Theme has three separate widget areas, one in the right column, and two below the content and sidebar in side-by-side boxes. This allows for a more versatile use, since the lower boxes can take wider content than a sidebar, allowing wider images, or larger ads, or featured content. It is also Tag enabled, to take advantage of the new WordPress Tag feature. If you are going to use the integral Tag Cloud Widget, I suggest you use the Skin Tags Plugin along with it.

The source ordered xhtml is search engine friendly web design that ensures that your content is first in the source, allowing for good search engine spidering and position.

Close but not quite it? If you want a unique custom wordpress theme design for your exclusive use, contact me, and I’ll whip you up something wonderful. It’s more reasonable than you think.

[tags]Free WordPress Theme, WordPress Theme Design, custom wordpress theme design[/tags]

The IE 8 Beta is out.

There is already buzz about it, since IE8 passes Acid 2, supposedly. Of course, that’s a step behind already, since Acid 3 was just released. And according to the Slashdotters, IE8 only scores 17 on Acid 3, compared to the most recent stable version of Firefox, which scores 50 on Acid 3.

There have been some rumors lurking about that it will only work on Vista, and will eventually be totally standards compliant. This is interesting, if so, since it will amount to USING IE8 to push vista adoption, since vista has not exactly broken any sales records. Though if that’s the plan I doubt it will work, since there are other browser options, and no one wants vista.

Additionally, there is an issue for developers. In IE8 there are three rendering options that a dev can code a document to, two of which will render to an IE7 standard, and only one of which will render to IE8 and standards compliance. The trigger is a special meta tag.

Re IE8, what can we expect? According to Alan Gresley of css-class.com, who posted this to the css-discuss list, there have been improvements.

He says:

Thierry of tjkdesign.com is reporting some IE8 Stacking Bugs.

There’s also been a section added to the css-discuss wiki to detail issues with IE8 Beta. I’m sure the css-discuss community will be doing some heavy testing on this sucker. Hopefully some of this stuff is ironed out before it goes into final release form.

I’m sure there will be more to report in the coming weeks, as more issues come to light.

[tags]IE8, IE 8, Acid 2, Acid 3, Web Standards, Browser Rendering[/tags]

Zi pointed me at a great article which lays out a toolkit for building accessible forms.

There are also some other tutorials and helper pages on the web to help in achieving form markup that will allow people using assistive technology to fill out your forms. I dug in my bookmarks and came up with these.

• Accessible HTML/XHTML Forms, Beginner Level
• Accessible Forms
• Creating Accessible Forms
• Accessible Forms

[tags]Accessible Forms[/tags]

Twice recently I went onto client’s sites to find they opted in WordPress Admin to use a category dropdown menu instead of the regular widget menu. It amazes me every time I see this. Why? Because not only is it an ugly interface in an otherwise Kickass design, but it’s also a really really REALLY bad idea from the point of view of accessibility and Search Engine Optimization.

Let’s take accessibility first, since it also covers the biggest part of SEO, since Search Engine Spiders happen to be blind. Screen readers and Search Engine Spiders cannot follow links hidden in Javascript, and since the dropdown menus that are generated by WordPress do not have a noscript alternative, that means that SE spiders and people who use assistive technology won’t find these links. From Google Webmaster Guidelines, “While Googlebot is great at understanding the structure of HTML links, it can have difficulty finding its way around sites which use JavaScript for navigation. We’re working on doing a better job of understanding JavaScript, but your best bet for creating a site that’s crawlable by Google and other search engines is to provide HTML links to your content.”

People who can see but are not dexterous with a mouse may also have a problem using this sort of dropdown menu, though I admit I didn’t try keyboard alternatives.

Now we come to SEO. People who use WordPress generated dropdown menus have not only hidden the links in Javascript so SE spiders can’t follow them, they’ve also thrown away KEYPHRASE RICH ANCHOR TEXT that would help their site get good serps for those keyphrases. The way Search Engines index you is to report back the anchor link text that is used to point to your pages. That’s what helps to “place” you within the WWW hierarchy, and counts for both internal links AND links from external sites. So when you toss out this keyphrase rich anchor text AND the links, it’s a double whammy against you.

Purely from a geek standpoint, I find it annoying that there isn’t a noscript alternative since most of us geekytypes run with js either turned off completely or at the least throttled back via firefox plugin to make our computers more secure. Also, if you’re going to write code, at least take the time to do it right, and in this case the WP devs didn’t. Not only is the noscript alternative missing, the html code that is generated by the javascript doesn’t validate. Ugly!

Now, from a usability and psychological standpoint, I, as a visitor, am much more likely to click on an intriguing category name in anchor text than I am to click on “Select Category”. So most likely it would follow that there are most likely going to be less pageviews per visitor with this type of menu system, which translates into less conversions, less ads viewed, less ads clicked, etc.

So next time you think it might “neaten up” your page to use a category or other type of javascript generated dropdown link menu, you might want to reconsider.

[tags]WordPress usability, WordPress Accessibility, WordPress SEO[/tags]