Common URL Structure

For all website designers and administrators, especially those with multiple sites, a common URL structure is the key to sanity. Of course this also works for those who only have one website. After all, best practices for busy site designers are best practices for those with a single site, as well.

Common URL Structure

Basic Rules for a Common URL Structure

The basic rules are simplicity, memorability, interpretability, and consistency.

For example, with Contact pages, should they be labeled /contact or /contact-us? Here, /contact is the simpler choice. The page title can of course be different. We are dealing with underlying URLs here, not the other layers.

Form Submission Pages

For Form submissions, the recommendation is to use nouns and verbs, in a hierarchical structure, as in:

/contact

/contact/submitted

and

/payment

/payment/submitted

/payment/cancelled

include various nouns as applicable (especially for tracking purposes by url, such as contact, registration, payment, subscription, newsletters, etc.)

Boilerplate Document URLs

All websites need Terms of Use and Copyright information, but this call all be lumped into a single /policies page. These are the website policies, rather than the organization or product/service policies. Those policies are better named Terms and Conditions and can be easily inserted at the url /terms. Frequently Asked Questions should be placed at either /faq or /faqs, but since /faq is simpler, that is the better choice (again, the page can have its own unique title, this is merely the URL structure.

General Rules for Content Pages

The basic rules are to try and be brief, yet memorable, descriptive, yet keyword-focused. This is not always simple, and there can be many possible URLs for any given page. Use redirections when changing already established URLs, or when the 404 logs show people searching for or linking to non-existent pages.

Non-HTML Elements

Various other elements (images, video, audio and other media, pdfs and other document types) should also have a nice common URL structure or framework, but this is much more difficult to deal with (as it is usually treated at the level of the content management system). Nevertheless, some kind of structure such as:

/site-images/image-short-description.png

The reason to include /site- in /site-images is for portability and memorability within a large document tree, and for multisite/single structure websites. Therefore there could easily be:

/site-images

/site-video

/site-audio

/site-pdfs

Note that site is a particular site name, not literally site.

Trailing Slashes or Not

The issue of trailing slashes is one where (according to Google) there needs to be a choice made, and to stick with that choice. 301 redirects should be at the opposite of the choice to redirect to the correct destination. Unfortunately with Docpad, at least at the moment the redirect trailing slash is not supported (or at least available on the Docpad site).

Browser behavior, at least for root domains, is to remove the trailing slash. Also RESTful APIs (at least many, and the specs) do not support trailing slashes.

So, do away with trailing slashes and ensure 301 redirects to the non-trailing-slashed version of the site/page.