This doesn't touch on WordPress as much as on general site design principles, but as these steps are often misunderstood and they very much determine whether your site is ever going to be successful, I decided it needed to be in there. The next article in the series will be more WordPress focussed, going on about design, and turning a design into a theme and more. Stay tuned for that, but for now, start reading: Your website: from goal to structure.

Using WordPress as a CMS article series is a post from Joost de Valk's Yoast - Tweaking Websites.A good WordPress blog needs good hosting, you don't want your blog to be slow, or, even worse, down, do you? Check out my thoughts on WordPress hosting!

Let me show you what got me so wound up:

#1 Canonical Link Plugin

This Canonical Link plugin consists of the following code:

function canonicalink() {
  $request_uri = parse_url($_SERVER['REQUEST_URI'],PHP_URL_PATH);
  echo "<link rel="canonical" 
    href="http://{$_SERVER['HTTP_HOST']}{$request_uri}" />";
}
 
add_action('wp_head','canonicalink',1,1);

If you know PHP, you can see what it does: it parses the current URL, strips out URL variables (if you've got any) and displays the current URL as the canonical link element. Of course the easy way would have been to do this:

function canonicallink() {
  global $post;
  echo '<link rel="canonical" href="'.get_permalink($post->ID).'"/>';
}

This would not rely on the current URL being ok, because it doesn't necessarily have to be. This would have been a better solution. Were it not for one simple thing: WordPress does this by freaking DEFAULT. Check out rel_canonical if you don't believe me. It was added in WordPress 2.9. Why this get's me wound up? Because the plugin author updated his plugin today, and updated the readme.txt to tell everyone that the plugin is compatible with WordPress 2.9.2. That's just bloody stupid.

Ow yeah I do have a canonical plugin myself, it allows you to set a different canonical URL for a post, quite useful, actually :)

#2 All in One Webmaster

This plugin allows you to do things that other SEO plugin which is not "All in One" either, with or without a premium option, has been lacking for years. While it's not as stupid as #1, the features might actually be useful to some people, I hate the fact that people call their stuff "All in One" when they're obviously not.

Bonus #3: All in one SEO pack

All in one SEO is not bad. It's just not "all in one" either. And it has a feature I loathe: automatic generation of meta descriptions. If he'd remove that feature I might actually not diss his plugin all the time :)

Confession: I'm looking into all these because I'm working on a new SEO plugin myself. Stay tuned for more info on that.

Two WordPress SEO Plugins you should NOT be using is a post from Joost de Valk's Yoast - Tweaking Websites.A good WordPress blog needs good hosting, you don't want your blog to be slow, or, even worse, down, do you? Check out my thoughts on WordPress hosting!

What I've done is I've added both hreview and hproduct microformats to our template. I'll briefly walk you through how to do that. It might be wise to start with Frederick's post on Driving more traffic from Google through Microformats. After that you can read my own post on how to implement hreview in WordPress or read on to see how to implement hreview-aggregate in Magento.

Adding hreview in 5 steps

Step 1: the 'hreview-aggregate' class

Because we've got more than one review for products, we're going to be using the hreview-aggregate version of the microformat. This wrapper class should be on an element that contains all the elements of the review. So we open:

template/catalog/product/view.html

And add the class hreview-aggregate to the product-shop div.

Step 2: the "item" reviewed

The second thing we should add is the item being reviewed, we'll use two classes here: item and fn. I've added this to the <h1> within the product-name class, still in the same file. So far, what we've got looks like this:

<div class="product-shop hreview-aggregate">
  <div class="product-name">
    <h1 class="item name fn">
      <?php echo $_helper->productAttribute($_product, 
          $_product->getName(), 
          'name') 
    ?>
    </h1>
  </div>

Step 3: the rating

Then you'll see a call like this:

<?php echo $this->getReviewsSummaryHtml($_product, false, true)?>

This calls to a template file that's hidden in:

/template/review/helper/summary.phtml

If you open this file you'll see a div called rating-box, containing a div called rating. Because this box outputs the rating visually using CSS, we'll need to make it machine readable as well. Luckily, there's a solution for that: we'll use the value-title method. Within the contents of the div with class rating, we'll add this:

<span 
  class="value-title" 
  title="<?php echo number_format($this->getRatingSummary() / 20,1); ?>">
</span>

As you can see, we retrieve the rating and turn it into a 5 point scale rating by dividing it by 20, so Google can understand it.

Step 4: the review count.

Next we have to tell Google how many reviews we've had for this product. In a span in the same file with the class amount, you'll find this info. I had to redo the code a tiny bit, it ended up looking like this (formatted for readability):

