The Problem with Frame-Wrapping URL Shorteners

April 13, 2009 by      
Filed under Web Stuff

A new URL shortener from Digg wraps your website in a Digg frame instead of taking users directly to your website. This results in a number of obstacles for the website owner.

Digg is not alone in utilizing this process. A platform allowing companies to manage Twitter profiles, HootSuite, uses ow.ly to shorten URL’s in much the same method. StumbleUpon will soon release su.pr which may also make use of the same frame-wrapping tactics.

The Digg Toolbar

Let’s go through some of the obstacles presented by these frame-wrapping methods:

First, let’s look at analytics as they perhaps take the biggest hit. Because digg.com’s URL shortener always wraps your site in a digg.com frame, it always appears that it is digg.com requesting your site. All traffic is cloaked making it impossible to see where it is originally coming from.

Therefore whenever digg.com’s URL shortener is used, no matter if it actually coming from Twitter.com, a rival’s site, an affiliate or Digg itself, many analytic solutions will always credit digg.com as the referring site.

It may even get more complicated if your social media campaign uses referrals from social sites as a metric. Through this route it can appear like digg.com is driving traffic to your site without your site ever even being submitted to digg.com.

Affiliates will also have an interesting role when this frame-wrapping technique is utilized. Most affiliates are prohibited by affiliate terms and conditions from frame-wrapping merchant sites in order to protect brands.

Since a frame-based URL shortener doesn’t always show the URL, or the full URL, of the site being pointed to, that site domain will end up hidden. For example, HootSuite’s URL shortener, ow.ly, link for bigmouthmedia shows the URL as http://www.zmogo… with the remainder of the address hidden.

So, as the URL’s become further muddled, the tracking codes of the affiliates may end up being passed around when the shortened URL is shared. It then becomes possible when the next gen URL shortener is used in combination with a site like digg.com that a large amount of traffic being driven to your site would benefit the affiliate.

It is important to point out that many affiliate tracking forms will be instantly visible if the URL shortener shows any of the full or long URL.

And next, SEO campaigns will also be affected negatively by the frame-wrapping URL shorteners. The elite first gen URL shorteners assign a 301 redirect from themselves to the initial “long” URL.

In the case where a link from a trusted site to another site counts as a vote from the trusted site to the other then the 301 redirect safeguards that as much of the vote passes through to the intended site as possible from the URL shortener. In circumstances such as this Google requests that 301 redirects be used.

Such is not the case when the frame-wrapping URL shorteners are utilized. The link’s worth is not passed through to the target site in this situation. The worth of the link remains with the URL shortener.

So what now for the website owner and/or internet marketer… complain about it? Seems like there are 2 options: find a way to adapt, or boycott those that implement shady wrappers.

Turning off the DiggBar:

There are two ways in which you can disable the Digg Toolbar. Go to your settings page and select “Never Show Diggbar for external links”.

The above preference is only available for people who are members of Digg. If you don’t have an account at Digg, open this page and hover your mouse between the “close” button and the feedback button on the Digg toolbar. Click the drop-down arrow and select “Always hide the toolbar”.

For an in-depth analysis of the Digg Toolbar, see: The Digg Toolbar Exposed; What’s in the code?

WordPress plug-in to block the Digg Toolbar


Comments

One Comment on "The Problem with Frame-Wrapping URL Shorteners"

  1. Curious on Mon, 13th Apr 2009 4:14 pm 

    > Because digg.com’s URL shortener always wraps your site in a digg.com frame, it always appears that it is digg.com requesting your site.

    Is this really the case? Your browser is still loading the content in the iframe with a direct HTTP call, I’d think digg.com would always be the REFERRER but not the request source.

    It would still muck up your analytics though, the whole thing is an obnoxious move on the part of Digg.com.

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!

You must be logged in to post a comment.