.net’s Guide to Digital Governance: URL Naming Conventions
.net’s Guide to Digital Governance
brandt
Mon, 11/14/2020 – 10:50
Scott DiPerna
Nov 14, 2020
This is the eighth installment of .net’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.
In this post we will cover…
A recommended naming convention for URL paths
Some tips for choosing section names
Questions to consider when defining rules for redirects and aliases
We want to make your project a success.
Let’s Chat.
A logical progression from Website organization is defining a naming convention for URL paths. URL paths should follow a consistent naming convention throughout all of your websites. Only under exceptional circumstances should a URL path name deviate from an established naming convention for a Website.
Best practices for URL path naming conventions recommend consistency in how sections, sub-sections, pages, and sub-pages are written. For most websites, I recommend URL paths follow the general naming convention below.
http://domain.com/SECTION/SUB-SECTION/PAGE/SUB-PAGE
This basic structure gives users an idea of where they are in the site’s hierarchy of pages. This can be especially important considering the volume of traffic that enters the site from web searches that will bypass the homepage and take visitors directly into deeper pages in the site. It’s also a good practice for improving the SEO value of your site’s pages, as it provides more specific context for the content of the page.
Section
Under this convention, SECTION is the top-level “directory,” and generally refers to the category under which subsequent content resides. For example, in the URL path http://domain.com/about, “About” is a primary category that often appears in a main menu, and thus receives a top-level URL path.
I generally like SECTION names to be one continuous string of letters without hyphens or underscores (e.g. about, services, people, etc.) because that makes for shorter top-level URL paths, however two word hyphens may also be acceptable if they aren’t too long. Given that top-level SECTION names are usually the label-names of your main navigation, it’s additionally wise to keep them clear, simple and concise.
Acronyms and abbreviations should be avoided because they often don’t make sense to visitors unfamiliar with the abbreviations. That being said, some abbreviations, such as http://domain.com/faq, may work so long as they make logical sense to most visitors.
If your Website has multiple users who are able to write URL path names, I recommended defining in the governance plan some limitation for who may write top-level directory names. These are typically the most highly sought-after URLs in a Website, and you will want to have a well-defined process for how those are distributed and assigned. A free-for-all is probably not a good process.
Sub-Section
SUB-SECTION is the second-level directory, if one exists. Using About as an example, “Meet Our Team” is the second-level “directory” in the URL path:
http://domain.com/about/team
since “Meet Our Team” is just one of the sub-sections under “About” in this example.
SUB-SECTION names also may be one continuous string of letters without hyphens or underscores, such as:
http://domain.com/about/team
or a string of words separated by hyphens:
http://domain.com/about/meet-our-team.
The choice between the two really depends on whether the additional words add value to the user’s understanding of location, and/or if the string of words adds SEO value because it captures important descriptive words for the content of the page.
In the example above, the words “meet our” really don’t add much information, and the shorter URL path name is simpler. Simplicity may become more important as you add pages to sub-sections and the URL path names become very long.
Some URL path names may appear to deviate from this rule if a sub-section does not actually exist, in which case the sub-section location would be occupied by the page name.
Page
Pages on the “Meet Our Team” site would then have a URL path structure of:
http://domain.com/about/team/PAGE-NAME
where PAGE-NAME could be any number of different page names. PAGE-NAMEs should generally describe the content of the page based on the page’s title. This can be expressed either as a single word (if a single word sufficiently describes the page), such as:
http://domain.com/about/team/consultants
where “consultants” is a page for information about consultants on the team titled “Consultants”; or by a string of hyphenated words, such as:
http://domain.com/about/team/website-consultants
where “website-consultants” is a page about Website consultants on the team titled “Web Consultants.”
For the purposes of SEO, at the page level, I generally prefer to include all of the keywords in a page’s title (separated by hyphens) in the URL path, especially when it adds descriptive value.
Sub-Page
As follows, sub-pages for any of the pages in the “Meet Our Team” site would have a URL path structure:
http://domain.com/about/team/PAGE-NAME/SUB-PAGE-NAME SUB-PAGE-NAMEs
should follow the same rules as PAGE-NAMEs, however sub-page names may require longer strings of hyphenated names as pages become more detailed and specific:
http://domain.com/about/team/consultants/WordPress-content-management-system
Conversely, if sub-pages are breaking out content into simpler categories, they may benefit from shorter names:
http://domain.com/about/services/web-platforms/WordPress
rather than:
http://domain.com/about/services/web-platforms/WordPress-content-management-system
All of that being said, you should determine the system that works best for your needs and stick to it. Just keep it simple, logical, and as memorable as possible so that it is easy for all users to implement.
Multiple-Word Names
When writing URL paths with multiple-word names, I recommend using hyphens, such as:
http://domain.com/about/services/web-platforms/WordPress-content-management-system
rather than underscores:
http://domain.com/about/services/web_platforms/WordPress_content_management_system
or concatenation:
http://domain.com/about/services/webplatforms/WordPresscontentmanagementsystem
Use of underscores makes it far too easy for a user to misread an underscore as a space, especially when the URL path is hyperlinked:
http://domain.com/about/services/web_platforms/WordPress_content_management_system
Most hyperlinks are underlined to indicate to users that a section of text is a hyperlink.
Concatenation is more obviously problematic because it simply creates confusing URL paths.
Aliases & Redirects
How URL path aliases and redirected URL paths are handled will depend on the policies of your organization and the platform you use for your Website. I highly recommend you define the rules and processes surrounding URL aliases and redirects in your governance plan, and here are some questions to consider along those lines.
How are URL aliases and redirects managed in your Web environment?
Who manages URL aliases and redirects?
Is there a process or procedure for requesting an alias or a redirect?
May anyone request a URL alias or redirect?
Are redirects to Websites outside of your domain or server environment permitted?
Who determines whether a URL alias or redirected URL path is appropriate or not?
Are there any special rules for using top-level directories as URL path aliases or redirected URL paths?
This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:
Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
Roles and Permissions – Define who should be able to do what in each system.
Content – Understand how ownership and permissions should apply to content.
Organization – Establish how the content in your digital properties should be organized and structured.
URL Naming Conventions – Define how URL patterns should be structured in your websites.
Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
Web-Based Applications – Consider use and ownership of web-based tools and applications.
E-Commerce – Determine the role of e-commerce in your website.
Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
Social Media – Set standards for the establishment and use of social media tools within the organization.
Digital Communications Governance – Keep the guidelines you create updated and relevant.
Stay connected with the latest news on web strategy, design, and development.
Sign up for our newsletter.
Strategy
Source: New feed