www vs. non-www: Which Domain Version Should You Use?

Type example.com or www.example.com into a browser and, on a well-run site, you land in the same place. Behind that seamless experience is a decision every site owner has to make: which version is the canonical one, and how do you make sure every other variation redirects to it? Get it wrong and you can end up with duplicate content, split analytics, cookie bugs, or a site that only works with one of the two. This article explains the real technical differences between www and non-www, how to choose, and how to enforce your choice with Nginx, Apache .htaccess, rel=canonical, and a few quick tests. For the DNS side of hosting a bare domain, also see what an apex domain is.

What Is the Difference Between www and non-www?

example.com is the apex (also called the root or naked domain). www.example.com is a subdomain of it. In DNS terms they are two separate names, and each needs its own records. A web server or CDN also treats them as two different hostnames.

Historically, www signalled "this is the web server" in the same way ftp. or mail. named other services. Today it is simply a convention. Browsers often hide it in the address bar, and users rarely type it.

Because they are separate hostnames, search engines treat https://example.com/page and https://www.example.com/page as different URLs. If both serve the same content without a redirect or canonical, you have duplicate URLs and search engines have to guess which one to show. Google is usually good at picking one, but it is far better to tell it explicitly.

Does Google Prefer One Over the Other?

No. Google has stated plainly that it does not matter for ranking whether you use www or not. What matters is consistency: pick one, redirect the other to it, and use it everywhere, including internal links, canonical tags, sitemaps, and structured data.

So the decision comes down to technical and branding considerations.

The Case for www

Using www.example.com as your primary hostname has real technical advantages:

Flexible DNS With CNAME

DNS rules forbid a CNAME record at the apex, because the apex must hold SOA and NS records and a CNAME cannot coexist with other records. A www subdomain has no such restriction, so you can point it at a CDN or hosting platform with a CNAME:

www    300    IN    CNAME    example.cdn-provider.net.

The provider can then move traffic between IP addresses at will without you changing anything. With an apex-only setup you need A/AAAA records, an ALIAS/ANAME record, or a provider with flattening. The details are in can you use a CNAME record on the root domain and what CNAME flattening is.

Cookie Scoping

Cookies set by example.com with a Domain=example.com attribute are sent to every subdomain: www, blog, api, static, and so on. If you serve the main site from the apex, it is easy to end up sending session cookies to every subdomain, which wastes bandwidth and can widen the impact of a compromised subdomain. Cookies set by www.example.com without a Domain attribute stay on www only.

Note that a cookie set by example.com without any Domain attribute is host-only and is not sent to subdomains. The problem arises when frameworks or analytics scripts set cookies for the whole domain, which many do by default.

Separation From Other Services

When the website lives on www, the apex can simply redirect, and other services such as mail records, verification TXT records, and SaaS tools can sit at the apex without interfering with web hosting.

The Case for non-www

• Shorter and cleaner. example.com is easier to say, print, and type.
• Matches what users type. Most people leave out www anyway.
• Modern DNS removes the main drawback. Many DNS providers offer ALIAS, ANAME, or CNAME flattening at the apex, and platforms like Vercel, Netlify, and Cloudflare make apex hosting straightforward. See what an ALIAS or ANAME record is.
• Brand style. Plenty of large sites use the bare domain successfully.

Quick Comparison

Factor	www	non-www
SEO ranking impact	None, if consistent	None, if consistent
CNAME to a CDN/host	Yes, standard	Not allowed; needs A, ALIAS, or flattening
Cookie isolation	Easier	Requires care with Domain attributes
Length and memorability	Slightly longer	Shorter
Works without redirect setup	No, the apex still needs a redirect	No, www still needs a redirect

Practical recommendation: if you use a CDN or hosting platform that wants a CNAME, or you run many subdomains with cookies, choose www. If your DNS provider supports apex aliasing and you prefer the shorter look, non-www is perfectly fine. Whichever you pick, keep it forever, because switching later is a site migration.

Step 1: Make Both Versions Resolve

Both names need DNS records, even the one that only redirects. A typical setup for a www-primary site on a single server:

@      3600    IN    A        203.0.113.10
@      3600    IN    AAAA     2001:db8::10
www    3600    IN    CNAME    example.com.

Check them with dig:

dig +short example.com A
dig +short www.example.com

Your TLS certificate must also cover both names, or visitors who hit the non-primary version over HTTPS will see a certificate error before the redirect can happen:

sudo certbot certonly --nginx -d example.com -d www.example.com

Step 2: Redirect to the Canonical Version

The redirect must be a 301 (permanent), must preserve the path and query string, and should get any variation to the final URL in one hop. There are four variations to handle:

• http://example.com
• http://www.example.com
• https://example.com
• https://www.example.com

