Principles: All web pages

The following principles apply to the naming of all web pages and particularly to static pages.

Principle 1: Brevity

A URL should only be as long as is necessary but abbreviation should only be used when it will not compromise meaning. In other words: Only use commonly understood abbreviations (see Principle 10: Abbreviations).
Take into account the fact that email may be used to send URLs. Eighty (80) characters is a reasonable total length for URLs (including URI scheme, e.g. 'http://', and host name) given that some email clients wrap at 70-80 characters.
URLs should be readable, meaningful, and may retain the website's hierarchy.
If it is not possible to create a short URL while retaining meaning and/or hierarchy, consider the creation of alternate URLs for print or advertising (see the Aliasing a resource section of the HTTP status message guidelines).

Readable URLs can provide users with extra information about the website's structure and content allowing the user to gain some understanding of the website.
URLs are not viewed solely online. Users find links in printed documents, add links to printed documents and pass URLs around by word of mouth.
Consider:
- ease of typing
- ease of remembering meaning (or lack of it; in different languages).
Well-chosen and informative directory names help users orient themselves within a site and navigate.
File names should inform the user of what is in the file and URLs should have some meaning to the user.
It is much easier for the user to have to type and read simple words rather than a collection of random characters. Favour descriptive words, and avoid serial numbers such as 'd1827.html'.
Avoid exposing system identifiers in URLs. For example using a specific term, such as '/licensing/' is more meaningful to a user than '/tabid23/'.
Use dated URLs such as 'http://www.dept.qld.gov.au/2003/10/meeting-minutes' for date-specific standalone documents.

Users should be able to truncate the URL and still achieve some success. A user who gets to nearly-the-right page should be able to clip the end from the URL to the next slash '/' and try again.
A website that has a web page for the URL 'www.dept.qld.gov.au/houses/building/applications/' should also have a web page for 'www.dept.qld.gov.au/houses/building/' and for 'www.dept.qld.gov.au/houses/'
For file-system based websites, ensure each directory's default 'index' page exists, and allows users to easily navigate to every page in that directory.

A URL should not show the underlying technology used to serve the resource.
- Avoid file-extensions like asp, jsp, php, aspx, etc. as they indicate the technology used to generate the content.
- Extensions like html, doc, pdf, etc. are fine because they specify the format of the content itself.
Directory names and file extensions commonly associated with a given server-side technology unnecessarily disclose implementation detail and discourage permanent URLs. More generic paths should be used.
Use content-negotiation, proxying or URI mapping to hide technology-specific extensions in both dynamic and static content. For example you could map a URL with '.html' extension to an '.aspx' application file.

Standard HTTP redirects must be used to point to new locations for temporary redirects, permanent redirects, and when removing a page.
If a page requires removal, it should be done in a way that informs clients that it has been removed intentionally.
See the HTTP status message guidelines for how to manage moved and removed resources.

URLs should be easily stored either as a bookmark, included in an email, added to another site as a hyperlink or indexed by a search engine.
Stored URLs should allow users to return to view the same content at a later date.
Every useful page (every resource) should have a unique URL which must display in the address bar. This means the POST method should not be used to display results; instead users should be redirected after a POST submission to ' unique URL that contains the results.

URLs should be consistent.
Keep the design or directory structure of URLs consistent and rational site-wide. A user who has seen some of a site's URLs, should not be surprised by other URLs in the site.
Keep information in consistent areas. Similar files should have similar URLs (see structure).
URLs should be predictable. If users find a file called '1999-q1.html', they are likely to guess that a more recent report might be called '2000-q1.html'.

As URLs can be case sensitive, their case should be consistent. It is recommended that a case policy be chosen and enforced.
A policy using 'all lowercase' is preferable and the simplest to implement.
The use of URLs in mixed case should be avoided wherever possible. Consider the use of hyphens in URLs containing unavoidably long strings of joined words. For example www.queensland-govt.gov.au is more readable than www.queenslandgovt.gov.au.

Avoid the use of any punctuation in the file name.
Underscores should not be used, as these may be obscured or difficult to read when the URL is underlined (URLs are often presented underlined on the web and in print). The use of a hyphen is preferred.
The use of a hyphen will optimise the file name for indexing as each word in the file name will be indexed separately. Words joined with an underscore are often treated as a single, usually unintelligible word.
There should be no spaces used in the URL. Consider the use of hyphens to separate words.
Avoid the use of any special, non-alphabetic or non-numeric characters in file or directory names.
URL structure can be used to indicate relationships between resources. The slash '/' indicates hierarchy and grouping of resources. Matrix URIs may be considered to indicate other relationships.

Use abbreviations consistently – consider whether all words are expanded or all words abbreviated.
If using abbreviations, ensure there is no ambiguity about the expansion. Use only abbreviations commonly understood by your target audiences.
Use acronyms sparingly as advised in Module 8 - Web writing guide of the Consistent User Experience Standard.
Consider creating extra URLs that redirect from the non-preferred form to the preferred form. For example you may redirect from '/rego/' to '/registration/'.