As Search Engine Optimization (SEO) becomes more and more important, web professionals are looking at ways to increase their Google juice, the much sought after increase in page rank that is achieved through a variety of means most of which are very simple to implement. One such optimization, which many web developers have overlooked, is the importance of the format of the URL.
And one of the standards which strives to make excellent use of the conceptual meaning behind the URL is referred to as Representation State Transfer, or REST for short. Basically with REST, which has morphed in meaning over the years, has grown to mean among web professionals the attempt to address resources on the web and deal with them as nouns rather than verbs. Verbs are actions that can be performed on the nouns, and the two should be distinct. It turns out that the World Wide Web provides a great foundation for this if only people would write their URLs in a RESTful format. Most of what we do on the web makes use of the HTTP GET command, so many are not aware that there are actually other commands such as PUT, DELETE and POST. Well, we use POST a lot too, come to think of it. That's what we use behind the scenes when we fill out online forms or when we upload a picture.
So, what would a RESTful URL look like and what what a non-RESTful URL look like? Great question.
Non-RESTful URL:
http://www.yourdomain.com/onlinestore/default.aspx?category=new_rel&get_mem_price=true&...
RESTful URL:
http://www.yourdomain.com/online-store/members/products/new-releases
The main idea behind REST is the focus on using URLs to identify resources, or nouns, basically things that we might want to see or perform some action on.
Do you buy this?
No, not really. In an ideal world, yes, but I'll still be using the QueryString in development, especially in situations where there is an integration between two parts of a system. Yes, you could use cookies, but then your users can't just copy and paste URLs into an email that they send to their colleagues. When I've worked with online stores for customers, this is always a concern.
So, no, my URLs won't please the REST purists.
But, I do want my URLs to help my clients drink deep of some fine fresh squeezed Google juice, so I will be paying attention to ways I can make my URLs more attractive to search engines and it turns out the RESTful URLs tend to lend themselves well to SEO. So much so, that I would recommend adding this to the list of considerations when looking into a Content Management System (CMS) for your organization. If your proposed CMS has stuff like this (WizardKey=f5da82f6-2140-4dea-8d9d-be112b16c3fd&WizardStep=93d4ee5a-70eb-4570-ae5d-fdbc6e3f43c2) in the QueryString, I would hazard a guess that this is not very meaningful information for search engines.
This was one of the things I liked about DotNetNuke (An ASP.NET-based, open source CMS) the first time I investigated it for use with a client about 3 years ago. The DNN architects were early in realizing that QueryStrings were not helpful when trying to increase page rank. However, one of the drawbacks to DotNetNuke (it's actaully a drawback to ASP.NET running on IIS 6 or lower and I've heard it's fixed in IIS 7) is that you can't have a URL without a file and a known file extension such as .aspx. This means that the closest thing I can get to a RESTful URL is something like this: http;//www.mydomain.com/products/chrome-bumpers.aspx. That's closer, but still not quite to the completely RESTful form of http;//www.mydomain.com/products/chrome-bumpers.
DotNetNuke Resources for SEO and Human Friend URLs
I stumbled upon this resource from Scott McCulluch last night. I haven't used it yet, but it looks really helpful.
Also, here's a video I created showing an attempt I made to implement a RESTful URL in DNN using an ISAPI filter and some changes to the core.
OK, so I've started this conversation. What do you think? What technologies are you using to keep the Google juices flowing?
PS This is my first post to the blog using our new metaPost DotNetNuke module. More on that to come.