Three of these should redirect to the fourth.

Nginx: Redirect non-www to www

# All HTTP traffic, both hostnames, goes straight to the canonical HTTPS URL
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

# HTTPS on the apex redirects to www
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://www.example.com$request_uri;
}

# The canonical site
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example.com;
    index index.html;
}

Nginx: Redirect www to non-www

Swap the hostnames:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://example.com$request_uri;
}

The canonical server block for example.com on port 443 stays as normal. Using separate server blocks with return is faster and clearer than an if ($host ...) check inside one block. Test and reload with sudo nginx -t && sudo systemctl reload nginx.

Apache .htaccess: Redirect non-www to www

Place this at the top of .htaccess in your document root (requires mod_rewrite):

RewriteEngine On

# Force HTTPS and www in a single redirect
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://www.%1%{REQUEST_URI} [R=301,L,NE]

The third condition captures the hostname without any www. prefix into %1, so the rule works for any domain without hardcoding it.

Apache .htaccess: Redirect www to non-www

RewriteEngine On

# Force HTTPS and strip www in a single redirect
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L,NE]

If your site sits behind a load balancer or CDN that terminates TLS, %{HTTPS} may always be off on the origin and cause a redirect loop. In that case, test the forwarded header instead, for example RewriteCond %{HTTP:X-Forwarded-Proto} !https, or handle the redirect at the CDN.

On WordPress, also set both the WordPress Address and Site Address under Settings, General to your canonical version, or WordPress will fight your rules.

Cloudflare

If the domain is proxied through Cloudflare, you can do the redirect at the edge with a Redirect Rule matching http.host eq "example.com" and a dynamic target such as concat("https://www.example.com", http.request.uri.path) with the query string preserved and status 301. The record for the redirecting hostname must be proxied for the rule to run. More on edge redirects in what domain forwarding is and how to set it up.

Step 3: Add rel=canonical

Redirects are the primary signal, but a self-referencing canonical tag on every page reinforces it and protects against stray duplicates such as tracking parameters. In each page's head:

<link rel="canonical" href="https://www.example.com/blog/my-post/" />

Always use the absolute URL on the canonical hostname and scheme. In the Next.js App Router, set it through the Metadata API:

import type { Metadata } from "next";

export const metadata: Metadata = {
  metadataBase: new URL("https://www.example.com"),
  alternates: {
    canonical: "/blog/my-post/",
  },
};

Also make sure your XML sitemap, hreflang annotations, Open Graph og:url, and structured data all use the canonical hostname. A sitemap that lists non-canonical URLs sends mixed signals.

Step 4: Test Every Variation

Use curl to confirm that each variation reaches the canonical URL in a single 301:

for url in http://example.com/about http://www.example.com/about https://example.com/about https://www.example.com/about; do
  printf "%-36s " "$url"
  curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" "$url"
done

Expected output for a www-primary site:

http://example.com/about             301 https://www.example.com/about
http://www.example.com/about         301 https://www.example.com/about
https://example.com/about            301 https://www.example.com/about
https://www.example.com/about        200

Finally, in Google Search Console, a Domain property covers both hostnames, so you can confirm that the canonical version is the one being indexed. The URL Inspection tool shows the "Google-selected canonical" for any page.

HSTS and the Preload List

Once HTTPS and your redirects are stable, add an HSTS header so browsers always use HTTPS. To be eligible for the browser preload list, the header must be served on the apex, which is another reason the apex must answer over HTTPS even if it only redirects:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Only add includeSubDomains (and later preload) once every subdomain supports HTTPS, because the policy is hard to undo.

www vs. non-www FAQ

Conclusion

The www versus non-www decision has no SEO winner. The www version has genuine technical advantages, mainly the ability to use a CNAME and cleaner cookie isolation, while non-www is shorter and is easy to host on modern DNS providers that support apex aliasing. Either is a good choice as long as it is a deliberate one.

What actually matters is enforcement. Make both hostnames resolve, cover both with your certificate, redirect every variation to the canonical URL with a single 301, reinforce it with self-referencing canonicals and a clean sitemap, and test all four combinations of scheme and hostname. Once that is in place, you never need to think about it again.

Here are some useful references for going deeper on canonical hostnames:

1. Google Search Central: How to Specify a Canonical URL — Google's guide to redirects, rel=canonical, and sitemaps for consolidating duplicates.
2. Google Search Central: Redirects and Google Search — which redirect types Google treats as permanent.
3. Apache HTTP Server: mod_rewrite Reference — official documentation for RewriteCond and RewriteRule.
4. MDN Web Docs: Strict-Transport-Security — how HSTS works and how to deploy it safely.
5. RFC 1034: Domain Names, Concepts and Facilities — the DNS rule that a CNAME cannot coexist with other records.