While I’ve written and posted an article on creating a simple URL hashing service, I’ve always had mixed feelings about URL hashing or shortening. I see the advantages of shortened URL’s for mobile devices and short message services like Twitter but there are several issues with the concept that need to be well understood before implementing and using these systems.
In its simplest form URL hashing allows the user to shorten the long descriptive URL’s generally created by modern CMS systems into short unintelligible URL’s that fit better with input-length restrained services such as Twitter or SMS.
As an example the URL www.example.com/jelloisgood/makegreenjello.html might become http://bit.ly/cr45Gg.
Where are we going?
Looking at that example it is clear that the longer URL will take you to the domain example.com and that the content is likely about making green Jell-O, as a user you may have visited example.com before, recognize the domain and trust it.
The short URL has no descriptive element to it. You cannot tell where the shortened URL leads without clicking on it which could cause serious issues if the shortened URL leads to something malicious like a malware site or even just something that is not safe for viewing at work or near children.
To compensate for this lack of transparency many shortening services have implemented a doorway page, bit.ly for example will take you to a doorway page that has link stats as well as the long link if you add a + to the end of the URL (http://bit.ly/cr45Gg+).
The doorway page removes the issue with transparency but adds another click the user has to go through to get to the content. More so, users have to be aware of the doorway page feature in order to use it.
Note – for some services the doorway page is also used as a mechanism for advertising.
Spam and ham
Shortened URL’s have a great possibility to be used in spam email, instead of spammers having to register several domains or exploit others domains they only need one that they can then shorten with several different URL shortening services.
Few URL shortening services make it quick and easy for users to report abuse for a particular link, most do not take spam into consideration and others require that a user takes time to send an email to the service. Reporting of abuse should be a one-click operation for end-users and the services should be monitoring this closely.
If a particular shortening service is being used for an excessive amount of spam the URL shortening site itself may be blocked by anti-spam systems. This could cause email with the shortened links to end up in the recipients spam folder or fail completely.
Service disruptions and closures
When shortening services experience technical issues the shortened URL’s may stop working temporarily, if the service closes the links will never become live again.
Many argue that on Twitter the life-span of a given message is very short and history doesn’t matter, yet when one of the larger of these services stopped in late 2009 it made the news:
www.dailyfinance.com/story/investing/url-shortener-tr-im-quits-citing-no-money/19124469/
informationweek.com/news/internet/social_network/showArticle.jhtml?articleID=219100562
Note – tr.im continues to support their API until the end of 2010 to give application developers time to flip to other services http://tr.im.
Iframes and Link-juice
Some URL shorteners have implemented IFRAMES in the past effectively allowing them to borrow or steal “link-juice” from content providers.
http://techcrunch.com/2009/04/02/diggbar-keeps-all-digg-homepage-traffic-on-digg/
While it doesn’t necessarily impact revenue for the content provider there is a possibility that it impacts the content provider’s site rankings while improving the URL shortener’s rankings. Basically this means they get credit for any traffic flowing to that link and can use it to bolster their position for additional advertising revenue.
Which domain?
When you open a webpage there’s a lot of things going on behind the scenes, without going into too much detail I just want to touch on DNS and the impact of these services.
Very basically, DNS or Domain Name System is how networked computers turn the numbered addresses (IP address) each computer is assigned into a human readable format. The DNS service also allows for the IP address of a server to change without breaking links to a server, for example if www.example.com is hosted on the IP 10.10.10.1 but is moved to a new datacenter and assigned an IP of 10.10.10.44 the DNS entry for the IP address would be updated so links to www.example.com would continue to function.
When you request a webpage, a resolver request is fired to the DNS to determine which IP address the domain belongs too, the IP address is then used to connect to the server hosting that webpage. That means that when a URL shortener is used you effectively double the number of requests required – one call to find the IP address of the shortening service, the second call to find the IP address of the destination site.
While DNS is quite a robust distributed system some argue that the additional load placed on these servers in unnecessary and that realistically these shortening services step on one of the problems the DNS was meant to reduce, namely human readability of URL’s.
Still not sure
So while I’ve written and posted an article on creating a simple URL hashing service, I continue to have mixed feelings about URL shortening. Allowing users to have a shorter version of a URL can be key to marketing a site effectively on mobile and short-message platforms but can come at the cost of transparency and security. Web designers, developers, and marketers should put some thought into what these issues mean to them before implementing such a solution.
