TL;DR: Google doesn’t care whether your site uses www.example.com or just example.com. When I’m setting up a new site, I prefer www. You can point it at your host with a standard CNAME, which gives you fewer DNS complications when you move later. You still need HTTPS and a redirect on the bare domain. And if an established site already uses the bare domain, I wouldn’t change its address without a good reason.
Building Bernard means dealing with the things a website owner quite reasonably doesn’t want to think about. DNS is one of them.
They want their website moved. They want their email to keep working. They want the links they’ve sent people over the last ten years to keep opening the right pages.
Behind that simple request are a registrar, a DNS provider, an old host, a new host, certificates and redirects. Sometimes several of those are the same company. Sometimes nobody is quite sure who controls what.
Then there’s a decision that looks like a matter of taste: should the website use www?
For me, it’s an engineering decision. Here’s why.
The apex is the bare domain
example.com is the zone apex. You’ll also hear it called the root or bare domain. www.example.com is a subdomain.
The important difference is that the apex has other jobs. It holds the zone’s essential DNS records, and usually its email routing and some verification records too.
You can’t put an ordinary CNAME there. A CNAME makes one name an alias of another, and it can’t sit alongside ordinary records at that same name. The apex already needs its SOA and NS records. That restriction is in RFC 1034.
With www, you can do this:
www.example.com. CNAME site.hosting-provider.example.Your website points to a name the host manages. The host takes responsibility for the infrastructure behind it.
One DNS change is easier to automate
When you move the site, you can replace that CNAME destination with the new host’s hostname. The public address stays the same. The email records stay where they are. You don’t inherently need to transfer the domain or move the whole DNS zone.
To be fair, moving an apex site can be just as small a change. If the new host gives you a stable IP address, you change an A record.
The complication comes when the host gives you a hostname instead. At www, that’s straightforward. At the apex, you need to know what the DNS provider supports.
For one website, a developer can work that out. When you’re trying to automate website moves, it’s another branch in the process, another set of instructions and another thing to verify.
Yes, there are ways around it
ALIAS records, ANAME records and CNAME flattening all exist to address this sort of problem.
Cloudflare’s flattening, for example, resolves the destination hostname and returns IP addresses. You get the useful behaviour of following a hostname while keeping the other records the apex needs.
That works. But now your setup depends on a feature of your DNS provider, and you need to check its behaviour against the requirements of your host.
My preference is to avoid needing that extra capability in the first place. A standard CNAME at www gives the migration process fewer special cases.
The host gets more room to manoeuvre too
A hostname also gives the hosting company a useful layer of indirection. It can change the underlying IP addresses without asking every customer to edit their DNS.
Vercel recommends www for exactly this flexibility: its CNAME setup gives the network more control over traffic for reliability, performance and security.
That doesn’t mean an apex site is inherently slow or unreliable. Vercel supports those too. It means the hostname gives the provider more options, which is useful when you’re building a hosting platform.
The redirect still needs engineering
There’s a trap here: a CNAME is not a redirect.
It helps resolve a name. It doesn’t change the address in the browser.
If someone opens https://example.com/about, something has to accept that connection and send them to https://www.example.com/about.
And because that first connection is HTTPS, it needs a valid certificate for example.com. The browser checks the secure connection before it receives the redirect. Saying “that domain only redirects” doesn’t get you out of operating it properly.
For a new site using www, this is the behaviour I want:
| Request | Result |
|---|---|
http://example.com/about | Redirect to https://www.example.com/about |
https://example.com/about | Redirect to https://www.example.com/about |
http://www.example.com/about | Redirect to https://www.example.com/about |
https://www.example.com/about | Serve the page |
Ideally, that’s one redirect straight to the final URL, keeping the path and query string.
“The DNS record is correct” is only one check. I also want to know that the certificate is ready, the redirects behave properly and real page addresses still work. A stale AAAA record matters too: IPv6 visitors could still be sent to the old host.
Then there’s ownership. If the apex redirect lives on the old hosting account, what happens when the customer cancels it? The redirect needs to be part of the move, with somewhere to live afterwards.
Google doesn’t mind. I mind how many cases we have to support.
Google has no indexing or ranking preference between www and the bare domain. Pick the main version, keep your links and sitemap consistent, and use permanent redirects from the other version.
I wouldn’t use this as an excuse to change every existing apex site. Moving the hosting and changing the public URLs are separate decisions. If the current address works, keeping it may be the better call.
For a new site, I’d choose www. It gives us a standard CNAME, fewer dependencies on the DNS provider and more freedom to move the website later.
Three letters. Fewer things to work around.
If you’re planning a move, Bernard moves and hosts websites. For more of the engineering behind it, read Building a CMS from scratch in 2026.