I'm not that technical, but I'm frustrated that the problem with harmful URLs doesn't seem to want to go away. Microsoft's very own Jon Udell started 2008 with a very well written comment on .aspx considered harmful, but .aspx is still the standard default used in most SharePoint 2007-driven public websites. Over at CMS Watch, I did follow up on Udells comment with a posting on Location matters: URLs should be short, meaningful and permanent.
Today, many Web CMS vendors are actively promoting what they call friendly URLs, short URLs, nice URLs or whatever. Here are 2 quick examples:
- FatWire promotes their friendly URLs, which take this form www.fatwire.com/cs/Satellite/Page/Home
- Sitecore claims that their solution "natively delivers URLs that improve organic search results" with URLs like this www.sitecore.net/Products/Sitecore%20CMS.aspx?nav=t
The problem with the above examples is that they are technology and vendor-specific. They are highly unlikely to work in late 2010 as technology and vendors change. Sitecore might natively deliver URLs that Google likes, but bear in mind that the .aspx will not be state-of-the-art forever (just like it predecessor .asp) and once a new technology comes along, you will either end up with many broken links or you will need to spend time carefully managing redirects.
I'm sure you've experienced the dreaded Page Not Found 404 error. It happened to me earlier this evening on a large shopping site. When an enterprise presents a customer with a "404" the consequence is typically:
- less sales as customer cannot find what he/she is looking for
- user frustration due to expectations not being fulfilled
- low rankings in Google search results
- a browser bookmark or e-mail does not work, forcing the user to spend time finding the content (again)
Here are some good examples of harmless URLs from 3 different Danish organisations:
Try to take a closer look at the URLs on their sites for inspiration on how to get it right.
Note: Some vendors are worse than my 2 examples. However, to be fair, some vendors get it, e.g. EPiServer and eZ.
Do you know any other vendors that have got it right? Have you got any examples of vendors that still provide really nasty and harmful URLs? Likewise, let me know if you disagree and think this is not an important issue.
Just to clear up your misunderstanding:
Firstly, nice URL’s are mostly an editor driven feature, see e.g.:
* http://cbs.dk/nyheder_presse/hoejreboks_forside/arrangementer/2009_01_19_09_45_00_faglig_dag_paa_cbs_for_samfundsfagslaerere
* http://www.drk.dk/nyheder/081105+militaermanual+efterlyses
Which gives a good indication that even the best intended website structure can be ruined by a bad editor (Hats of to dsb.dk which actually maintains a good and stringent URL structure). The feature is also driven by the specific implementation of the Website CMS, not the vendor itself see e.g. the following EPiServer driven websites which I hope we can agree are not nice:
* http://www1.idrottonline.se/templates/NewsPage.aspx?id=268077
* http://www.skandiabanken.se/hem/templates/pages/SectionPage____1580.aspx
Secondly, the .aspx extension is applied primarily because of the nature of older versions of the Microsoft IIS webserver and .NET framework. The extension can be removed but requires configuration (which I guess is the same as .php on Apache). My experience is that this configuration is not easily sold to the customers and is therefore often skipped.
The problem is not applicable to the new IIS 7 webserver (on Windows Server 2008), so my guess is that future websites running .NET Platform CMS’s will no longer have this problem.
Last but not least; in the case of Sitecore, the URL’s are absolutely not vendor specific, and has not been for the last many releases of the product. See e.g. http://www.stenaline.dk, which runs Sitecore and has nice URL’s. In your example from the Sitecore website (www.sitecore.net/Products/Sitecore%20CMS.aspx?nav=t) the .aspx can be removed – and we agree that it should have been from Sitecore’s side. The %20 indicates that the editor has put a space in the page URL, which is a bad habit. Lastly I would guess that the ?nav=t parameter underlines a third party vendor-specific shortcoming, which is that analytics tools (like Google Analytics) cannot determine whether you have navigated the page from the topmenu or elsewhere and therefore must have a parameter which specifies this.
I hope this rather long reply helps you understand that your criticism is somewhat misdirected. We totally agree that the URL problem should go away, but try to primarily face the editors, customers and implementers (like me) not the vendors.
Thank you for the very helpful reply. A few points:
- Yes, editors and system integrators are often also to blame, but the problem starts with the vendor. If the system created harmless URLs out-of-the-box, there would be no configuration to sell to customers.
- Sitecore does not create vendor-specific URLs by default (unlike FatWire), but they do create technology-specific URLs, which is just as harmful.
If vendors does not understand this problem, can we really expect customers to pay a consultancy money to fix it on each and every project?
[...] for knowledge sharing and collaboration. If you take a closer look at the site, please note the harmless URLs. Also, Urchin Software by Google is used for website [...]
We made a conscious decision to enforce friendly URLs in the SilverStripe CMS, meaning the product will note install unless the (IIS or Apache) web-server is configured to permit it.
This is generally very good, although we get criticism on our forum from time to time, that it makes it harder to install. We think it is worth it — if we didn’t mandate it, then all too many installs would have poor URLs, like you state.
Another point to your post, is; (a) automatically generating nice URLS from the page titles, and (b) making it easy for content authors to alter those URLs, e.g. to shorten “Employment Opportunitities” to a URL like ‘site.com/jobs’. (You can see these at http://www.silverstripe.org/assets/video/cms.html )
[...] new projects, make sure you implement harmless URL’s, hereby preventing problems later [...]
Hi all,
First of all, let me state that I am not in any way technical, but I do am responsible for overseeing the Government of the Azores Portal, and we do have an ugly URL problem… I’ve come accross your postings as I did some research on the subject. As such, I would really very much like to hear from all of you: what can I do to make it better? Clues, hints, tips anyone? Our portal is built over CMS 2002 with Sharepoint 2003. The portal is organized by channels, in which each government service has its own channel and is responsible for editing it. Hope this description helps.
[...] management radar, is postponed to a distant future, so customers still have to fix accessibility, harmless URLs, and the buggy rich text editor on their [...]
[...] am always curious how vendors eat their own dog food, sometimes with mixed success. Percussion uses harmless URL’s on their website, but evidently it still requires work to make all old links [...]