Last weekend, Google rolled out an update to its PageRank toolbar. For those that have downloaded Google’s Toolbar and installed it on your browser, it is the little green bar that appears next to Bookmarks on the Toolbar:

For a quick review, PageRank is a number that Google calculates for every webpage based on how well-connected the page is on the internet. It used to be one of the prime indicators of how well your site was doing with respect to linking value but these days its importance is diminished because other factors have been incorporated into the algorithm that appear to be offsetting its direct effect. 

Google updates the PageRank toolbar two or three times a year. In fact, there was a major update last spring. However, what is not often understood is that even thought the toolbar only updates every 200 days or so, PageRank updates constantly. So, if the toolbar shows that your PageRank has dropped a point, it does not mean that it just happened. It could have happened back in May and you are just finding out about it now.

That said PageRank is not as good of an indicator of how a site’s pages will rank in search engine results pages as it used to be. It is a better reflection of the number of links rather than the precise keyword relevance of the link. If you have been focusing your linking efforts on getting links from pages that are highly relevant to your site rather than just overall numbers, your PageRank might go down while your rankings for your most relevant key phrases go up.

Even so, a drop in PageRank is an indicator that should not be ignored. However, it should be viewed as a signal to do some deeper research into your site and not that there is necessarily something wrong. Is there an accompanying ranking issue in Google’s search engine results? Has there been a big change in inbound link numbers? Is your conversion rate dropping while your bounce rate rises?

If there are other issues, then maybe the linking strategy you have adopted needs to be re-evaluated. Take a look at the number of inbound links you currently have by verifying yourself as the Webmaster of your site in Google’s Webmaster Tools and take a look at the number and type of inbound links you have. If all your inbound links are good quality relevant links from the best sources in your industry, consider concentrating on increasing the number of inbound links that you currently have by increasing the range of sites where links to your site appear. If you have many inbound links but they are primarily from low ranking sites, you should focus your efforts on getting more links from higher quality sites that would be considered “authorities” or “hubs” in the sector of the internet that your site is concerned with. Of course, if you do not have an inbound linking program in place, this would be a good time to implement one. Set aside some time every week to look for link building opportunities and proceed accordingly depending on your focus. Remember that building inbound links from dubious sources too quickly can affect rankings so if your site is very new and has very few inbound links, you might want to take it slow. If you have many inbound links, then try to add up to 20% more links each month. This will allow you to grow your inbound links and also to account for any links that become obsolete.

If you haven’t yet downloaded Google’s toolbar, you can download it here: http://www.google.com/tools/firefox/toolbar/FT3/intl/en/index.html. (Remember to read the Privacy Policy because the toolbar sends information about you back to Google so you’ll want to know how that works: http://www.google.com/support/firefox/bin/static.py?page=privacy.html&. In return, Google will tell you a little bit of information about you and will give you quick access to Search, Gmail and other services.

Welcome back to my series on fixing canonical URL issues. In my last post, Fixing un-canonical URLs. Oh joy! Part 3, I discussed how case-insensitivity and having a default index file could negatively affect your URL canonicalization efforts. Today, we’ll talk about query strings and how they can affect your canonicalization efforts. A query string is a grouping of parameters and values at the end of your URLs that looks like “?podID=249&catID=31”. Let’s review the areas where your site can have un-canonical URLs:

1. Protocols (http and https)
2. Domain and subdomain names (sometimes referred to as host names)
3. URL paths
4. File names
5. Case sensitivity (when myPage.html is handled differently than MYPage.HTML)
6. Query strings
7. Combinations of any or all of the above

Let’s say you have a web page that is used as a landing page and you want to track which of your affiliates referred some visitors to your site. You give each of your affiliates the URL to that page, but add a customized query string to the URL that contains the name of that particular affiliate. The landing page, like many web pages, will show the same generic content regardless of the query string in its URL, but may have another section of the page that does change (even if it’s unnoticeable by a visitor or a search engine) depending on the query string. Your landing page tallies (in a database) the number of visits from each affiliate to the landing page. Though the treatment of URLs with query strings may vary from search engine to search engine, they have the ability to cause different content to show while using the same domain and URL path. You should consider query strings in your efforts to rid your site of duplicate content.

