Web hosting - www vs apex domains

Hosting your website involves business-critical decisions. One of the first: should you use the www sub-domain or the bare non-www (apex) domain? In other words, should your primary website be on mydomain.com or www.mydomain.com?

Personal preference

Your domain choice is primarily personal and branding preference. Some domains look better with a www. Some don't. In general, shorter domains can look more balanced with a www, e.g. www.bbc.co.uk. Longer domains may seem too long with the www.

Could your choice confuse users?

Your printed letters, leaflets, contracts, and other documents should show your domain. Most people will understand that it's a web URL when you're using a top-level domain such as .com, .net, .org, or a country-specific option (.co.uk, .fr, .de, etc.)

However, there are hundreds of other top-level domains that readers are less likely to recognise, e.g.

mydomain.courses
mydomain.dental
mydomain.gifts
mydomain.homes
mydomain.marketing
mydomain.ninja
mydomain.photo
mydomain.services

Adding the www in printed materials makes the web link more identifiable, but it's not necessary to use it online...

Always support both domains

Whichever alternative you prefer, it's important to support both the www and apex domain. Users should not encounter a 404 page because they choose to use or omit the "www".

HTTP certificates

You must register HTTPS certificates for both versions of the domain, or put both domains on the same certificate. Note that wildcard certificates for *.mydomain.com do not apply to the apex domain.

Canonical URLs

You can choose to keep the user's domain choice in the browser's address bar: they will see whichever domain they entered.

In this case, use relative or root-path URLs in your HTML <a> links -- it should not be possible for the user to switch domains by clicking a link.

Be aware that Google and other search engines can index both versions of your site and consider them to be identical copies. To avoid indexing and ranking issues, you can define a canonical <link> in the HTML <head> of every page with the URL of your preferred domain, e.g.

<link rel="canonical" href="https://mydomain.com/some-page/">

Domain redirection

The other option is to redirect the user to your www or apex domain as necessary. Redirecting can become complicated so be wary about introducing invalid redirects, infinite loops, or long chains. Appropriately redirecting pages should not affect search engine optimization but there's no harm adding canonical URLs.

Web hosts often provide redirect options, but web servers such as NGINX allow you to set a 301 permanent redirect header in the HTTP response:

# NGINX configuration - redirect to www domain
server {
  server_name mydomain.com;
  return 301 https://www.mydomain.com$request_uri;
}

# NGINX configuration - redirect to apex domain
server {
  server_name www.mydomain.com;
  return 301 https://mydomain.com$request_uri;
}

A similar Apache configuration:

# Apache .htaccess - redirect to www domain
RewriteEngine on
RewriteCond %{HTTP_HOST} ^mydomain\.com(?::\d+)?$ [NC]
RewriteRule ^/?(.*)$ https://www.mydomain.com/$1 [L,R=301]

# Apache .htaccess - redirect to apex domain
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.mydomain\.com(?::\d+)?$ [NC]
RewriteRule ^/?(.*)$ https://mydomain.com/$1 [L,R=301]

DNS record implications

You can use a DNS CNAME (canonical name) record to define the www sub-domain as an alias of the apex domain:

www.mydomain.com.  IN  CNAME  mydomain.com.
mydomain.com.      IN  A      1.2.3.4

This does not redirect: the user will see whichever domain they entered.

Additionally, some hosts provide DNS CNAME records to point your domain at their servers. This is possible for sub-domains such as www:

www.mydomain.com.  IN  CNAME  myhost.com.

but you cannot set a CNAME on the apex domain -- it usually requires an A or AAAA record with the web server's IP address.

Fortunately, domain registrars often provide a way around this restriction using ALIAS or ANAME records -- but you should check. Some offer domain flattening which permits apex CNAME records that resolve in the background to appropriate A or AAAA records.

Cookie implications

If you support both the apex and www domains without redirecting, you can share cookies across both by setting Domain=mydomain.com. However, this shares cookie data across all sub-domains -- not just your primary site.

Sharing cookies across sub-domains is not recommended:

it can lead to security issues. Any sub-domain can read, alter, or delete those cookies. Third-party client-side JavaScript can delete or overwrite cookies and read the data unless it's marked as HttpOnly.

it may affect performance. Browsers typically permit up to 20 cookies of 4KB or less. Up to 80KB of unnecessary cookie data can therefore be sent on the HTTP request and every HTTP response. A page with just 10 resources would incur an additional 800KB download.

That said, cookie sharing may be useful if a user's login session is retained across multiple applications running on different sub-domains.

Browser storage implications

Browser storage is always origin-specific and never shared elsewhere. This includes localStorage, sessionStorage, IndexedDB, and the Cache API for service workers.

Light and dark mode switchers often use localStorage. If you're not redirecting, the www and apex versions of your site could show a different theme.

Domain recommendations

Ideally:

Check your preferred primary domain will work with your registrar and website host.
Register HTTPS certificates for both the www and apex domains.
Redirect requests to your primary domain when the other domain is used.
Avoid inadvertently sharing cookies across sub-domains.
Set an appropriate canonical <link> on every page.
Test thoroughly. Then test again.

That said, nothing is set in stone and you may have specific use-cases. Please contact us for domain advice.