I am currently designing a blog application and am having trouble deciding how to design the blog URLs.

Pages (pages like the about page etc):

  • http://site.com/about

Post URL can be:

  • http://site.com/2012/01/15/title-of-post
  • http://site.com/2012/01/title-of-post
  • http://site.com/12345/title-of-post where 12345 is a random guid.
  • http://site.com/title-of-post

I don't think the last option is very good due to possible conflicts and confusion if there are 2 posts with the exact title or very similiar titles. It will also conflict with pages where the same title is used.

I am currently considering the second or the third option. StackExchange uses the third option, which I quite like, because the guid is not as distracting as the date in the URL, however, I am not very keen on guids because they don't have any meaning to the user.


  • http://site.com/categories/user-experience
  • http://site.com/user-experience


  • http://site.com/tags/user-experience-conference-2012
  • http://site.com/user-experience-conference-2012

The problem I can see with the second approach is that if you have a tag or a category with the same name, you will run into problems.

Pagination: I found this question regarding pagination urls which is very useful. I quite like the recommended approach of using something like:

  • http://site.com/categories/user-experience/page/1
  • http://site.com/tags/user-experience-conference-2012/page/2
  • http://site.com/2012/01/page/2

I think this makes quite a lot of sense. If one were to browse archives, something like http://site.com/2012/01/2 could be mistaken for 2nd of January 2012

Now this is quite nice, but if some one attempts to access http://site.com/2012/01/ what should happen? Should I implement a 301 redirect to http://site.com/2012/01/page/1? What about http://site.com/2012/01/2, etc?

I have bolded the URLs that I am leaning towards at the moment. However, User Experience and SEO are the most important issues for me, so is there anything I should change?

  • The question on pagination URLs has good explanations about URL structure as it relates to UX. The details of your particular case aren't that unique as the approach is the same: make URLs readable & understandable to humans. The only thing to add is configuring 301 redirects or URL aliases or just good 404 pages for cases where people get too smart & experiment with your structure.
    – dnbrv
    Commented Jan 17, 2012 at 4:44
  • 2
    Those aren't guids, a guid should by definition be globally unique and is much longer than a simple auto increment field. en.wikipedia.org/wiki/Globally_unique_identifier Commented Jan 17, 2012 at 13:37

3 Answers 3


Go with a GUID on the URL, and add post title for SEO purpose only. This simplifies the task of locating post items.

URLs are primarily for computer consumption, not human, therefore if you need the put a link in an interactive screen (e.g. in a web page), make it clickable and give a human-readable link text, there is no need to show the URL to the user until the user hovers on the link. If you need to give a URL outside of an interactive screen (e.g. on print), use a URL shortener service and provide a "link text" that explains what the link points to.

So, what I'd recommend, in order:

  1. (on screen) visit my question about Designing blog URLs
  2. (on print) visit Stack Overflow at http://s.tk/
  3. (alternate on print) visit my question about Designing blog URLs at https://ux.stackexchange.com/q/16204/

As Naoise said, don't put post date in the URL. The fact that two posts is made in January 2012 is a product of accident, it does not reflect the structure of your site.

  • +1 for Go with the postId on the URL, and add post title for SEO purpose only. -1 for url shortener service Commented Jan 17, 2012 at 13:43

If you analyse the variables that you are considering to include in the URI individually, you can prioritize them, taking into account how much value they give to the user:

  • post ID: zero value to the user, it is only intended for not creating duplicate URLs (same titled posts)
  • post date: posts are timeless, they can be accessed years after they have been written and still be useful. So, while having the publishing date is important, is not as crucial to have it in the URI.
  • tags: tags are a good keyword for the URI (SEO) but one post will have many tags, and you will need to choose only one. Is there always one tag more important than the other? Otherwise you would have duplicate URIs for every tag (bad for SEO).
  • category: categories are like tags, but you will normally use only one category per post. Good as a keyword for SEO and for the user to give the post some context from reading the URI.
  • post title: undoubtedly this is the most important, both from a SEO and a UX stand point.

I've ordered them from least important to most, following my reasoning, I would recommend


  • 1
    Entering long titles is annoying. When copy pasting it can happen that the source inserts a line break somewhere in the title, breaking the url. A title can change over time, so you need to keep a history of titles so urls don't become invalid making coding more annoying. So I dislike websites where the title in the url actually matters. Commented Jan 17, 2012 at 13:42

The easiest way to do this, in which it will help you in the long run when you are looking for posts ;), is the following format:


This allows you to keep track of all of your posts, and the url will make perfect sense to the user. For example, if the user typed in http://site.com/2012/01, he would be taken to a monthly archive. If he typed in http://site.com/2012/, he would be taken to a yearly archive.

This, of course, is just a recommendation.

  • I don't like making the title a part of the url that actually matters. It's long and it's mutable. Commented Jan 17, 2012 at 13:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.