Tips For Better Page URLs

By  on  

Page URLs are probably more important than most people realize. No one wants to deal with marathon URLs and meaningless querystrings. Here area few tips for keeping your URLs respectable.

Lose the "WWW"

The four most useless URL characters are always "www.". If you want to take the easiest step to making your URLs shorter, lose the WWW. Of course, you need to configure your server so that it sees "WWW" and non-WWW the same way. Too often I see "www." in print ads -- what a waste of space!

Lose the File Extension

With .htaccess files and mod_rewrite, file extensions in URLs are a thing of the past. Why make users remember page.php if they can just remember "page?"

Use SEF Links

If you want or expect a lot of people linking to your page(s), do them the favor of generating search engine friendly links. No one remembers "davidwalsh.name/post.php?id=3249". People can, howevever, remember "davidwalsh.name/learn-about-urls".

Don't Bury Files in Many Directories

Well, you probably can but at least use mod_rewrite to create "shortcut" URLs. No one likes "blah blah SLASH blah blash SLASH." Slash is for Guns and Roses, not useful web links.

Don't Use Trendy, "Clever" Web 2.0 Domains

Domains like "script.aculo.us" and "del.icio.us" were memorable at first, but now they're just annoying and difficult to remember. Don't make your users guess where the dot goes!

Have any suggestions? Please share them!

Recent Features

  • By
    LightFace:  Facebook Lightbox for MooTools

    One of the web components I've always loved has been Facebook's modal dialog.  This "lightbox" isn't like others:  no dark overlay, no obnoxious animating to size, and it doesn't try to do "too much."  With Facebook's dialog in mind, I've created LightFace:  a Facebook lightbox...

  • By
    Send Text Messages with PHP

    Kids these days, I tell ya.  All they care about is the technology.  The video games.  The bottled water.  Oh, and the texting, always the texting.  Back in my day, all we had was...OK, I had all of these things too.  But I still don't get...

Incredible Demos

  • By
    HTML5 Context Menus

    One of the hidden gems within the HTML5 spec is context menus. The HTML5 context menu spec allows developers to create custom context menus for given blocks within simple menu and menuitem elements. The menu information lives right within the page so...

  • By
    Implement the Google AJAX Search API

    Let's be honest...WordPress' search functionality isn't great. Let's be more honest...no search functionality is better than Google's. Luckily for us, Google provides an awesome method by which we can use their search for our own site: the Google AJAX Search API.

Discussion

  1. Ahmed

    I use all these except for the Lose the “WWW” tip. And my reason is very simple, but it works for me. I develop locally forwarding domain.name to 127.0.0.1 and force www on the actual thing, and to switch I just need to edit one line in the database or in my actual_url.php – but honestly, your tips are great!

    Thanks Dave,

  2. Rich

    I started messing around with SEF URLs when i first read your article
    generate search engine friendly URLs and still use the same function now. I know you probably get many thanks from developers, but your examples and posts help the whole community so thanks.

    I have recently started a project where there is no precise direction for the blog they want created, so i am trying to figure out some sort of URL structure for them.

    what would you recommend if any:

    .com/year/month/article-title.html
    or
    .com/state/city/article-title.html

    my concern with both is that there could be dup titles. how would you account for that?

    I really dont want to add a number like article-title-2.html

  3. Well it is a matter of preference to keep the www or not. However you should make absolutely sure to have a 301 redirect to the other url to avoid duplicate content penalties. Having a dns change the url for you is not good enough. You will need a 301.

    Duplicate Content www vs. non-www Canonical Problems

    Having the www in the url is also the standard for top level domains. The user doesn’t have to type www to properly get to your url if you have the proper 301. The only time I would leave it off is in print advertising as you mentioned.

    Also for people reading tip number 2, don’t go out and start changing your urls. You WILL lose pagerank. Although the loss can be limited with 301s, it isn’t worth it. If you are starting a new project then by all means use “pretty urls”.

  4. Yeah but also remember some people are just totally confused about the url. I don’t know how many people I’ve seen at work throw the www in before a subdomain just because they think they need it. I would stick to convention and leave it in. Those in the know, know not to put the WWW but it look familiar to those who have no idea.

  5. Jeff Hartman

    Why make users remember “page.php” if they can just remember “page?”

    Assuming the URL is fairly simple, they’ll remember whatever they find worthwhile – extension or not.

    I think a bigger benefit to no extension is for the developer and site maintenance (switching to a different language, etc.)

    People can, howevever, remember “davidwalsh.name/learn-about-urls”

    They can, but will they? Only if they visit that particular page often**… which I’m guessing excludes 99.99% pages on the internet. For everything else your friendly URLs are for search engines and your own organizational benefit.

    ** or if your brand is very strong (e.g. http://www.apple.com/itunes)

  6. I guess that users won’t remember almost any long URL. It would be great if they remember a domain name. It’s always copy&paste from bookmarks or whatever.

    That doesn’t means that these things are not true, I definitively agree!

  7. Haha…love the line:

    “Slash is for Guns and Roses, not useful web links.”

  8. Bookmarks???? (or Favorites for the Internal Error (IE) users) Might help?

  9. geekasylum

    Another thing to consider when thinking about “losing the WWW” which hasnt been mentioned here is cookies. If your page has a lot of external resources, say it has images, and javascript, and json, and ajax, and css, and favicons, and so on, each request will be accompanied by all of the cookies you set on the domain, even though, its only ever the page itself that uses them.

    If your web site is example.com, and you set your cookies there, you’re pretty much out of luck, because those cookies will also be sent to subdomains, so images.example.com and static.example.com will get all the cookies you set on the example.com domain which you send your users to.

    Sending your users to http://www.example.com, and setting the cookies there, (on a subdomain) allows you to use other subdomains where the cookies dont bubble up. Cookies set on http://www.example.com, wont be sent to images.example.com, so you can serve your images, or other static content from there without the browser sending a mass of useless cookies that wont be used, along with the request.

    This helps speed up your pages and gets rid of unnecessary bloat in the request. But cookies are tiny, you say.. well, I just looked at a page that makes around 60 requests in total to build the page in the browser. If the cookies are, lets say 2k, thats 120k that the browser really didnt need to send – do that over 10 pages, and its over a Mb.

    If you dont use a subdomain in your site url, like www, the only alternative is to register a whole new domain to serve your static content from, where your dont set any cookies. Yahoo uses yimg.com, Youtube uses ytimg.com, and most other large sites have them – thats the proper way to lose the www.

    I too for a long time fought to banish the www from web pages, and still agree with the redirects (though I prefer server aliases and other trickery) so that you can drop www from the print ads, but there is good reason to include it in the URL, unless you can afford registering two domains for each web site, or dont care about bloat and slower response.

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!