Last week, Google, Bing and Yahoo announced collaboration on a single standard for structured markup. Yes, I’m talking about Schema.org and utilizing Microdata for “Rich Snippets.”

Since then, many sites have posted about why Schema.org might be good, bad or otherwise for site owners; some balanced, some not. Personally, I think structured markup and machine-readable information is always good to have on your site, regardless of potential SEO benefits. I’ve had a love for structured markup (in the form of Microformats) since I first laid eyes on hCard several years ago. I could have written a whole post about why I think Schema.org is good for SEO, but instead I decided to implement it on a site of mine.

I co-own a book review site, and I’ve been meaning to implement the microformat hReview on it for over a year. I never got around to it because it involved creating custom post types in WordPress, and I knew that would be a time-consuming affair. I finally bit the bullet and sat down to do that on Sunday. That part took about 5 hours of my day.

Then, I started implementing microdata. From never having implemented microdata before in my life (like I said, I was a Microformats fan), I found out what markup I needed, added it to my template, and tested it in about an hour.

I started out by making a list of all of the attributes about books that we use in a review. Then I determined which item type (itemtype) it would be associated with – for my purposes, Book, Review , and Rating were all I needed. Then, I noted which item property (itemprop) I would use. Then it was simply a matter of adding the appropriate markup to my existing HTML and PHP.

There were a couple of attributes that were confusing – for example, do I use description or reviewBody from Review? Do I use aggregateRating from Review, or reviewRating from Rating? The examples on Schema.org were helpful to a degree, but I still felt like I was guessing at proper use. Time will tell if I’ve used the appropriate item properties. I also wasn’t sure if I had to upgrade the doctype to HTML5 or not, but I chose not to as only modern browsers support it and some of my users have older browsers.

To test that you’ve implemented microdata correctly, you can use Google’s Rich Snippet testing tool. However, it was throwing errors for things it should not have had a problem with (I suspect it was getting a lot of use over the last week as people rushed to add microdata to their sites), so I looked for an alternative. I found this Microdata Tool using jQuery to test that I had applied the code correctly; unfortunately it can’t show how Google might display this data in the SERPs.

One of the arguments the naysayers against Schema.org are using is that it will take too long/too many resources to implement, but clearly that is not the case. I’m going to continue to tinker with microdata and my review template, and monitor my organic search rankings and conversion rates to determine just what the effect of adding it will be over time.

We’re excited to announce a pretty big new feature which will be live next week. We’ve been working with a few different API’s to bring in backlink data about any website. There aren’t that many sources for this information, and numbers from these sources can vary widely, which is why we decided to give you all of them, and let you choose which metric to look at. We’ve successfully incorporated data from Yahoo!, SEOmoz and MajesticSEO. We’re also pulling, in real-time, the latest blogs linking to any site. Here’s a preview of what you’ll see very soon.

We’ve used the Top Rank Blog as an example, and you’ll see from these numbers, they’ve done an impressive job of developing link worthy content. How does your blog compare? Next week you’ll be able to find out.

[click to enlarge]

The canonical tag is simply a way to silence webmasters.

Yesterday at SMX West it was announced that Google, Yahoo! and Live have agreed upon a method to help webmasters define original content within a site. The canonical tag is a meta tag used to tell search engines which page to list in SERPs when multiple listings of the same, or very similar content exist in their databases.

On-site duplicate content has been a big issue since the beginning of the web. There are lots of things that could cause search engine spiders to index the same content at multiple locations. URL canonical variations (http://www.exmaple.com vs. http://example.com) is the most common issues, but there are others. This is a good explanation of the canonical tag and how it’s implemented.

In september the Google Webmaster Central Blog published a fairly extensive post on how search engines handle on-site duplicate content in hopes of dispelling a lot of the rumors and speculation circling the issue. Despite how clear the article was, and all the other resources on the web, there were still LOTS of questions about the issue.

As new webmasters come into the space trying to understand SEO and mitigating duplicate content the easy thing to do is ask Google. If you’re site is set up correctly duplicate content shouldn’t be an issue. The canonical tag, is not the end-all be-all of duplicate content. You still need a sitemap, good URLs, redirection from the www or the non-www to the correct path, etc. This tag is simply an easy answer to the duplicate content question.

What do you think? Have you implimented the canonical tag yet? Is it really THAT important considering all the other things that still need to be done?