<?php 
  echo '<span class="count">';
  echo $this->getReviewsCount();
  echo '</span>'.$this->__(' Review(s)'); 
?>

So with the span count it only shows the number, the text "Review(s)" is actually outside of it. Otherwise Google wouldn't understand it.

Step 5: The pricerange

This last step actually caused me a bit more headaches, even though the end result is quite simple. We need to add the pricerange class to our price "tag", in order for Google to understand the pricing of our product. To do this, we open up:

/template/catalog/product/price.phtml

This is one big file, but don't get scared: there are two divs there with class price-box, just add the pricerange class there and you'll be ok, and quickly close that file before that code get's to your head!

Adding hproduct to your template

Step 1: The hproduct class

Open up view.phtml again:

/template/catalog/product/view.phtml

The hproduct class needs to go up in the source a bit higher than the hreview class, easiest way is to add it to the div with class product-view.

Step 2: Availability

The fn is already there because of our hreview implementation, so we can go right to availability. To add the proper classing open up:

/template/catalog/product/view/type/simple.phtml

You'll see that the class in there is already called availability. It's there twice: for in stock and out of stock occasions. The full code I made out of that uses the value-title method, and looks like this:

<?php if($_product->isSaleable()): ?>
    <p class="availability in-stock">
    <?php echo $this->__('Availability:') ?> 
    <span class="value-title" title="<?php echo $this->__('In stock') ?>">
      <?php echo $this->__('In stock') ?>
    </span>
  </p>
<?php else: ?>
    <p class="availability out-of-stock">
    <?php echo $this->__('Availability:') ?>
    <span class="value-title" title="<?php echo $this->__('Out of stock') ?>">
      <?php echo $this->__('Out of stock') ?>
    </span>
  </p>
<?php endif; ?>

Now I'll be honest: I have second thoughts about giving Google availability data for products. If Google were to act in the best interest of it's endusers, it would not show you in the rankings for a particular product when there were other sites that carried the same product that indicated they do have stock. So, use this part of hproduct with some prejudice.

Step 3: The product photo

Next up is the product photo. Open up:

/template/catalog/product/view/media.phtml

You'll see an img element with the id image, give it two classes: photo and fn. Some microformats parsers might have issues with using the fn from the hreview, and since this image contains the exact same title as an alt tag, adding the fn class here will help those parsers.

Step 4: Price

This step is easy: the default theme already has the class price around the price everywhere, so just leave it as is and you're good, otherwise, open up price.phtml and add it in.

Step 5: Brand

The last step to our hproduct completion is to add the brand. Open up:

/template/catalog/product/view/attributes.phtml

We'll use the fact that brand is an internal attribute name in Magento as well for this. Where it has a td with class data, change it into this:

<td class="data <?php echo strtolower($_data['label']); ?>">

By doing this all the data cells will have a proper class name, one of which will be brand, completing our hproduct microformat!

My presentation from Meet Magento

Microformats in Magento

So if you've followed the steps above, you should now have a nicely microformatted product page. Use Google's Rich Snippets testing tool to test it, and have a lot of fun using it!

Downloading the updated template

You can download the updated template from Magento Connect.

hreview and hproduct in Magento is a post from Joost de Valk's Yoast - Tweaking Websites.A good WordPress blog needs good hosting, you don't want your blog to be slow, or, even worse, down, do you? Check out my thoughts on WordPress hosting!

