We use URLs everyday. Although most are not usually seen by humans, some are remembered and typed into a browser’s address bar. So I believe that webmasters should make them easy to remember (if they want people to visit their sites). But the situation is not so simple, partly due to badly configured software and partly due to humans accustomed to unfriendly URLs.
Formally, a URL consists of many parts. But in most cases a URL is not more complicated than http://example.com/foo/bar?baz=qux which has a scheme (http), host name (example.com), path (/foo/bar) and query string (baz=qux). So what’s usually wrong with these?
Web browsers usually use http if the user does not specify a schema. So many people will not notice that for secure connections the schema https is used. Since they type the URL for HTTP, secure websites put there redirects to HTTPS. Clearly since HTTP is insecure (another server may send other data), redirecting from it to HTTPS is also insecure. With newer browsers hiding the protocol used, this makes the Web less secure.
The host name also may lead to securing problems when users mistype domain names, but these are less interesting problems. In WWW many host names are prefixed with www. It clearly does not contribute any information – compare http://www.plone.org/ with http://plone.org/. The second one is shorter and contains less technical information. So it is easier to type and more friendly to people. This may be a reason why the longer URL is a redirect to the website of the Plone content management system.
The path may be an easy to read text in a hierarchy. But dynamic websites made with e.g. CGI or PHP by default include many technical data in the path and use the query string to specify which page is used. Fortunately, search engines rank websites with readable URLs higher, so this may become a lesser problem in the future.
My advice here is simple – write whole URLs, do not prefer leading www and use words instead of implementation-specific details or query strings in the rest.
