O'Reilly

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!

Track.js Error Reporting

Upcoming Events

Recent Features

  • Convert XML to JSON with JavaScript

    If you follow me on Twitter, you know that I've been working on a super top secret mobile application using Appcelerator Titanium.  The experience has been great:  using JavaScript to create easy to write, easy to test, native mobile apps has been fun.  My...

  • CSS Animations Between Media Queries

    CSS animations are right up there with sliced bread. CSS animations are efficient because they can be hardware accelerated, they require no JavaScript overhead, and they are composed of very little CSS code. Quite often we add CSS transforms to elements via CSS during...

Incredible Demos

  • dwProgressBar v2:  Stepping and Events

    dwProgressBar was a huge hit when it debuted. For those of you who didn't catch my first post, dwProgressBar is a MooTools 1.2-based progress bar which allows for as much flexibility as possible. Every piece of dwProgressBar can be controlled by CSS...

  • CSS Columns

    One major gripe that we've always had about CSS is that creating layouts seems to be more difficult than it should be. We have, of course, adapted and mastered the techniques for creating layouts, but there's no shaking the feeling that there should be a...

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!

Recently on David Walsh Blog

  • OâReilly Velocity Conference â New York

    My favorite front-end conference has always been O'Reilly's Velocity Conference because the conference series has focused on one of the most undervalued parts of client side coding:  speed.  So often we're so excited that our JavaScript works that we forget that speed, efficiency, and performance are just as important. The next Velocity...

  • Free Download: Font Bundle Featuring 17 Incredible Typefaces

    The only thing we love more than a good font, is a good free font. So we’ve combed the Web for some of our favorite free fonts, and gathered them here in a single download. You’ll find a variety of useful typefaces, from highly geometric designs...

  • OâReilly Velocity Conference â Amsterdam

    My favorite front-end conference has always been O'Reilly's Velocity Conference because the conference series has focused on one of the most undervalued parts of client side coding:  speed.  So often we're so excited that our JavaScript works that we forget that speed, efficiency, and performance are just as important. The next Velocity...

  • CanIUse Command Line

    Every front-end developer should be well acquainted with CanIUse, the website that lets you view browser support for browser features.  When people criticize my blog posts for not detailing browser support for features within the post, I tell them to check CanIUse:  always up to date, unlike...

  • Generating Alternative Stylesheets for Browsers Without @media

    If your CSS code is built with a mobile-first approach, it probably contains all the rules that make up the "desktop" view inside @media statements. That's great, but browsers that don't support media queries (IE 8 and below) will simply ignore them, ending up getting the...