URL Shortening Services Suck (and could be Better)

Thanks to the prevalence of microblogging, and before that the infamous 80 column screen, friendly (or keyword-stuffed) URLs have run into character limit issues. Long URLs are great for both SEO and usability. They give both users and search bots an insight on the page's content before actually visiting it. This doesn't work so well for Twitter's 140 character limit, though, so to work around Twitter and other constraints the concept of URL shorteners came up. These are simple redirect service, using a hash or key to perform redirects from a short URL to the full friendly one.

There are a few benefits from short URLs. They can be shared easily, are shorter to remember, and may be set up with tracking. Quite a few services exist for URL shortening, including bit.ly, t.co, and tinyurl.com. Most of them offer APIs for developers to create short URLs for different purposes and some of them work directly with popular services to do auto-shortening prior to publish (like t.co and Twitter).

However, the negatives of URL shortening services far outweigh the positives. Linkrot, the breaking of links due to a failure of the service, is a huge issue. For many webmasters it is hard enough to keep their site up and all links working, let alone depend on multiple external services. Also, it is easy to hide malicious links with short URLs, as the user is not sure where the link may go.

The largest issue with URL shorteners involves poor implementation. Short URL services require extra lookups, which can slow down the user's experience. Each time a user bumps into a new domain several lookups need to occur, each one taking up bandwidth and time. This is often forgotten when people use a URL shortener. Where this starts to get frustrating is with Twitter's default usage of t.co, where every link is sent to first, even if it is already a short URL. So, a user will click and go to t.co, be redirected to bit.ly, and then finally be redirected to the final URL. I've seen chains like this be six redirects deep, taking up to 10 seconds to fully resolve.

An elegant solution does exist out there that answers the need for shorter URLs while maintaining a level of transparency, reducing unnecessary redirects, and keeping the domain handling in-house: personal URL shortening services. A few larger sites already own their own short domains, including youtube.com (youtu.be) and time.com (ti.me). Ideally any short URL generated from these domains could avoid redirects and just serve up the appropriate content, but these services chose to still perform a redirect. While this is better than depending on third-party solutions, it does not go far enough.

To completely answer this problem a few changes need to occur. First, microblogging platforms should be able to sense short URLs and avoid wrapping every single URL in their own proprietary system (I'm looking at you, Twitter). If a link passed in is already short enough or is recognized to be using an acceptable URL shortener it would be left alone. Second, and most importantly, private services would serve up the content instead of doing a redirect. There is no reason why youtu.be should redirect to youtube.com... it should simple serve up the video. If YouTube is concerned about duplicate content it can throw a meta noindex or a canonical rule and have all the links on that page serve up the normal domain. These two steps would clean up many issues that tiny URLs raise and improve user experience and decrease unnecessary web traffic.