Google just recently posted an article talking about their opinion on dynamic vs. static URLs. In short, Google is saying that dynamically created URLs from a content management system, i.e. URLs that contain information talking to a database such as:

/media_review.php?user_id=25&article_id=315

should be left as is instead of rewriting them to look cleaner (static):

/media-review/bruce/dnc-ratm-concert/

Here’s a direct quote from their blog post on the topic:

Does that mean I should avoid rewriting dynamic URLs at all?
That’s our recommendation, unless your rewrites are limited to removing unnecessary parameters, or you are very diligent in removing all parameters that could cause problems. If you transform your dynamic URL to make it look static you should be aware that we might not be able to interpret the information correctly in all cases… …if you’re using URL rewriting (rather than making a copy of the content) to produce static-looking URLs from a dynamic site, you could be doing harm rather than good.

The problem is that Google seems to be making a recommendation on what is best for their search engine crawling and not what is best for the user or web usability in general. There is no debate, URL rewriting makes websites easier to use. It makes people understand what they will be looking at when they visit a link, and in general provides clearer information than dynamic URLs. For instance, here on our blog you can see all of my posts by going to http://blog.imulus.com/bruce the url is clear and easy to understand. If you want to see all my posts for a certain category you can do this http://blog.imulus.com/bruce/css. This functionality makes logical sense. Websites with extremely complicated URL calls can utilize rewriting to help their viewers better understand where they are on the site. And in regard to marketing materials — the time I see a company willing to use a url with ?id=237 at the end for a marketing or advertising campaign will be my first.

The fact is this, URL rewriting is an extremely useful tool (ironically Google’s blog post about dynamic rewrites uses rewriting for the URL). And while certain rewrite schemes may hide data that Google would like to parse, that doesn’t mean people shouldn’t use rewriting. The idea that a usable standard should be changed just to make Google’s web crawling better is ludicrous. Google throughout their history of search has continuously accommodated for changing website methods. By stating that URL rewrites are improper Google is taking a strike at one of the best standards to come out of Web 2.0. They’re suggesting a machine’s readability is more important than a human’s. And guess what: they’re dead wrong.

Right on the heels of my Quantcast posting; I’ve decided to give Quantcast some respect for helping me figure out which of the microblogging services are on the rise. My gut told me Twitter and it looks like my gut was correct.

Initially I thought this chart was showing me the rise in interest in Twitter and the adoption of it by so many new users. However, ff we make this chart relative it even suggests that Pownce and Jaiku are loosing steam / users.

Is there anything wrong with Pownce and Jaiku? Jaiku yes, Pownce not at all. Jaiku was solid before Google acquired them but it has taken forever for Google to re-open Jaiku for the general public. Pownce on the other hand is a solid service and sometimes seems easier to use and more reliable then Twitter. Kevin Rose and gang are no strangers to high-use sites and I believe Pownce will compete better with Twitter over time.

Based on the few examples I’ve looked at, not very!

Site A: Enterprise Class / Fortune 1000 Web Site
This comparison shows Quantcast ESTIMATES in green, versus the ACTUALS in WebTrends. Both measures track “VISITS”. This is important because the default for Quantcast is “PEOPLE”. I still haven’t figured out the difference between the two. The variation between the two sets of data is significant and the traffic pattern seems inverted.

Site B: Regional Business Information Site
This comparison is between Quantcast ACTUALS in green and Google Analytics ACTUALS in orange. Again, we are tracking Google Unique Visitors against Quantcast Visits. Another important note is that when actual data is pulled in Quantcast you’ll see separate tracking for US vs Global. Since Google doesn’t distinguish, we’ll focus on the global on both.


Site C: National Ecommerce Site
In this example Quantcast faired to be a bit more accurate. I compared Quantcast People (ESTIMATED) with Google Absolute Unique Visitors and the results were a bit more accurate.


Trend Overview
These graphs below were interesting to me because of the traffic discrepancy despite both sites utilizing tracking codes. Both of these graphs are pulled from Site B. Google’s Max is 206 VISITORS per day, whereas Quantcast is showing about 330 VISITORS.

Google Analytics

Quantcast Visits

Summary
I think Quantcast is an excellent tool; however you should proceed with caution when using the analytics obtained from both it’s estimates and actuals. It is important to note that both measures are benchmarking Quantcast against WebTrends and Google Analytics; however both of these tools have been used for many years and are fairly trusted. I’m not sure I’m ready to fully trust in Quantcast. But I’m very open to differing opinions on this.

Yes, you can track file downloads with Google Analytics. Although it doesn’t automatically give you that capability by just dropping in the Google Analytics Code, here is a simple method to add that tracking ability. For each file that you want Google Analytics to track, you need to create a “virtual page” using the pageTracker function in each file HREF in your site.

Example:
If you site has a PDF called financial-report.pdf and the link is
<a href="/files/financial-report.pdf">Financial Report</a>
That code will need to be rewritten to read.
<a href="/files/financial-report.pdf" onclick="pageTracker._trackPageview('/files/financial-report.pdf');">Financial Report</a>


This works great for a limited number of files, but for sites which have multiple file downloads. You may want to try Brian Clifton’s JS Script.

XML sitemaps are a default for Web development at this point, yet I’m amazed about how many sitemaps are done improperly because developers use sitemap generators which either return partial or inaccurate coding. For the longest time we used http://www.xml-sitemaps.com/ and repeatedly ran into formatting issues with Google Webmaster Tools.

After trying a slew of various editors I think we’ve found a winner. XMLEcho isn’t the quickest option in the World but it certainly produces clean and accurate sitemaps. Creating an account is simple and quick, plus the service gives you the option to create sitemaps of unlimited size… best of all, it’s free!

Nice job XMLEcho!