When you type a website name into the browser address bar, do you ever start with www? Can you tell whether Wikipedia, Amazon, Facebook, and Twitter are www or non-www? Don’t worry if you can’t because you’re not alone.
Since popular web browsers like Google Chrome and Safari now hide the www part of a URL, it’s easy to lose track of the www prefix in the names of popular websites. If you’re wondering, all of the above-mentioned Internet giants except for Twitter are www. But if you type facebook.com instead of www.facebook.com, you’ll still get your news feed loaded in a few seconds.
The fact that omitting the www part won’t hinder your access to most websites can make you think that www is obsolete, and you may not bother to include it in your website URL at all. But if that were the case, then why would Wikipedia, Amazon, and Facebook stick to this conventional format?
In this post, we’ll consider the pros and cons of making www a part of your website name. On top of that, I’ll also share some technical setup tips that will help you keep your website SEO-friendly regardless of whether you choose to go www or non-www.
What’s the point of www?
Before we delve into discussing all the benefits and drawbacks of keeping or skipping the www part, let’s first understand where it comes from. To run a website, you basically need two things: a server where all your website files will be stored along with an easily memorable name aka the domain name. The latter will let users access your website by typing (www.)example.com instead of the server’s IP address into the address bar with DNS doing all the heavy lifting.
So, why would you add the www prefix to your registered domain name? Historically, such prefixes were used as a means of differentiating between servers within your network. In the early days of the Internet, there were no hosting providers and virtual private servers. Every company used to manage its own network of servers, every server within the network was considered a host and performed a single function like storing files for sharing on the web or mail exchange. So, with regard to the kind of service the host provided it received a particular host name.
|SERVICE PROVIDED BY THE HOST||HOST NAME||FULLY QUALIFIED DOMAIN NAME|
|Stores files for sharing on the web||www||www.example.com|
|Used for exchanging files within the network||ftp||ftp.example.com|
|Handles e-mail delivery over a network||mail.example.com|
When combined with the company’s registered domain, each host name formed a fully qualified domain name (FQDN) – an Internet equivalent of the property’s full address with the zip code, street name, city name, etc. Entering the FQDN into the browser address bar allowed users to access the necessary server within the company’s network.
In the modern Internet landscape, things no longer work that way. A single server with one IP address can be used both as a web server and as a mail server. Besides, it is common practice to point both the root domain—this is how non-www websites are called in technical terms—and the www hostname to the same IP address. It will let users access your website regardless of whether or not they add www to the website URL. For SEO reasons, however, you’ll still need to choose which of the two domain name variations you prefer.
Putting it right SEO-wise
Surely you want to decide whether to go www or non-www with SEO in mind. But from an SEO standpoint, it doesn’t really matter which option you go for, as was confirmed by John Mueller on Twitter. Favoring one over another is really a question of branding and technical capabilities—we’ll dwell on both things in more detail later.
If you make your website accessible through both www and non-www, what matters for SEO is telling Google which of the domain name variations is your preferred one. Otherwise, Google will treat the www and non-www versions as separate websites, they will both get indexed, and you’ll have to deal with the duplicate content issue.
When it comes to indicating your preferred domain name (also called canonical), you have several means at hand. The most common solution would be to set up server-side 301 redirects. That way, every time a server receives a request to the non-canonical domain, it will automatically redirect users to the canonical equivalent. So, if your preferred version is www.example.com and a user types example.com/page01, he or she will end up seeing www.example.com/page01 in the browser address bar.
If for some reason you have no technical means to set up 301 redirects, you can add the rel=canonical <link> tag to the HTML code of all non-preferred version pages. Just keep in mind that this method is not as reliable as 301 redirects. Google treats canonicals as recommendations and not instructions, and as a result, both website versions may get indexed.
So, if adding rel=canonical tags works better for you anyway, here’s how you can implement it. If your preferred version is www.example.com, add the following line to the HTML code of https://example.com/page01.
<link href="https://www.example.org/page01" rel="canonical">
With WordPress 2.9 or higher, rel=canonical tags will be added to all your website pages automatically, so you won’t even have to do anything on your own. Tags will either point to www or non www versions of your website depending on the one you specified as your WordPress Address (URL) under the general settings of WordPress.
From the user perspective, the difference between using 301 redirect and rel=canonical tags is that, in the latter case, the URL in the browser’s address bar and history doesn’t change. So, a user trying to access example.com will see this exact URL in the address bar even if www.example.com is your canonical variation. However, as popular web browsers now skip www, I doubt that users will even notice that something’s changed.
Now, once you decide whether to go www or non-www and mark your preferred version as canonical using either of the two methods, it’s also essential to consistently use your chosen URL variation. So, if you decided to keep www, make sure all your Sitemap URLs and internal links are www. Moreover, whenever possible, try to arrange for your backlinks to also include www—while both 301 redirects and rel=canonicals are supposed to pass link juice, some of it may get lost along the way. In turn, Google will appreciate your consistency and reward you with better rankings.
No set-it-and-forget-it approach
Once you set up 301 redirects or mark preferred pages with rel=canonical tags, make sure to check from time to time if things are still working properly. If you’re wondering why they wouldn’t, here’s a real-life example.
Let’s say you’ve marked your webpages with rel=canonical tags and then added a new WordPress theme that automatically included the same tag on all pages that you were unaware of. So, you’ll end up having duplicate rel=canonical tags, which Google finds confusing, but you won’t even know that there was a problem until it impacts your SEO performance.
To avoid such situations, you can systematically run a website audit. SE Ranking’s Website Audit tool, for example, will tell you if some pages of your website have duplicate rel=canonical tags, if several pages point to the same canonical URL or if some pages are missing the rel=canonical tag.
Under the audit’s Health check section, you can see if you have 301 redirects from www to non-www (or vice versa) set up properly.
You can set SE Ranking to run a website audit for you regularly, like every week or month, so that you’ll be able to spot if something goes wrong in time. To check if everything is set up properly on your website, you can start your 14-day free trial and the system will automatically audit your website as soon as you add your project to the platform.
Choosing the preferred domain
Now that you know how important it is to clearly tell Google which domain name version you prefer, let’s finally figure out which of the two will serve you better as canonical. At first sight, the non-www URL looks neater and more appealing. It also rolls off the tongue much easier. As English author Douglas Adams once noted, it takes three times longer to pronounce the abbreviation www than simply saying “World Wide Web”. So, it’s no wonder broadcasters normally drop the www part when mentioning a website on-air. This is actually what most people do when saying a website name out loud.
When typing a domain name in the address bar, users who don’t remember the early days of the Internet typically also skip the www part. So why not skip it when choosing the canonical version of your website name? After all, it’s 2020 and people will still understand it’s a web address even if www is not a part of the URL and as long as you use one of the common top-level domains like com, net or org.
It really makes sense to choose non-www for the sake of branding. But before doing so, there are some technical restrictions you need to consider. These limitations are the reason why Internet giants stick to www.
When is www a necessity?
Let’s say you decided to go non-www and mapped both your root domain and hostname to the same IP address you received from your hosting provider. It is done using an A-type record, and the DNS record looks like this.
example.com. IN A 192.0.2.0 www.example.com. IN A 192.0.2.0
Then you marked example.com as your canonical domain. Everything looks good so far.
Now, let’s assume that one day your website will significantly grow and will start getting thousands or even millions of visitors every day. A single server cannot sustain such an increased load, and that’s the reason big websites like Wikipedia, Amazon, and Facebook don’t have their domains mapped to a single IP address. Instead, they rely on content delivery networks (CDN) to quickly and securely deliver content to millions of their users. So, you’ll naturally want to also use a CDN. And here come the technical limitations.
Handling loads of traffic
According to DNS specifications, root domains should always point to an IP address. But to make use of CDNs, you’ll need to point your website to a CDN domain, and not to an IP address. Theoretically, you can map your domain both to an IP address using an A-type record and to a CDN domain using a CNAME record. But here comes another DNS rule telling that a CNAME record cannot co-exist with other resource records types. So, if you add both, the A-type record pointing to the IP address will be ignored, violating the first rule.
If you got slightly overwhelmed by all the technical terms mentioned above, here’s the short version. Because of the way DNS requests work, you cannot point a non-www host name to a CDN domain. Doing so will lead to unexpected errors and won’t let your website function properly.
At the same time, if you choose the www host name as your preferred version, you won’t have any problems complying with DNS rules. You’ll simply create a CNAME record for the www hostname, mapping it to a CDN of your choice. And you’ll also add an A record for your root domain pointing to your website’s IP address.
www.yourdomain.com. CNAME somecdn.com. yourdomain.com. A 192.0.2.1
It is also worth mentioning that some DNS providers like Cloudflare, DNS Made Easy, DNSSimple, and more have introduced workarounds to overcome the DNS restrictions. But relying on the workarounds will limit your choice of DNS providers and you may also face the problem of hindered user experience because of users being routed to a far-away CDN node.
Taming website cookies
In addition to DNS limitations, choosing a root domain as canonical brings up the cookies issue. The thing is in modern browsers, cookies of the main domain are automatically passed down to subdomains. So, if you set cookies for example.com, they will also be sent to static.example.com, email.example.com, etc. And here’s why this is a bad thing.
The second reason is security risks. When you log into your website’s CMS, a cookie is issued. Then when you visit mail.example.com or cdn.example.com, the cookie is sent to these subdomains and can be read by server administrators. It poses a security risk as administrators can copy the cookie and use it to log into your corporate CMS. To mitigate the risk, you can resort to IP restriction only allowing access to your corporate network IPs.
So, if you want to optimize your website’s speed by hosting static content separately, but you are not quite eager to purchase a whole new domain for this purpose, consider keeping the www prefix in your preferred domain name. This way, you also won’t have to worry about third parties reading your website cookies.
To www, or not to www
The www prefix in the domain name may seem little and insignificant, but it can make a big difference. Your branding and your website’s scalability are affected, so make sure to choose wisely based on your priorities and future plans. And once you make the decision, mark your preferred version as canonical and stick to it. Switching back and forth from www to non-www is technically possible, but it won’t do your website’s SEO any good.
Finally, we’d love to hear which camp you are in. Share in the comments sections below why you prefer to www or not to www.