How to get more literal URLs and still use IDs
Posted by David February 04, 2007 @ 09:26 PM
Obie walks through the technique for getting more search engine-friendly URLs and still retain the ease of use with auto-incrementing ids.
It’s the same technique we used on the new 37signals blog engine to get urls like http://www.37signals.com/svn/posts/247-calling-all-basecamp-customers-in-nyc-or-chicago.
The 247 is what Rails see and calling-all-basecamp-customers-in-nyc-or-chicago is what Google will focus on. Have your cake and eat it too!
I prefer URLs without the ‘247-’ id in them. I have a blog entry on how to achieve this with the permalink_fu plugin : http://www.seoonrails.com/even-better-looking-urls-with-permalink_fu
I have some more SEO posts on that blog too, including potential problems with Rails’s image_tag method.
I do too, but this is a much simpler method of achieving that. Plus, you can change the title, thus changing the permalink, without breaking the url.
Therefore, /257-adsf and /257-omg both work just fine. Probably not the best for SEO though…
rick: what you do is, when the slug doesn’t match the one in the db, you 301 to the existent one.
The main problem with leaving off the id [247] is that if the title of the article changes then the permalink A. changes with it and breaks the link or B. gets out of sync with the actual article title. If you use the method described above [though I’ve been using something more like /entry/247/this-is-the-permalink] then the title and permalink can change but since the id is still there everything will work. Also, having two articles with the same title is no problem with this method. Searching on the permalink requires that the permalink be unique.
I prefer the separate slug method. It’s more work, but you get better URLs. The 245-blah thing just looks cheesy, and using the full title leads to URLs that are just too long.
With a separate slug, you can have an unchanging permalink URL that’s not depenant on the title. The user can customize the slug so the URL is < 80 characters and packed with only the most relevant terms.
I think that doing /blog/i-am-a-no-id-permalink is just fine for simple applications. The kind where if someone gets a redirect, its no big deal. Or where it might be ok to mangle the name in honor of not conflicting with an element of the same name.
I am personally a big fan of the ”#{id}-#{safe_name}” method for to_params.
People are wayyyy too obsessed with pretty URLs. Nobody except elitist Internet snobs pay attention. Normal users don’t. However, normal users do notice when their link breaks because the name of the page changed.
“id-name” is a great trade-off in instances where the name is important and might be non-unique or changing.
For things where the name isn’t really that useful, don’t use it! Just use the ID.
I’d rather consistency and programmatic clarity over “users think they are pretty” any day.
Now, I say that with being clear that there are some instances (wikis, usernames, etc) where hackable URLs really do add value.
I guess in the end, just listen to the applications needs and don’t worship at any cult of “this is the way its done”. Except, generally, REST-style is a good middle ground when it doesn’t matter one way or the other.
-hampton.