Is it better to have post ID in post URL?

Hi,

I am building a new site (PHP & MySQL) and I can’t decide on whether to include the post ID in the URL or not. There are some sites that do this and some other sites that don’t. For example, my URL structure for posts will be like the following with post ID:

http://www.mysite.com/post-id/category-name/post-name/

Ex:
http://www.mysite.com/283/web-design/web-design-trends-in-2013/

or without post ID

http://www.mysite.com/category-name/post-name/

Ex:
http://www.mysite.com/web-design/web-design-trends-in-2013/

If I add post ID, I will get the post details from the database using the post ID which is the primary key. On the other hand, if I don’t use post ID, I will get the post details from the database using the post name. I don’t know which one would be faster and better for scalability. Maybe there is another better option that I can’t think right now.

Thanks for any ideas.

As long as the post name has a unique index, then your two options are virtually the same. Given that, a lot of people choose the post name option because it makes for a more human friendly URL.

I think it would be better from a SEO point of view to have the title of your post hyphenated.

Take a look at the uri for this thread.

It will mean a bit more work to ensure no duplicates but well worth the effort.

I guess I didn’t express myself clearly. I was just comparing

http://www.mysite.com/283/web-design/web-design-trends-in-2013/

with

http://www.mysite.com/web-design/web-design-trends-in-2013/

The first option has a post ID unlike the second option.

What do you mean by “unique index”? I am not so knowledgeable with databases. Does that mean I will add a “Unique” index to “post name” column in the database and it will work as faster as getting post details from post ID?

Yup.

Thank you, I never really knew it worked like this. So, I will not use post ID in the URL.

I always like to have URLs that are as short as possible – which may exist in parallel with longer and more meaningful URLs. That’s particularly important in the world of Twitter as well as offline promotion. We often send out newsletters that have web addresses on, and it’s so much better to be able to give a URL of
website.com/page/4628
than
website.com/section/subsection/documents/long-article-title-with-lots-of-hyphenated-words
Guess which one people find easier to retype! And the chances are that it will appear intact in tweets and will be unbroken when repeated elsewhere (eg on here, long URLs appear with the middle chopped out). You may well want to keep the full wordy URL for most situations, but it’s great if you can prominently promote the short form of the URL to encourage people to use it when linking to your page or referencing it.

In most of the cases the parts after the ID are ignored by the app – it is just window dressing for SEO.

We typically build a UrlName property into anything that is going to be it’s own URL on the public side, said name is well indexed and garunteed to be unique within it’s domain. We avoid exposing identifiers directly – it enables one to change out content completely and not have a trail of broken links behind you.

Mind you we don’t do blog type stuff generally so that model could be different.

  • Notice the value after ?974393-

I find numerical surrogate values such as; primary keys much easier to deal with. You don’t have to worry about URL encoding or some moron copying and pasting a word document into a title. If some type of SEO garbage must be included than I much prefer the way sitepoint does it. Where everything following the primary key is just throw away meta data. Not to mention the state of the entity can change without affecting the URL. However, if you use a title than when the title changes there would need to be some type of exception to route the old URL to the new one and that can become very messy. Otherwise, users who bookmark said URL would be greeted with a nice 404.

Nayen,

Have a look at http://wilderness-wally.com and the table of contents (links) on the left. These are ALL the articles Wally has posted USING UNIQUE ARTICLE NAMES. Not an id in sight and, IMHO, that is a beautiful thing. Just be careful which characters you allow in the titles as URIs can throw a fit is you insert characters which are reserved (http://www.ietf.org/rfc/rfc2396.txt - it’s “geeky” but a very valuable resource), etc.

Regards,

DK

Thank you very much Stevie, I never thought of something like that. I think considering the scope of my website this will be something I may need.

Could you please clarify what you meant above? “exposing identifiers” meaning displaying the post ID?

Thanks for your opinions. I really have mixed feelings now because what you are saying also makes sense. In my case, URLs will most likely change in time because I will be updating content on each page from time to time and possibly changing their titles slightly.

I will have only [a-z0-9-] in my URLs.

Well, I asked this question here to come to a decision but the replies I got tells that both options are equally nice. I will think on this a bit more.

There is one problem with this approach actually but not sure how important it is. When you use only the post ID for validating GET value, then the post name can be changed by the user as they wish and the link will still work.

For example, the following all redirects to the same page:

http://www.sitepoint.com/forums/showthread.php?974393-sitepoint-dont-think-so
http://www.sitepoint.com/forums/showthread.php?974393-sitepoint-thinks-so
http://www.sitepoint.com/forums/showthread.php?974393-welcome-to-my-website
http://www.sitepoint.com/forums/showthread.php?974393-trololo

And the URL in the address bar is even not redirected.

I thought about also validating the post name as well as the post ID but then it makes this approach useless for future title/post-name changes and keep the SEO benefits.