WWW vs Non-WWW: Which Is Better and How to Make Both Work

Neither is better for search ranking. www.example.com and example.com are two different hostnames that happen to show the same site, and search engines treat whichever one you declare as canonical the same way. What matters is that you pick one, redirect the other to it with a 301, and make sure both actually answer. The choice itself has a few technical consequences (DNS, cookies, HSTS, certificates), and those are what this guide is about, along with the classic support ticket: "the site does not open without www".

Two hostnames, not one

To DNS, example.com (the apex domain, also called the bare, naked or root domain) and www.example.com (an ordinary subdomain) are unrelated names. Each needs its own records, its own entry in the web server configuration and its own place on the certificate. Nothing makes www work automatically because the apex works, or the other way round.

$ dig +short example.com A
192.0.2.10
$ dig +short www.example.com
edge.cdn.example.
203.0.113.20

The DNS difference: the apex cannot be a CNAME

A CNAME record says "this name is an alias, look over there for everything". For that reason the DNS standards (RFC 1034, clarified in RFC 2181) do not allow a CNAME to coexist with any other record at the same name. The apex of a zone always has an SOA record and NS records, so a CNAME at the apex is not valid. Some control panels refuse it; others accept it and produce a zone that breaks mail in hard-to-predict ways.

www has no such restriction, and that matters because CDNs, PaaS hosts and site builders usually ask you to point a CNAME at a hostname of theirs. That lets them change the IP addresses behind it without touching your zone.

For the apex you have three options:

Option	How it works	Trade-off
Plain A / AAAA records	You enter the provider's fixed IP addresses	You must update them if the provider changes addresses
ALIAS / ANAME / "CNAME flattening"	Your DNS provider resolves the target itself and answers with A/AAAA records	Provider-specific feature, not a standard record type; behaviour and naming differ per provider
Apex only redirects	The apex points to a small redirect service or server, and the real site lives on `www`	One more component to keep running and to cover with a certificate

Nothing called ALIAS ever appears in a DNS answer: the provider's nameserver looks up the target and hands out ordinary address records. If you move the zone to a provider without the feature, the record cannot move with it.

This is the main practical argument for www as the canonical host: it can always be a real CNAME, on every DNS provider.

Cookies

Cookie scope is the second real difference.

A cookie set with Domain=example.com is sent to example.com and to every subdomain: www, static, api, blog, all of them.
A cookie set without a Domain attribute is a host-only cookie. Set on www.example.com, it goes back to www.example.com and nowhere else.

With www as the canonical host you can therefore keep session cookies host-only on www and serve assets from static.example.com without any cookies attached to those requests. With the apex as canonical, host-only cookies behave the same way and stay on example.com. The trap is any cookie that carries Domain=example.com (many analytics and consent scripts set it that way): on an apex site it is sent to every subdomain, including ones run by third parties you have pointed a CNAME at.

Redirects: one hop, permanent, path preserved

Whichever host loses should answer every request with a permanent redirect to the same path on the winner:

$ curl -sI http://example.com/pricing?plan=pro
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/pricing?plan=pro

$ curl -sI https://www.example.com
HTTP/2 200

Rules that save trouble later:

Use 301 (or 308, which also preserves the request method). A 302 tells clients the move is temporary.
Preserve the path and the query string. Redirecting everything to the home page throws away deep links.
Aim for one hop: http://example.com/x straight to https://www.example.com/x, not http → https → www. The exception is HSTS preloading, described below, which requires the HTTP → HTTPS step to happen on the same host first.
Put the same choice everywhere else: rel="canonical", internal links and the sitemap.
In Google Search Console, a Domain property covers both hosts (and both protocols), so you do not need to verify them separately.

The redirect checker follows a chain hop by hop.

HSTS

HSTS is sent as a response header and applies to the host that sent it. With includeSubDomains, a header sent by the apex covers every subdomain of the domain. Before you turn it on, make sure every subdomain, including the forgotten intranet host, really serves HTTPS.

Two details people miss:

If www is canonical and the apex only redirects, browsers see the apex's policy only when they visit the apex over HTTPS. Send the HSTS header on the apex's redirect response too, not only on www.
The browser preload list has its own requirements for the apex: a valid certificate, an HTTP → HTTPS redirect on the same host, and an HSTS header with max-age of at least 31536000 seconds, includeSubDomains and preload. Removal from the list is slow, so treat preloading as a one-way decision.

Certificates

The certificate has to list both names as subject alternative names. This is the point most often forgotten, because the redirect from the losing host can only be sent after the TLS handshake on that host has succeeded. No valid certificate for example.com means a browser warning, not a redirect.

A wildcard does not help: *.example.com covers www.example.com and does not cover example.com. Wildcard certificates therefore normally list both *.example.com and example.com.

$ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -ext subjectAltName
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

Run it twice, once per hostname in both -connect and -servername, or use the SSL checker, which lists the hostnames covered by the TLS certificate the server presents.

"The site does not open without www"

Work through the layers in order:

Symptom on `example.com`	Likely cause	Check
Name does not resolve, or the browser reports the server cannot be found	No A/AAAA record at the apex, only `www` was created	`dig +short example.com A` and `AAAA`
Hosting provider's default page or a different site	The web server has no virtual host (server name) for the bare domain	`curl -sI http://example.com`, then the vhost / `server_name` / domain list in the hosting panel
Certificate warning on `https://`, while `http://` redirects fine	The certificate does not include the bare name	the `openssl` command above
Works on `http://`, times out or errors on `https://`	The CDN or load balancer has the apex hostname missing from its configuration, so only `www` is served over HTTPS	the provider's hostname list; `curl -sI https://example.com`
Redirect loop	The origin redirects to one host and the CDN or a plugin redirects back	`curl -sIL https://example.com` and read each `Location`

The mirror case (the bare domain works, www does not) has the same causes with the names swapped: a missing www record, no vhost alias, or a certificate issued for the apex only.

A missing answer from your own machine may also be a stale negative cache; see what TTL means in DNS.

Common mistakes

Putting a CNAME at the apex because the hosting instructions said "add a CNAME", and breaking MX records as a result.
Issuing the certificate for one name. The redirect then sits behind a certificate error.
Redirecting with 302, or redirecting every path to the home page.
Turning on includeSubDomains before checking what runs on the subdomains.
Letting both hosts serve the full site with 200 and relying on rel="canonical" alone.

So which one?

Choose www if you use, or may one day use, a CDN or platform that wants a CNAME, or if you want clean cookie separation between the site and its other subdomains.
Choose the apex if you prefer the shorter name and your DNS provider offers ALIAS/flattening or your host gives you stable IP addresses.
If the site already exists, keep what is indexed and fix the redirects instead.

If a related question is whether a section should live on its own hostname at all, see subdomain vs subdirectory; for the record types mentioned here, DNS record types explained.

Check it with OrbitProbe

Run the OrbitProbe DNS lookup once for example.com and once for www.example.com. It shows the A, AAAA and CNAME records with their TTLs as public resolvers return them at that moment, so you see immediately whether one of the two names has no address and whether www is a CNAME to your provider. If both names resolve and the problem remains, move on to the redirect chain and the certificate names.