Selecting Canonical & Preferred Domains
What is a canonical, or preferred, domain? Why does this affect SEO and how can it affect user experience? Why should we care? Let’s dig into each question, and more.
What is a Canonical or Preferred Domain?
In organic search marketing / SEO, the term “canonical” typically is used to refer to a canonical version of a particular URL. Briefly defined, a canonical URL is the official version of the URL. This becomes important to define when there is more than one URL you can use to surface a particular set of content. For instance, let’s say a page of your website can be reached at either mysite.com/somepage or mysite.com/somepage.php and that both of these URLs return exactly the same content. In this example, you risk creating duplicate content. Duplicate content can be confusing to users and also confusing to search engine robots.
A canonical domain, then, is this same concept but at the domain-level instead of a page-level. There are many different ways to access a domain. For example, here are four ways to access my site:
Like with duplicate content, duplicate domains can cause confusion. In some cases, the lack of HTTPS in the URL can cause concern for users since HTTPS indicates a level of security. But the bigger issue is with search engine robots. Search engine robots will index one version of your domain. What’s more, a search engine robot can often see a domain without www as something different than a domain with www (though, to an extent, this only becomes an issue in extreme conditions).
Select a Canonical Domain
To avoid confusion, and any of the problems that can arise from duplicated domains, the best solution is to choose a canonical version of your domain. In looking at the four examples of my website above, there are really two questions you need to answer:
1. Should my domain include a www or not?
2. Should my domain be secured via an SSL certificate (HTTPS) or not (HTTP)?
The answer to the first question is rather open ended. Some tests we’ve run at Elementive show that less-tech savvy user groups respond better when using “www” in the URL—having “www” makes the website’s URL look more like a website’s URL should. Among other benefits, this can translate into more people clicking on the search result. Of course, a more tech-savvy audience can prefer the opposite and find the lack of “www” in the URL appealing. In other cases, using the “www” or not says something about the brand itself. In deciding whether to include the “www”, think about what it says about your organization and how your users will respond.
As for the second question about securing the domain via an SSL, in the past, the general rule of thumb was ecommerce sites or sites that collected personal information from users should use HTTPS but anybody that had a content-oriented site (like, say, matthewedgar.net) was largely okay using HTTP (without an SSL). That all changed over the last few years as Google made HTTPS a ranking signal and as Google Chrome began indicating HTTP sites weren’t secure. All the sudden, thanks to Google, the answer to the second question is: choose HTTPS unless you don’t care about organic search traffic or people using Chrome. In other words, everybody should choose HTTPS.
To simplify this, it is easier to picture these options as a grid. There are, essentially, four options you have for a canonical domain, in my case those are:
In the case of MatthewEdgar.net, I’ve chosen the canonical domain of https://www.matthewedgar.net/, with HTTPS and with www. Now that I’ve chosen that, how do I communicate this selection to Google, other search engines, and to the people visiting my website?
Enforcing Canonical Domain
Redirecting to the Canonical Domain
Even though I’ve chosen https://www.matthewedgar.net/ (with HTTPS and WWW) as my domain’s canonical version, it is entirely possible a person attempting to visit my site might type in the HTTP/no-WWW version of my domain in an attempt to reach my site. Google might try to access the HTTP/WWW version of my domain. Regardless of which version I’ve chosen as canonical, I want to make sure people using any version can access my website.
In order to do this, I need to redirect the other versions of my domain to the canonical version of my domain. Each of these versions of my domain need to redirect with a 301 response code in order to communicate this is a permanent redirect; that is, the redirect explicitly states you are choosing the canonical version of your domain over all others.
As well, it is important that the other variations of the domain redirect directly to the canonical version. In an incorrect setup, you might find that http://matthewedgar.net/ redirects to http://www.matthewedgar.net/ which then redirects to the canonical version with both HTTPS and WWW. This creates a chain of redirects or is sometimes also referred to as a double-hop redirect (to indicate the redirect hops through more than one step). The more steps in the chain, the worse it gets—one client we worked with had the http/www redirecting to the https/www, which redirected to the http/no-www version before finally redirecting to the canonical https/no-www version.
These redirect chains can impact the way Google crawls through your website and it is likely Google will stop following redirects at a certain point. As well, redirect chains can also slow down the experience for the user, especially if the server is slow to respond when redirecting. The simple answer? Avoid chains and redirect directly to the canonical version.
Linking to the Canonical Domain
Along with redirects, every link within your control should utilize the canonical version of the domain. Although we have the redirects in place, that doesn’t mean we want to force people to use our redirects. It is better for robot and human visitors if they can directly access the correct version of the URL without the need for a redirect. This also helps communicate to Google which version of the domain they ought to include in the search results.
That means, every link within your website needs to be updated to reflect the corrected version. When I moved my domain from the canonical version of HTTP/WWW to HTTPS/WWW, I went through all my old blog posts and updated the URLs to reference the new canonical version. Your results may vary, but generally this is an easy process of finding/replacing old links. When updating links on your website, you also want to make sure your XML sitemap includes the canonical version of the domain too.
Along with links within your website, any links contained on external profiles should be updated as well. This would include links to your website in local listings and social media. Here again, it is about helping people avoid the redirect. Sure, if the version linked to isn’t the canonical and you have the redirects in place, people can arrive on your website. But we want to clearly communicate which version is the canonical version while also saving people the need for any redirect. The best way to do that is by updating the profiles to link directly.
Google Search Console
To better understand how Google is looking at each version of the domain, you want to add each domain version as a property to Google Search Console. This means, you’ll have four versions of the domain added to Google Search Console.
To make this a bit easier to manage, you can also create a set of multiple properties:
If everything is configured correctly, you should only see activity in the Google Search Console property for the canonical version of the domain. However, it is easy for some pages to slip through the cracks—some pages don’t get redirected properly or there are links to non-canonical versions of a page. Whatever the reason, you can spot these in the Google Search Console properties containing the non-canonical versions of the domain.
As an example of how you can use this to detect problems, while writing this blog post, I discovered there was an old blog post of mine from years ago which was still linked to via HTTP and without WWW (not the canonical version of the domain). Thankfully, Google included it on the HTTP/no-WWW property within Google Search Console. Having found this, I was able to redirect the blog post to the HTTPS and WWW version of the domain instead along with correcting the links pointing to the non-canonical version of the blog post.
From the above, you may think the canonical decision comes down to two questions. While those are the biggest questions, it is worth mentioning there are other aspects to consider.
1. Trailing slashes add another layer of complication to your URLs. Do your URLs end in / or not? If you visit your home page without the trailing slash does it redirect you to the version of the page with the trailing slash (or vice versa)? Or, does the page show up in the browser with the trailing slash in the URL and also show up without the URL? If it shows up both with and without the trailing slash, you have a potential duplicate content issue as Google may see these as separate pages. This can be fixed with a canonical link elements but is typically better fixed by redirecting from no slash to trailing slash (or trailing slash to no slash).
2. The other consideration is with subdomains (like, subdomain.elementive.com). A subdomain is really just a separate domain, at least when it comes to deciding on the canonical version of that domain. With a subdomain, you’ll need to decide if it resides on HTTPS or HTTP and if there is a trailing slash or no slash. However, a subdomain is connected to the main website and often there will be links between the main domain and the subdomain. As a result, it is often wise to follow the same patterns. That is, if the main domain is HTTPS with a trailing slash, then the subdomain should also use HTTPS with a trailing slash.
Any more, every canonical version of the domain will include HTTPS, unless you don’t care about ranking in Google or users in modern browsers. This leaves you with the choice of WWW or non-WWW and the choice of slash or no slash. Once you’ve made these decisions, implement redirects to route other versions of the domain to the canonical version. As well, be sure to link appropriately to the canonical domain you’ve selected. Be sure to revisit these questions and steps for all subdomains.
Canonical domains (and canonical URLs) can get complicated fast. If you have any questions, please contact me and let’s talk about your specific situation to make sure you have the best plan in place.