Now I hadn't paid too much attention to this new feature until we started testing a new search traffic monitoring tool we've built at OrangeValley, and I noticed that 5% of the traffic coming to my WordPress SEO article had such rich "jump to" snippets. I could see this because they entered the site with a URL with a fragment identifier (aka hash: #) in it.

Now 5% of the traffic didn't immediately make me go all nuts, until I started thinking about what this meant usability wise: instead of people having to search within the article for the content they came for, they're taken straight there. That's a bonus, right? I've yet to prove that this improves conversions, but I'd guess it would.

Researching jump to snippets

So here starts the research: how do we optimize for these rich snippets? In the post on the Google Webmaster blog accompanying the official release, they state that:

There are a few things you can do to increase the chances that they [these jump to snippets, JdV] might appear on your pages. First, ensure that long, multi-topic pages on your site are well-structured and broken into distinct logical sections. Second, ensure that each section has an associated anchor with a descriptive name (i.e., not just "Section 2.1"), and that your page includes a "table of contents" which links to the individual anchors.

When I dove more deeply into our stats, I noticed a couple of things:

• almost every article that has an internal Table of Contents is getting this kind of traffic
• those articles are getting more search engine traffic in general (probably related to their length too)
• they use different ways of identifying the anchor, and all seem to work
• their tables of contents are always marked up using a list
• articles with "just" inline internal links to other parts of the article do not seem to get this kind of traffic

How to create internal anchors

Basically there's three ways of defining these anchors:

1. <h2 id="heading">Heading</h2>
2. <h2><a id="heading">Heading</a></h2>
3. <h2><a name="heading">Heading</a></h2>

All three options require linking to them like this:

<a href="#heading">Heading</a>

Where my WordPress SEO article uses option #2, our Magento SEO is using option #1, and the examples Google gives are using option #3. I can't see any real reason to choose one over the other, so I chose the cleanest one: option #1.

Optimizing for jump to snippets

So what do we need to do?

It turns out this is awfully simple, you need to do two things:

1. properly identify the different sections of longer articles, and identify their headings with fragments;
2. create a table of contents, linking to these fragments.

While the Magento SEO article has a clearly marked Table of Contents, the WordPress SEO article only has a listing of internal links, without any heading. They do have one thing in common: a list, either ul or ol linking to the different sections with their appropriate fragments.

So your table of contents should look like something like this at the minimum:

<ol>
<li><a href="#research">Researching jump to snippets</a></li>
<li><a href="#createinternal">How to create internal anchors</a></li>
<li><a href="#optimization">Optimizing for jump to snippets</a></li>
</ol>

I'll keep track of this kind of traffic from now on, and I'll let you know if I find any more optimizations. There's one caveat to this: this is not based on a very large data set yet, and it just so happens to be that all of the pages with ToC's I found getting this traffic have these ToC's marked up as lists. It could be that other ways of marking up a ToC work too, I just haven't found a working example yet.

Optimizing for Rich “Jump To” Snippets is a post from Joost de Valk's Yoast - Tweaking Websites.A good WordPress blog needs good hosting, you don't want your blog to be slow, or, even worse, down, do you? Check out my thoughts on WordPress hosting!

Notice something? I know I did: there's no description there. So I clicked on and checked the page to see what could cause that, finding it was easy:

<meta name='robots' content='noindex,nofollow' />

It was listed right above the EditURI line that WordPress puts in by default, telling me they forgot to uncheck a box (that get's checked by default on some auto installers, I've been told on Twitter):

One issue though... If Google had actually seen that tag, it wouldn't have listed the site at all. So there had to be something else. And of course, there is: meet Webdesigner Magazine's robots.txt:

User-agent: *
Disallow: /

Sitemap: http://www.webdesignermag.co.uk/sitemap.xml.gz

The first two lines there prevent Google from indexing the site entirely. But it just became funnier... The fourth line was added by a plugin they're running, pointing search engine bots at their XML sitemap. Yes, the same bots they just forbade entry to their entire site... If you check out their XML sitemap, you'd notice they're running Arne Brachold's Google XML Sitemap Generator...

So: they installed an XML sitemap plugin, let's see what else they did: ah... Cool! They're running All In One SEO too! Now AIOSEO is "ok", except: it doesn't warn you for stupidities like these... Might be a darn good feature for an SEO plugin to check whether your site is actually allowing crawlers to come in, don't you think? Ah well, nothing can be perfect.

Anyway, this tells me one thing: Web Designer Mag needs help with their WordPress install. And they need it bad. If you work for them, and read this, feel free to contact me on Twitter or through the contact form. I'd be happy to help!

Web Designer Mag should fix its SEO is a post from Joost de Valk's Yoast - Tweaking Websites.A good WordPress blog needs good hosting, you don't want your blog to be slow, or, even worse, down, do you? Check out my thoughts on WordPress hosting!

The solution can be found in one single RedirectMatch line. This line should be placed above the WordPress code, or in the Apache config. The line is the following:

RedirectMatch 301 /([0-9]+)/([0-9]+)/([0-9]+)/(.*)$ 
http://www.example.com/$4

This matches every URL which starts with a date, and permanently redirects it to the new URL for this post. Ofcourse you could be running your blog in a subdirectory, like I am, in that case, the line would be:

RedirectMatch 301 /subdir/([0-9]+)/([0-9]+)/([0-9]+)/(.*)$
http://www.example.com/subdir/$4

This way, all your incoming links will still work, and thus count for SearchEngines and you have the benefits of the new URL structure.

Changing your permalink structure is a post from Joost de Valk's Yoast - Tweaking Websites.A good WordPress blog needs good hosting, you don't want your blog to be slow, or, even worse, down, do you? Check out my thoughts on WordPress hosting!