Tag Archives: WordPress

Why an ending slash on a URL matters (or not)

Recently I read a report from Google about the status of their own Web sites in terms of Search Engine Optimization (SEO). Uhh, Google, the search engine giant, is looking how the own sites are behaving when a Web crawler is stumble over them! To be honest, it’s fully clear to me that in such a big company, like Google, not all is perfect in the sense of cooperative appearance. There are different projects, different teams, with different strengths and weaknesses, different priorities and of course different managers. To summaries the report: In some areas Google does a good job, but in most it doesn’t.

How to optimize

Although SEO even lead to a business case for some companies, I believe it’s not so hard to do and in my humble opinion the most important points, a Web site owner should take care of, are the following 6:

  1. Usage of Web standards like XHTML 1.0 Transitional and making sure the Web site conforms to them.
  2. Usage of the <title> tag.
  3. Usage of meta tags like description and keywords.
  4. Usage of the header tags <h1>, <h2>, and so one.
  5. Adding canonical URL information to every site of the Web site, if a specific site is reachable from more than one URL.
  6. Writing good content.

Although 6. is quite obviously, it’s the most important point and often people forget about it and wonder why there is no traffic on there Web site at all.

1.-5. are technical aspects and if a Web site owner is using e.g. WordPress the Web site should be in good shape, already. Of course this depends a little bit on the used theme and the plug-ins the user has installed. For item 1. I always propose to make a bug report if a theme or a plug-in doesn’t confirm to them, as I have done for the theme used in this blog. Conformity could be easily tested with the W3C Valitator.

Why one should use HTML tags like the title, the meta and the heading tag is also easy to understand. A Web crawler isn’t a human, so he can’t distinguish between structural information because e.g. the font size is different. Helping him by semantic marking some of the text with the available tags of HTML is therefor a good idea. For the same reason using HTML tables to layout a page is a bad idea. Although this was standard in Netscape 4.0 times it isn’t necessary anymore these days.

Slash or no slash

Item 5. is about giving the Web crawler a clear idea about the structure of your Web site in a whole. Comparing 64k-tec.de/test and 64k-tec.de/test/ as a human doesn’t seem to be very different. From a technical point of view, it is. Considering that the Web itself is grown up in a UNIX environment, the former points to a filename and the later to a directory. This means for a Web crawler two different sites are targeted. The easiest way to fix this, is to decide about the nomenclature globally used. Either use the one form or the other. WordPress uses the “ending with a slash” variant (most of the time). By the way, this is also important for 64k-tec.de/test/index.html and other variants. Another way is to tell the Web crawler the canonical address even if the site is served by another URL. This could be done by adding the link rel tag canonical to the header of the page. On my homepage this looks as follow:


As you see, even on the top-level domain a slash is added. WordPress does this automatically for you since version 2.3. On older versions plug-ins for this task are available. The canonical tag is a good way to make clear which address is the base URL of a specific page. On the other side I see some potential for improvements. I have found two places in my blog where the base address isn’t targeted right. The first one is the tag for the site index relationship. It’s noted as follow, on my blog:


The second one is the link of the logo presented on top of every page on the blog. It use the following link:

64k

As you see the ending slash is missing, both times. It is not really a problem, cause the page itself use the canonical tag. The second mistake is clearly a failure of the theme. It’s not fully clear to me if the first wrong target is a failure of the theme or WordPress itself. It also happens with the default WordPress theme (version checked is 2.9.2).

Conclusion

Creating a Web site which is easily understandable by a Web crawler isn’t any magic. Of course you could make a pure science out of it. There are tons of plug-ins for WordPress available. On the other side considering some simple rules will help a lot. Reading Google’s hints or using Google webmaster tools might help, too. Even for Web crawlers from other companies.

On a last note, here is a nice article about how to effectively keep users out of your blog ;).

A simple WordPress plugin

As you may noticed I use WordPress for my blog. This is an unbelievable great piece of software. It has uncountable possibilities for enhancements and as soon as you begin to explore these, you start adding some of them to your own blog. One of the plugins I added was WPtouch. This plugin wraps your blog into a theme for mobile devices if they are detected. This works for the iPhone, the Android platform or even Palms webOS. The theme is styled in a way it makes the content more readable on such (screen) limited devices and moves the menus to some extra place.

Why writing a plugin if there are so many

On our web server we are using Power PHLogger for a simple user statistic tracking. Unfortunately this software isn’t maintained anymore, but it does it job very well. To use it you have to embed some JavaScript code and a blind image to every website you want to track. My first try was to add this code to the theme I use. This worked ok, but I soon realized that this has to be done on every update of the theme. Additionally this doesn’t work with plugins like WPtouch, as there the whole theme is replaced. I searched for a plugin which takes this job, but I didn’t find one. So what, I’m a programmer, time for writing it myself.

Creating the necessary bits of code

Plugins in WordPress are located at the wp-content/plugins directory below the WordPress installation path. You have to choose a name, I used phlogger, and create a directory with that name. The plugin itself is written in PHP and named like the directory with the php extension. As the title says, it’s a simple plugin with one public method only, as shown in the following code.

<?php
/*
Plugin Name: phlogger
Plugin URI:
Description: Adds the power phlogger code to the footer.
Version: 0.1
Author: Christian Pötzsch
Author URI: http://www.64k-tec.de
*/

add_filter('wp_footer', 'phlogger_footer');

function phlogger_footer()
{
 $l = '<script type="text/'."n".'mce:1'."n";

 echo $l;
}
?>

The method just outputs the code for the phlogger tracking. WordPress executes this method because of the add_filter call. wp_footer is the filter keyword for content which should be added to the footer of a webpage, just before the </body> tag. The comment on the top of the file isn’t only there for cosmetic reasons. It’s parsed by WordPress and shown in the Plugin admin page of your blog settings. So it have to be there.

Of course I could have been adding methods for setting the phlogger link or the user name, but for my case this wasn’t necessary. For more information on writing WordPress plugins have a look at the good documentation.

Conclusion

Starting to write WordPress plugins is easy. It makes even sense for so simple tasks like this, because it offers the possibility to inject code (and functionality) without changing WordPress or the theme itself.