The URL Shortener-SEO Cage Match
Making the case for a Hungarian Notation variation for URL hierarchies One of the top discussions out in the ether these days revolves around URL shortening. One of the reasons folks flock to URL shortening services like bit.ly and TinyURL is because web sites and applications use exceedingly long URLs. Many times this is because of exposed file system hierarchies (a potential security risk, by the way) and a desire to take advantage of descriptive file names for SEO and informational reasons. Recently Delicious founder Joshua Schachter expressed his opinion that URL Shorteners are bad for the web, while Ben Parr at Mashable refutes with a few reasons he believes the services are useful. The use of URL Shorteners are somewhat out of the control of developers. They can’t know whether they’ll be used or not, and it’s really out of scope of their responsibilities. But the question then becomes, why don’t developers simply generate shorter URLs in the first place? Why don’t they tighten up the file system hierarchy and present something more reasonable to the user? Wouldn’t this, then, eliminate the need for URL shorteners (and the debate)? After all, very long file names and deeply nested hierarchies waste bandwidth and money. It turns out that there’s a lot more to consider before shortening URLs or condensing file system hierarchies. Last week’s discussion on the potential waste of bandwidth (and money) from excessively long URLs elicited several responses that were valid and insightful. LONG URLs AREN’T THE ONLY BANDWIDTH HOG The first reminded me that cookies are far more piggish in their consumption of bandwidth, with 4-5KB cookies stuffed in HTTP headers like so much stuffing at Thanksgiving being not unusual these days. That reminder is a good one, because it’s a trickier problem to solve than simply shortening a URL. In other words, that’s a discussion for another day – but we will have it eventually. Suffice to say there is a technical solution (a cookie jar) to the problem and we’ll dive into later because, well, it’s not really germane to this discussion. The second response was more directly related to the negative impact of automatically shortening URLs on business related functions and goals. Having targeted keywords in your url can provide a (slight) SEO boost to a pages relevance if it matches the query. http://www.seomoz.org/blog/11-best-practices-for-urls http://www.seomoz.org/article/search-ranking-factors Using a meaningful url structure can help with usability as it can provide context (or what Jakob Nielson calls information scent) for the site’s architecture. http://www.useit.com/alertbox/20030630.html This raises an important point to consider before deciding to reduce the length of file names. If the importance of “search” to your business is such that the loss of search traffic due to the removal of keywords from URLs and subsequent SED (Search Engine De-optimization) would be significant then perhaps URL shortening is not a good idea. If you’d notice it, in page ranking or traffic flow or however you’re measuring the effectiveness of SEO in your organization, then you’ll definitely want to consider this against the potential costs of long URLs. TRIM THE FAT ELSEWHERE If it’s the case that the business – and they really must be the final arbiter of such a decision because, well, business is the reason you’re serving up web sites and applications in the first place – is willing to absorb the cost of lengthy URLs in the name of SEO then you may need to look elsewhere for a reduction in bandwidth costs. As mentioned earlier, cookies are a common bandwidth hog. Unfortunately the implementation of a cookie-jar functionality is not as straightforward as it seems, though it is likely one of the places you can immediately trim fat that will have a significant impact on bandwidth use. If you can trim them down in the application, do so from the start – it’s always easier to develop an application with leaner cookies in mind than to rework the application later or implement a cookie jar on an intermediary. For example, perhaps it’s the case that your URLs need to contain certain keywords that are going to necessarily make them long. But do the supporting assets need to contain lengthy, descriptive file names? Do you really need to use /assets/monthly/images/this/is/ridiculous/myimage.jpg when something much shorter, and simpler, would suffice? There are plenty of supporting object types that make up a web page that are not as likely to affect SEO efforts one way or another. Consider the file system hierarchy you have in place for: Scripts CSS Images Commonly reused content elements (headers, footers, menus, etc…) And examine whether they are using unnecessarily lengthy URLs. The impact of reducing the length of supporting objects’ file names while maintaining a lengthy page URL in the name of SEO is likely more significant, because the ratio of objects to page URL is, on average, 50:1. A reduction even in the hierarchy naming structure can have a significant impact on bandwidth. These types of reductions are the reasons folks turn to compression. The trade off between performance and compression is lessened with the use of an intermediary capable of intelligent compression, but just turning on compression in general can certainly buy you quite a bit of bandwidth, which means you can leave the long URLs and file system hierarchies alone. TRUST ME, YOU’LL LOVE THIS SITE As is the case with URL shortening services, there are trust issues with shortened URLs. Rick-rolls are the least of your concerns when presented with a shortened URL for which the domain and page URL are obfuscated. Using an intermediary to shorten the URL alleviates some of the concern because the domain is clearly visible, but many folks want more information in the URL from which they can extrapolate information and make a decision whether to follow the link or not. The difference between shortening a URL yourself using an intermediary or network-side scripting (or just doing it as a matter of design during development) is that you aren’t obfuscating the URL, you’re just shortening it. The concerns with URL shortening services is partially due to the fact that they are misnamed. Oh, they shorten the URL, but in order to do so they completely obliterate any reference to the original and essentially present the user with gibberish. There is a big difference between obfuscation and shortening. While the latter can lead to the former, it doesn’t have to. Shortening schemes can be developed that adhere – at least in spirit – to usability guidelines such as those presented by Jakob Nielson and that don’t erode the user’s trust. It takes time to design such a hierarchy or scheme, but it can be done. SHORTEN, BUT DON’T OBFUSCATE Consider that programmers have long used such techniques that allow other developers to identify variable names “at a glance”. Hungarian notation is one such technique. By prefixing variable names using a codified system of identifiers, developers can easily distinguish a short integer (sNum) from a long integer (lNum) and so on. So perhaps what we need is to develop a “Hungarian Notation” for web sites; something that’s simple, easy to learn, and can be used as identifying information in a URL so that we can simultaneously shorten URLs (at least by reducing the hierarchy) while maintaining the business’ need for SEO.5-Minute iRules: What’s a URL?
On last week’s podcast, we riffed for a few on the common misunderstandings of what a URL versus a URI are in terms of writing iRules and communicating said development in the forums. I had earlier in the day been looking at Prezi and got the idea that I should attempt my first Prezi on breaking down the various components of a URL and URI. Be gentle: Related Articles HTTPS Redirect for a specific URL, URI - DevCentral - F5 ... multiple url/uri rewrite w/multiple default statements ... URL-uri rewrite problem using Default - DevCentral - F5 DevCentral ... LTM for URL/URI Filtering only (Very Urgent) - DevCentral - F5 ... Small URL Generator: Part 1 > DevCentral > F5 DevCentral > Tech Tips iRule to use specific server based on URL/URI request - DevCentral ... iRule: modifying the uri without a redirect uri based load balance - DevCentral - F5 DevCentral > Community ... iRules: Rewriting URIs for Fun and Profit Different behaviour with HTTP::path and URI::path - DevCentral ...
DevCentral Top5 04/03/2009
Having failed to coerce the calendar to allow the Top5 to fall on April 1 st , I'll have to leave you without any gag comments, Rick Roll links, or otherwise. That's just as well though, since there's plenty of goodness on DevCentral to cover this week. We've been busy, and that's usually a good thing. Hopefully you'll agree when I say it's reflected by more and more cool content. Here's your DevCentral Top5 for the week: iRules Event Order http://devcentral.f5.com/s/Default.aspx?tabid=63&articleType=ArticleView&articleId=344 I'm very pleased to present the definitive document of event order within iRules. It's been requested many times and has been a long time in the making, but it's finally here. This walks you through each of the current events usable in your iRules and details in what order they occur in inside a given connection. Many thanks to those that helped with this. I think it's going to be a huge benefit to people writing iRules, and I'm excited to have it available. If you're even marginally involved or interested with iRules, take a look at this one. Reason #5 That You Need File Virtualization http://devcentral.f5.com/s/weblogs/dmacvittie/archive/2009/04/02/reason-5-that-you-need-file-virtualization.aspx Don continues his awesome File Virtualization series with reason #5 - disk savings. Going into detail he discusses the ways in which you can make use of this kind of virtualization to produce some pretty huge cost savings within your deployment or your organization as a whole. Not only do you get to better utilize current storage, but you get to change your purchasing plans for future storage as well. He explains it far better than I can, so follow the link and read on. Creating A Graph Template in Cacti http://devcentral.f5.com/s/Default.aspx?tabid=63&articleType=ArticleView&articleId=346 Following on to his extremely popular article on Cacti working with LTM, Jason saw fit to produce a tutorial in screen capture form that walks you through creating a template for graphing Web Accelerator info. Not only is graphing with Cacti and other such software a popular topic on DevCentral and elsewhere, but this kind of detailed walkthrough makes it even more cool. Jason's definitely the group expert on this stuff within the DC team, so when he talks about it I'm inclined to listen. This time is no different, and it's worth the time to listen up. If you're going to try to follow along I recommend downloading the full screen version so you can read his screen. Real IT Interview - Nojan talks CDNs with Jeff http://devcentral.f5.com/s/weblogs/realit_extras/archive/2009/04/01/real-it-interview---nojan-talks-cdns-with-jeff.aspx With Real IT at full steam ahead the content is flowing out, fast and furious. This interview is one of the many tidbits that I thought was very cool, and my favorite of the bunch this week. Jeff sat down with Nojan for an extended discussion about delivering content worldwide. They talk about some different options, pros and cons, and experiences with some of the possible solutions. It's an interesting look at a topic that garners prime real-estate just amongst most IT news sites thanks to the prevalence of the issue. This one's got some good stuff in it. Take a look for yourself. How to recoup the costs associated with long URLs and variable names http://devcentral.f5.com/s/weblogs/macvittie/archive/2009/03/31/how-to-recoup-the-costs-associated-with-long-urls-and.aspx In her typical fashion Lori brings up a very interesting topic that made me stop and think. Long variable names and more specifically long URLs can, in the right situations, contribute to a pretty hefty chunk of used bandwidth for a given application. I honestly wouldn't have thought they could be that much of a problem, transfer wise, but 74Mb/sec? That's outlandish, and very possible given the right scenario. Sure it's an extreme case, but it's used to illustrate a very valid point. There are savings to be had by saving space over the wire - big savings. This is a great read and a very thought-provoking topic, at least for me. Big kudos as well to the commenter that brought up the idea of network layer cookie jar type functionality to cut down on unnecessary transfer even more than URL shortening. Very cool stuff. Looks like it's time for an iRule … There's your Top5 for the week. Feedback and comments are more than welcome, as always. Also, drop me your ideas for what should be featured and you just might see your favorite article of the week show up here. #Colin
