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.
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
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.
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.