I think it’s quite possible Twitter and similar micro-blogging services may be responsible for a great deal of future Linkrot. This is in no small part due to Approt. (I wrote about Approt way back in April 2006. Approt is basically when a Mashup or some web application disappears causing a cascade effect on dependent applications, sites, etc.) Linkrot, of course, is simply when hyperlinks go bad due to moving or disappearing web pages.

In short, (literally in this case), microblogs allow for only a short squirt of messaging. That’s not enough to say much. In any case, one of the popular use cases for Twitter, et al, is to promote a recent blog post or otherwise point to a web address. Such a need often demands the use of some kind of URL shortening and re-direction service. The problem is when the re-direct service disappears.

Crunched down web addresses are obviously useful for a variety of people for a variety of reasons. Some web targets consist of a long string of parameter information. So when displaying via certain types of client software like chat or whatever, it can be convenient to use a shorthand version. Though for most applications, I’m not quite sure if the effort to generate a small URL is really all that easier then just using a typical hyperlink with a label and embedding the href as usual. Whether one is using raw HTML, a WYSIWYG editor, blog software, most office applications or whatever; that’s just usually not that hard to do. So, for example, I don’t at all understand why people do this in PowerPoint or similar presentations. I’ve seen it. I just don’t understand the reasoning.

The thing is, the increased popularity of microblogging and similar services likely exacerbate this problem and could quite easily end up creating a whole bunch of content with dead links at some point.

What Happens When the URL Cruncher Disappears?

The reality is that these URL services have no discernible business model. There may be a case to be made that the traffic stats may have some value. But will such value be monetizeable to the point it can support a growing service? Consider for a moment if a particular service gets very popular. Say, just for example, TinyURL.com. As cheap as it may be to generate a hash code and re-direct, at large volumes there’s still some potentially significant costs. Assume for just a moment such a service goes * Poof * one day. There will be – all at once – a whole slew of very dead links in a wide variety of places. What this may or may not do to search engine algorithms that use link popularity as a weighting mechanism is anyone’s guess. But the obvious immediate effect is a whole lot of historical content with bad links. According to a recent Jan. 8, 2008 Mashable post on URL Shortening, there were over 90 URL Shortening services. This is likely because they’re not that hard to create and folks feel they can add a feature or two. Even if some kind of paid model for a few top services emerges, at least most of these are likely to go deadpool at some point.

When Bad Things Happen to Good Links

Take a look at Tweetl. As of this writing today, Jan. 13, 2009, their home page says, “All services, with the exception of redirects, have been temporarily turned off.” OK, how long until those go bye-bye as well?

Another service people seemed to like, urltea.com, died sometime mid 2008. They’re still listed under Google Code with a link to a dead page http://code.google.com/p/urltea/ You’d think of all people Google would catch a bad link. What happened to links that used this service?

Do You Really Need a URL Shortener?

The only apparent use case to really need a URL Shortener are microblogging tools or places where a web or client software doesn’t allow proper formation of a hyperlink. This works and maybe makes sense for chat, which is usually not meant to have much permanance, but other than that, it seems to be used just to be in vogue. As is sometimes the case, things that seem popular aren’t always good ideas.

Solving the Problem

Client software or services need to make it easy to create links. It’s really just that simple. Chat software needs to allow for link creation inline with text, microblogging services need to allow for link creation inline with text, etc. etc. Until that happens, any content that’s sourced from such venues, (be in mining chat logs or web pages based on microblogging), is at double-risk for link failure. In the first case, due to a resource that moves or dies all on it’s own, and in the second case – en masse – from a dead shortening/re-direct service.

An after the fact solution might be for a heading down the tubes business to share it’s hashing algorithm so serives can fix the problems in pre-existing content. But this is obviously a weak and inconsistent possibility.

In short, avoid short if possible.