What makes a “friendly URL”?

Question

I\'ve read a great deal of discussion recently (both on this site and elsewhere) about \"friendly URLs\" but I\'m not sure what exactly makes a URL \"friendly\" and why we r

Answer 1

I happen to agree with you, but shhh don't tell anyone.

It's just my humble opinion, but it seems silly to me that

http://stackoverflow.com/questions/522466/

and

http://stackoverflow.com/questions/522466/what-makes-a-friendly-url

are the same page. I mean, I can see that the hyphenated question title gives the URL some context, but it unless you know that part's optional the URL just gets longer unnecessarily.

Answer 2

The 2nd URL looks more user friendly, whereas the first looks search-engine friendly.

Search engines give a higher relevance to words that appear in the URL. The domain name gets the highest (because it can't change), the rest of the URL gets a high priority because the length is limited, and then the body of the document is analysed.

My answer is quite subjective, because it depends on whether you are being human friendly (easy to type manually, or read to a friend) or whether you are being search engine friendly (boosting your ranking.)

Answer 3

Tim Berners-Lee (the architect of the WWW) wrote a great article about this subject about 10 years ago.

• Your example is a bad URL -- but not just because it has both an id and a "slug" (the abbreviated, hyphenated form of the page title). Putting the page title into your URL is problematic in the long term. Content will change over time. If you ever change the title of that blog post, you'll be forced to choose between keeping the old URL, or changing the URL to match the new title. Changing the URL will break any previous links to that page; and not changing it means you'll have a URL that doesn't match the page. Neither is good for the user. Better to just go with www.myblog.com/posts/123.

• Users often do need to type a URL, but more importantly, sometimes they'll also edit existing URLs to find other pages in your site. Thus, it's often good to have discoverable URLs. For example, if I want to see post #124, I could easily look at the current URL and figure that the URL for the page I want to see is www.myblog.com/posts/124. That's a level of user-friendliness that can be a big help to people trying to find what they're looking for. Including other information (like the subject of the post) can make this impossible -- so it reduces my exploration options.

• Forget about SEO. Search engine technology has been reducing the effectiveness of SEO hacks for some time. Good content is still king -- and in the long run, you won't be able to game the system.

Answer 4

In my opinion, IDs and UUIDs should never be part of the URL, never.

1) Some NoSQL databases don't use IDs at all, they use UUIDs. UUIDs are long, portions are separated using dashes. Google will treat a dash like a words separator: that means your url will have 5 more useless keywords.

2) A human being does not understand IDs or UUIDs. A person understands words and talking URLs.

3) If the title changes you can simply make a redirect like WordPress does, like @TRiG pointed.

4) Finally, remember to use a date, so you can discern between two articles having the same title and posted in a different year, month or day. For example you can have two reviews (first edition and second edition) of the same book.

http://example.com/2013/02/11/data-mining-concepts-and-techniques

and

http://example.com/2011/05/23/data-mining-concepts-and-techniques

5) A date will also help any user to figure out if the content is recent or is not.

6) A date will add an important keyword to your URL: the year. Let's suppose I want see the most beautiful girls in the world, I will type in Google: "most beautiful girls in the world 2014". My url will be:

http://example.com/2014/07/10/the-most-beatiful-girls-in-the-world

7) Last but not least, Chrome caches the site you visited, so you can find the above site just typing in the address bar "girls".

Answer 5

As for:

Wouldn't this be a violation of the "don't repeat yourself" mantra?

That refers to the application CODE!!, not the application it self!!

It makes complete sense to have

• Title in the <title> tag
• In the URL
• And as first line in the content.

And pretty much everywhere else the content need it.

What that "mantra" refers if the your code should look like this:

  <title><%=obj.getTitle()%></title>
  Reading:<h1><%=obj.getTitle()%></h1>
  Link to this:<a href="getHrefFor( object.getTitle() )">obj.getTitle()</a>
  Etc. etc.

Instead of having different methods with copy/pasted code all around your app.

Answer 6

Ahh...the trick is who the URL is friendly to. Search engines perceive the first url as more friendly because it apparently has content information in the URL and it doesn't look like the same page being repeated with a different parameter.

For instance, comparing

www.aTvShowSite.com/show.aspx?id=123
www.aTvShowSite.com/show.aspx?id=124

a robot will say okay, I don't know what these are...but they look like the same page to me.

Whereas comparing

www.aTvShowSite.com/shows/AmericanIdol
www.aTvShowSite.com/shows/Lost

makes them look like different pages (even though it may be the same aspx page serving them up), and robots tend to rank them higher.

EDIT: Additionally, it should be noted that many robots look at the text of the url to determine usefulness, so a search for "Lost" will likely hit the second type of url more than the first, even if the page content is identical.