I’m writing up a CMS for myself and I’ve been thinking about this for a while and can’t come to a good conclusion. I’d like the URLs to be functional, but also not include needless information.

The old standard for a blog is /YYYY/MM/DD/TITLE. That has some nice qualities to it. It lets people know when something was posted as well as lets people chop off the end and get to date-based indices (if you do it right).

But, the counter-argument goes, what if the date changes? Well, you have to setup a redirect. Now, I already have my CMS looking for URL-changing events and auto-creating redirects for them (yay!) so that’s no _big_ deal, but I would like to not change URLs as much as I can. The proponents of this say that the best URL is EXAMPLE.COM/TITLE-AS-A-SLUG.

Honestly, I see the point, but I think that’s over-simplifying the problem because in a blog half of the data is when it was posted. If I post tips about an OS and the date is 2007, you’ll think twice before following them. If I post about how to fix a car, then it won’t matter. But the point is that the decision goes to the user instead of making people question it and go looking for a date, or worse, not know at all.

I also thought about /SECTION/TITLE and /SECTION/YYYY/MM/DD/TITLE so that one could do multi-blogs like “news” and “blog” and so on, but then second-guessed myself with “what if I want a root-level entry?” Well, then the answer is to have Pages and Entries, right? But, what about people who want date-based URLs rooted at /… ?

Overthinking? What do you think is the best future-proof way of doing this?