With all the talk of AJAX these days and with my concerns about poorly implemented AJAX-based sites and what they may mean for the web, I’m once again reminded of an opinion I’ve had for a long time: Well designed URL is one of the most valuable aspects of the web. Put more succinctly:
Well Designed URLs are Beautiful!
The following are my (current) set of rules for how to ensure beautiful URLs:
Well Designed URLs Point to Content that Does Not Change
Theoretically, each URL points to a unique view of specific content, or a specific “state” if you will. And I content that should include URLs that point to dynamically generated web pages.
Of course many URLs point to content that changes that with each view (such as advertisements) and/or that is modified based on the current login state of the person viewing the content. Both of these cases corrupt the purity of the ideal stateless URL, but in my pragmatic opinion they are okay as long as the core content for a given URL is static.
URLs that point to home pages and section home pages often change their content, but to me that is okay too. Web users generally don’t expect portal pages to have static content, but all other URL should point to content that doesn’t change.
Well Designed URLs Don’t Change
This should go without saying, but then again how often have you found exactly what you were wanting on a search engine or in a website’s “links” section only to get a 404 after you click the link? Sometimes this happens because the website owner went out of business, but usually its because of a careless website owner/developer who simply reorganized the website without considering all the dead links they are creating, and all the opportunities for traffic they lost for themselves.
Of course most application servers and most content management systems make it almost impossible to “do this right.” For example, what’s with Microsoft’s IIS, now in version 6.0, that you can’t serve virtual URLs unless they have an extension (most commonly .aspx?!?) Sheesh!
Well Designed URLs Can Be Stored
When you see a web page you like, you should be able to bookmark its URL and return to view the same thing later. When you see a web page you want a friend to see, you should be able to cut & paste into an email where they can see in their browser exactly what you saw (this is especially helpful if what the see is a bug in your server-side scripting!) And when someone who is blogging or building out a website finds your related web page, they should be able to include your URL as a link in their web page, and it should work as a link for anyone that views their site. Plus, if a URL can be stored, it can be indexed by a Search Engine.
Well Designed URLs Only Use Parameters with Forms-Driven Queries
Many websites use parameters to data drive their website. In most cases, those URLs are just ugly. If I’m looking for Sweaters at Sears, I should click a link that points to www.sears.com/sweaters/, not www.sears.com/products?type=23.
Instead, URL parameters should only best used on pages that allow users to submit a query based entered into form fields. All other URLs should be composed and readable.
Well Designed URLs are Readable and Hierarchical
URLs can and should be part of a website’s user interface. Well designed URLs that are readable and Hierarchical provide wonderfully rich information to a website user about the structure and content of a website. Websites with non-readable and non-Hierarchical URLs don’t.
Well Designed URLs Mean Something
Besides being readable, a web page’s URL should mean something to the website viewer. Having “/honda/” in a URL helps the website user understand the site; having “/tabid23/” in a URL does not.
Of course who violates this rule the worst? Content management systems. And it seems the most more expensive the CMS, the worse it violates this rule (can you say “Vignette?”)
Well Designed URLs are Readable in Print
When you see a web page you’d like to reference in print, you’d want it to be readable, not a collection of what appears to be random letters and numbers (i.e. not like a “GUID.”) Imagine a reader trying to type in 38 apparently random letter and numbers; that’s simply a painful thought.
Well Designed Websites Have Atomic Leaf Nodes
How many sites have a URL to display a collection of items but no unique URLs for each specific item? Just as an atom is indivisible, so should be leaf-node web pages, each with its own specific and understandable URL.
Well Designed URLs Are Hackable
A website that has a web page for the relative URL “/cars/toyota/4runner” should also have a web page for “/cars/toyota/” and for “/cars/.”
Well Designed URLs Can Be Guessed
Let’s say that a website user is on a really slow link. If you URLs are well designed, chances are they can guess at the URL for the page they want. Of if you, godforbid, have a broken link, maybe they can correct it.
Well Designed URLs Are Only As Long and As Short As Necessary
URLs should be short. Short URLs can more easily be posted into emails and not wrap, and short emails can be printed in advertisements, for example. However, URLs should be long enough to make them readable, not obscure their meaning, and retain the website’s heirarchy.
If you can’t make URLs short enough to be readable, retain meaning, and retain heirarchy, create alternate URLs for print, advertisement, etc.
Well Designed Links Do Not Trigger JavaScript
How often do I find web pages with links that use JavaScript? Grrrrr!!!! (Can you say “__doPostBack()” Yes, I feared you could.) What’s wrong with JavaScript? Users often use browser’s status bar to view the URL give them a clue to where the link will take them. Not with JavaScript. Plus, many users hold down the shift key to launch a new window. NOT WITH JAVASCRIPT!!! (Can you feel my anger? Well Designed Links do NOT trigger JavaScript.)
If this is so bad, why is this done? For the application server developer’s convenience, and not for the user’s convenience; that’s for sure.
Well Designed Search Forms Always Use GET
Search engines result pages provide content too, and their URLs need to point to content that doesn’t change. Well of course they do change over time as they display what is current, but that’s appropriate for a search engine result page. If a search form using POST, its search engine result page URL is only useful when an action of a search form, and worthless in every other case.
For a perfect example of a search page that violates this rule, check out CycleTrader’s Search Page.
Well Designed URLs Have More Friends than Just Me
Of course I’m not the first to make the case for URLs, and I probably won’t be the last. Here are some of the better essays about quality URLs:
- Tim Benners-Lee’s Cool URIs don’t change.
- Jakob Nielsen’s URL as UI.
- Jakob Nielsen’s Pages Must Live Forever.
- Jesse James Garrett’s User-Centered URL Design.
- Pete Hopkin’s Good URLs Are Important.
- Adam DuVander’s Only good URLs.
- Thomas Powell’s and Joe Lima’s Towards Next Generation URLs.
- Simon Willison’s Quality news site URLs.
- Simon Willison’s URLs matter.
- Simon Willison’s Top web design mistakes.
- Nathan Ashby-Kuhlman’s Article URLs week: Principles.
- Mathew Thomas’ How to recognize a Weblog tool by its permalinks .
- Már Örlygsson’s Howto: Future-proof URLs in Movable Type.
- Peter Seebach’s Making URLs accessible.
- Anne van Kesteren’s URI (IRI) design.
- Brent Simmons’ Law of CMS URLs.
- Adam Moran’s Human Readable Web Addresses.
- Jennifer Kyrnin’s “Link Rot” Are You a Culprit? (Don’t Change Your URIs).
- Mark Pilgrim’s Cruft-free URLs in Moveable Type.
- Shirley Kaiser’s More on Friendly URLs.
- Paul Hoffman’s The User Interface of URLs.
- Olivier Thereaux’s Choose URIs wisely.
There are also a few tools that can help:
- For IIS: ISAPI_Rewrite
- For Apache: mod_Rewrite
Well Designed URLs are an Asset
Some people rail against the URL and say it is an overly technical anachronism to which non-technical people should not be exposed. I completely disagree.
Just like so many other technical things that have become such a part of common culture over the years to have become all but invisible, such as radio station’s frequencies, checking account numbers, ATM passcodes, and highway speed limits, so too will URLs become so straightforward that they’ll soon not even be recognized as technical. Instead, they’ll be viewed as obvious and valuable because they fundamentally are.
So, in a nutshell:
Well Designed URLs are Beautiful!
Wow. What a wonderful article on something that we fuss about in the background but completely ignore. While I agree with everything written, I feel you were a tad too harsh on links triggering JavaScript. No No. I am not saying you are wrong as I myself have had this experience a zillion times but still there could be very valid situations when links must trigger code. That said, I have seen people use JavaScript ‘just’ to open the contents in a new window. Now, something like that is despicable.
Arshad: Thanks for the nice comments.
Also, see: http://www.mikeschinkel.com/blog/IsUsingJavaScriptToEmulateClickingAnHREFABadTechnique.aspx
Well designed URLs do not reveal more than they need to in order to make sense. Can you say .aspx? .php?
http://www.mikeschinkel.com/blog/CommentView,guid,34d8ff59-526b-4613-9734-c2321073da14.aspx
Well designed URLs don’t end in ‘.aspx’ or have huge, ugly series of numbers, ‘GUIDs’, etc.
*cough*
http://www.mikeschinkel.com/blog/CommentView,guid,34d8ff59-526b-4613-9734-c2321073da14.aspx
*cough*
I agree totally. If you believe what you’ve said, then dasBlog must be killing you.
Look at my blog: all of the URLs are completely guessable. Once you’ve seen a couple feeds, you can try appending the feed URL to just about anything and you’ll get a feed version of it. Moreover, on the visitor side of things, you’ll never see an ID value in the query string.
Hi Mike,
Yes it’s true that well designed URLs are beautiful with the lots of best features which you have listed in this posting. The same task URL rewriting we did without using ISASPI_Rewrite in ASP.NET 1.1 , And it’s working fine :)
Generally we believe in our custom coding becuase we have the complete command over the applcation including the Search Engine Algorithm changes issues.
But absolutely this component is nice for those who don’t was to waste time for custom coding filter.
Hey, I had my blog email notifier misconfigured for a long time and I was dealing with a lot of other problems, so I haven’t seen these comments.
Matt: TOTALLY AGREE about .aspx & .php
Jon: TOTALLY AGREE about guids.
Bill: YES, it is killing me. But what blog tool is any better?
Matt, Jon, & Bill: want to help me take it up with the guys over at the dasblog forum? :) (http://www.dasblog.us/)
Andy,
Are you saying that by using custom coding in ASP.NET 1.1 and above that URL Rewriting can be handled? As far as I know, you are correct assuming:
1.) You are in control of the source code of the application and you want to modify it (sometimes you just want to let the app be developed and debugged by someone else)
2.) You are okay with having file extensions like .aspx, which I (and Matt above) prefer not to have because of how IIS is architected. I know that you can make IIS run everything through ASP.NET, but I know that when I tried that several years ago I ran into problems with that, I think it is that it eliminates the ability to have default documents in subdirectories, but I cannot remember for sure. I would love it if someone could remind me of the limits on this.
So, have I understood your comments correctly?
Also, to anyone else, this is a timeless topic. Please continue to comment even though this post is older.
I understand about URLs but what about i18n ? Can you expect to i18n all your urls so they can be beautiful in many languages?
I wasn’t familiar with i18n until I just Googled it (http://www.debian.org/doc/manuals/intro-i18n/), but you used it as a verb so I’m not sure exactly what you mean. Can you clarify exactly what you are asking, please?
What blog tool is any better? Is that a serious question because just about any non-ASP.NET-based blog engine has better URL capabilities? WordPress, for example, has some beautiful URLs. The blog engine I work on (Quick Blog) has great URLs (though they still require the .aspx extension because we aren’t willing to run everything through ASP.NET).
Bill:
Thanks for the comment.
>> What blog tool is any better? Is that a serious question because just about any non-ASP.NET-based blog engine has better URL capabilities?
Ya know, I’m not sure what I was thinking when I wrote that. I think maybe I had a point, but I remember I had just spent more than 8 hours cleaning up my blog, so maybe I was just loopy…!
>> WordPress, for example, has some beautiful URLs.
Funny you should mention that. I’ll soon be launching a new focused blog at http://blog.welldesignedurls.org/ and it’s on WordPress. And clean URLs is one of the main reasons for choosing it.
But I do hope to document how to use ISAPI Rewrite to clean up dasBlog once v1.9 stablizes so I won’t be working on an earlier version here:
http://wiki.welldesignedurls.org/DasBlog
I also want to try and convince the dabBlog team to have an option to *generate* clean URLs as well as write the HTTPD.INI file for ISAPI Rewrite (http://www.isapirewrite.com). If it’s not too much work, I might even do it for them.
>> The blog engine I work on (Quick Blog) has great URLs (though they still require the .aspx extension because we aren’t willing to run everything through ASP.NET).
I’ve not heard of QuickBlog. I googled for the term and found something that looked like QuickBlog as the name of something GoDaddy offers. I assume that’s not it?
Anyway, how about documenting it at http://wiki.welldesignedurls.org/?
If you’re is build on ASP.NET, maybe you could do the same thing with ISAPI Rewrite?
I can’t believe you just wrote an entire article about REST style urls without actually saying REST. Have you not heard the term?
Hey Ramon:
Thanks for the comment. Actually, there are probably a few people on the REST-DISCUSS list that would debate your assertion. :) I’m over there now and will soon be debating away.
But honestly at the time I wrote this I was not thinking about REST nor had I studied it much. I was instead thinking about URLs from a end-user perspective.
Recently however, I have been thinking a lot about REST and see a potential explosion of what I am calling "Lightweight Web Services."
In my new framework I made sure the urls are as clean as possible. Plus I never allow filetypes, which are ugly (ie .html .do .jsp) but only clean words. REST is definitely the way to go.
thecodist: Cool. Tell me more about your framework…
BTW, I’ve been thinking about extensions a lot. Here’s my latest take:
— Pages that return (X)HTML are the default web page. They SHOULD NOT have extensions of any type (.htm(l) if you must, but preferably not any.)
— Pages that are not (X)HTML such as .GIF/.JPG/.PNG/.PDF/etc. which are files that the user is familiar with and with which the user might want to save to their local computer SHOULD have appropriate extensions.
— URLs SHOULD NEVER incorporate anything that would expose unimportant implementation details (i.e. never .asp(x), .php, .do, .jsp, etc. and no "www2" and "www3" subdomains for round robin DNS) URLs should provide be a conceptually organized VIRTUAL LAYER on top of the implementation.
Anyway, check out my new blog specifically on this topic over at http://blog.welldesignedurls.org/
In general I agree with this article. But not everything is hierarchical.
Consider tagging.
http://example.org/tag/internet for links to items tagged internet.
http://example.org/tag/london for links to items tagged london.
But what should be the url for links to items that are tagged both internet *and* london? What about items tagged internet and *not* london?
I do not think these things fit naturally into a url without using parameters.
Dave:
Thanks for the comment. ABSOLUTELY, one size does not fit all. BTW, I will soon be blogging about the subject of URLs in-depth and ad nauseam at http://blog.welldesignedurls.org/ I plan to cover the issue you raise, and many, many others. I probably have a year’s worth of ~weekly blog posts planned, if not more…
Sign up for the blog’s RSS feed (not this blog, but the one referenced in the previous paragraph) if you are interested. And definitely participate in the comments because in most of my planned posts on the subject my goal is to gather input on very specific aspects of Url design to determine best practice as opposed to just lecture from my soap box!
Over time, I’ll post the Best Practices on the wiki here: http://wiki.welldesignedurls.org/Principles
"""I do not think these things fit naturally into a url without using parameters."""
They don’t fit very naturally into a URL using parameters either…
http://example.org/?tag=london&and=internet¬=hollywood
so, considering the URL as a virtual layer, why not one or more of:
http://example.org/tags/+london/+internet/-hollywood/
http://example.org/tags/+internet or london/-hollywood or florida/
http://example.org/tags/london and internet and not hollywood/
sfb:
Nice thoughts, I like where you are headed. However I wonder about the use of the plus (+) as I believe it is html-encoded in Urls to mean a space.
What about the following where the slashes denote "and" and the "-or-" is obviously "or?":
http://example.org/tags/internet-or-london/hollywood-or-florida/
I haven’t thought through this issue yet to see what it could negatively affect, but I think it has promise…
Hey, to all of you who complained about the URLs on my blog, have you noticed I’ve been able to fix *most* of them to be clean — but unfortunately, not the comments URL yet. :-( I’ll be posting a writeup (hopefully) soon.
Well designed URLs are Beautiful…
of course the reasion is because they are human readable and the second and very important is SEO optimization.
The best way is to use them with "-" split when you have several words.
Regards from
Dimi
http://www.bgpages.com
Dimi: Of course, I absolutely agree! :) Thanks for the comments.
You might want to do a search and replace to fix the spelling of "hierarchical" throughout your article. The spelling errors detract from your excellent arguments.
Ian: Thanks for the kind words and constructive criticism. Fixed.
BTW, can you tell that where I went to college we used to have a saying: "I are an en-ga-neer?" :-0
Hi there – well designed URLs give readers a chance.. they split long texts in mentally and psychologically accessible and remindable pieces of the cake… let me be a litte teasing: and not create an endless bandworm of words (however it´s maybe a rhetorical technique in free speech…reading it tires (a little ;-)
Nevertheless, you are right, in general.
Regards
Hans
For mod_rewrite rules on IIS, I strongly recommend IIS Mod-Rewrite:
http://www.micronovae.com/ModRewrite/ModRewrite.html
AFAIK, it’s the only tool that is fully compatible with Apache mod_rewrite.
Nice article !
I agree wholeheartedly. The first basic to internet success is an attractive website.
Indeed. That is the basic beginning of all e-commerce activity, though some would disagree with me (and have.)
I would be one of those to disagree. I think a handsome URL is great and helpful, but not necessary in the e-commerce community.
I agree well designed Url attracts people and they the best way to communite in bussy world where people dont care to see and look what is happening around.
ALex Bell.
There isnt any harm result at my site. In 10 days ago i saved my site to a toplist. Then my site has some bug. But when i saw this, i cleaned that toplist from my site. But now my site seems harmful site in google result.
But what should be the url for links to items that are tagged both internet *and* london? What about items tagged internet and *not* london?
Hmm why?
Travesti: Good questions
The first one is easy:
http://example.org/tags/internet/london/
However, my answer implies a hierarchy where there isn’t, but if you also enable the following then in fact you do have somewhat of a hierarchy via an implied query language:
http://example.org/tags/london/internet/
As for the second, possibly one of:
http://example.org/tags/internet/not-london/
Or better yet just simply (as sfb suggested):
http://example.org/tags/internet/-london/
http://example.org/tags/internet/-london/
Amusing anecdote of the day. Ages back, I saved this page as a bookmark, and today decided to visit it. Except the “.aspx” extension that had been saved with the bookmark no longer worked.
As a result, my “Well designed URLs are Beautiful!” bookmark led me to “My 404 page is better than yours”.
Charles: LOL! Thanks for the comment!
I just recently converted this site to WordPress and put lots of effort into getting all the URLs moved over to work and it was far from a trivial task. The URL you had was really old and I didn’t have any examples of it being called recently in my server logs so I hadn’t do anything in the .htaccess file to resolve it. I will soon; it would help me if you could post the old URL, just in case, so I could make sure it works.
I’ve already recently started researching plug-ins for WordPress that strive to improve the situation. BTW, here’s a post I wrote on another blog about the subject of booksmarks and changing URLs:
http://blog.welldesignedurls.org/2007/01/25/bitten-by-the-uri-opacity-axiom/
Lastly, as for the “My 404 page is better than yours” I think that came from either WordPress itself or the template I used. I didn’t write those words, and I’ll be changing them as soon as I can get to it.
As a result, my “Well designed URLs are Beautiful!” bookmark led me to “My 404 page is better than yours
In my new framework I made sure the urls are as clean as possible. Plus I never allow filetypes, which are ugly (ie .html .do .jsp) but only clean words. REST is definitely the way to go.
muhabbet: Way to go! BTW, I think filetypes in URLs *are* good when they mean something to the user (i.e. .jpg, .pdf, .doc, .xls, .zip, .xml, etc.)
Also, be careful with associating REST too closely with URL design. REST and URL design are related yet orthogonal concerns. A web site/service can be perfectly RESTful with extremely ugly URLs, but good URL design makes it easier to design a good RESTful architecture and also makes it easier for devs to use (assuming they ignore the hypermedia constraint, which most do and IMO provides significant disincentives to adoptions for publicly published APIs.)
In my new framework I made sure the urls are as clean as possible. Plus I never allow filetypes, which are ugly (ie .html .do .jsp) but only clean words. REST is definitely the way to go.
I would be one of those to disagree. I think a handsome URL is great and helpful, but not necessary in the e-commerce community.
Hate to be so blunt @siirleri, but you are just shortsighted on this issue.
I would be one of those to disagree. I think a handsome URL is great and helpful, but not necessary in the e-commerce community.
travesti
Hmm, the first URL in this article is 404’ing?
@Nevyn: Point taken! Fixed.
Ironically enough, several of the links here are now 404s, and one seems to go to a different article entirely in the blog being linked to. It seems even the people you cite as having good ideas in this area didn’t necessarily follow best practices in the subsequent development of their sites.
@Dan T.: Too true. Longevity is one of the most difficult aspects of URL design.
I’ve just been searching for some time for info about a well designed url; for a new system I’m creating (in Perl) which will be used to promote (aspirant) artists of any kind..
I’m still not completely done with some issues like spaces, since I’m wondering how to change the dreadfull %20 into something nice without loosing too much of the original title/artist/album name where spaces get used.
I could change spaces to dashes like “this-could-be-a-cool-title” but also to “this+could+be+a+good+title+too”; the expense would be with which character I want to loose to add spaces in a neat manner…
Hey @Wildchild, Definitely use dashes. Pluses are spaces encoded so if the URL is decoded and displaced somewhere it could “break.” Dashes, definitely.
Ironically enough, several of the links here are now 404s, and one seems to go to a different article entirely in the blog being linked to. It seems even the people you cite as having good ideas in this area didn’t necessarily follow best practices in the subsequent development of their sites.
@escort bayan: Yes it’s ironic, but it shows how hard longevity can be in URL design. It also shows how few software stacks place emphasis on URL design, though it is getting much better.
What is URL Design?
Hi @cam:
Thanks for asking. Simply put, URL Design is working to ensure that URLs are structured for human comprehension and consumption rather than URLs as a programmer’s convenience and afterthought.
Hope this helps.
-Mike
In my new framework I made sure the urls are as clean as possible. Plus I never allow filetypes, which are ugly (ie .html .do .jsp) but only clean words. REST is definitely the way to go.
Ironically enough, several of the links here are now 404s, and one seems to go to a different article entirely in the blog being linked to. It seems even the people you cite as having good ideas in this area didn’t necessarily follow best practices in the subsequent development of their sites.
@Firma Rehberi – Thanks for commenting.
Yes, it is very sad that people and companies do not respect the ideal immutability of the URL.
-Mike
P.S. I left your SEO link, which I normally wouldn’t, but you made an applicable comments so I did.
In my new framework I made sure the urls are as clean as possible. Plus I never allow filetypes, which are ugly (ie .html .do .jsp) but only clean words. REST is definitely the way to go.