In addition to tracking affiliates and referrer sources, query strings are also used by web applications to display dynamic content from different sections of a site using the same page template or layout. In fact, this is the most common use of query strings in URLs. With this scenario, you can see that query strings allow the web page creator to show a variety of content dynamically while maintaining just one file instead of maintaining one static web page file for each set of content he or she wants to show. A good example of this is an ecommerce site.

If you happen to have a web page that shows one set of contents using one URL plus query string and the same set of contents using the same URL but a different query string, you may have an un-canonical URL issue.

To fix this, you probably don’t want to blindly 301-redirect all URLs that have query strings to the same, respective URLs with the query string chopped off for the simple reason that someone or something probably intended for those query strings to do something meaningful.

One pretty rare exception can be encountered when browsing a site that must remember something about you during your time browsing session. Usually, cookies are used to keep track of which visitor has which products in their shopping cart by storing your unique visitor session number. If the visitor’s web browser is set up to not accept cookies or the ecommerce application is not setup to use cookies, the session number may be appended to every URL the visitor uses to browse the store. That URL may look like: http://www.eample.com/store/privacy_policy.aspx?SESSID=233493JJG37272HB. If cookies were being used, the exact same content would show for any page you visit on that site, but the URL would simply not have the “?SESSID=233493JJG37272HB” part at the end.

Because, under normal circumstances, you want to use the query string appropriately in your web pages, one safe method to canonicalize URLs with query strings (that show the same content) is to add a robots meta tag that instructs the search engines to not index the page. This will work as long the same URL without the query string does not have the robots meta tag. Many times, however, there is a low chance that the URL with a query string is even known to the search engines because you would not publish that URL anywhere.

Another way to canonicalize URLs with query strings is to create SEO-friendly versions of these URLs. Creating SEO-friendly URLs would normally take a URL like http://www.eample.com/store/podID=249&catID=31 and turn it into something like http://www.eample.com/store/cellphones/nokia-8851-clam-shell-camera.html. It doesn’t make sense to create SEO-friendly versions of URLs such as http://www.eample.com/?affiliateID=1446545 because changing the affiliate ID in the query string would probably not change the content of the page substantially. There are various ways to create SEO-friendly URLs. Your CMS may already offer this. If you’re not using a CMS that supports this, you may have to resort to creating URL rewrite rules for your website. (The first part of this series has several links to resources about URL rewriting for both Microsoft IIS and Apache web servers.)

As the topic of query strings is the last item in the 7-item list above, my next post will wrap up this series and provide some tips in your efforts to rid your site of un-canonical URLs.

As most of us are aware, Google is the leader in terms of search market share. Regardless of where you look, this is the case. Although Google has held this lead strong for quite some time, it appears that Microsoft is trying to catch up by offering incentive-based programs in hopes of attracting more searchers.

Initiating these types of programs is not a new tactic for Microsoft.  MSN’s Search and Win, Live Search Club, Search and Give, and Live Search Cashback are few of their previous programs.  Their latest program is called SearchPerks.  SearchPerks is essentially a point system where users can earn “tickets” based on the number of searches conducted.

So how does it work?  To begin, a “Perk Counter” must be downloaded. This Perk Counter is designed to track search activity and award “tickets” for the number of searches performed on Microsoft’s Windows Live, MSN or Live Search. (A maximum of 25 tickets can be earned in a day.) One thing to note is that the actual search queries and the websites visited are not tracked.

At the end of the program, searchers have the opportunity to trade in their tickets and redeem prizes. These prizes vary based on the number of points accumulated. By simply participating in the program, the searcher will initially receive 500 tickets.

There are, however, a few drawbacks to the SearchPerks program. First, it requires a Microsoft browser, Internet Explorer 6.0 or higher, and a Windows PC.  Secondly, it may entice searchers to consider Live Search for their immediate searching needs, but will it make this their search engine of choice in the log run?  What will happen when Microsoft stops offering incentives? Lastly, what about those who participate in the program and just type random characters into the query box in an effort to receive more tickets?

Microsoft has acknowledged that SearchPerks is not designed to actually keep searchers searching. Instead, the primary goal of the program is to create awareness about Live Search, to introduce the search engine to new users, and to build loyalty. Overtime, they would of course like to see searcher’s behaviors and perception of Live Search shift in their favor.

My curiosity regarding the program’s limitations with regard to browser compatibility as well as my question about random characters counting as searches still remain. It will be interesting to see how yet another incentive-based program for Microsoft turns out.