WWW vs Non-WWW: Which to Choose and How to Redirect the Other

Let's answer the ranking question up front so you can stop worrying about it: Google does not rank www.example.com any differently from example.com. Google's documentation treats them as two separate sites that you tell it are the same. Pick either one. Neither is faster, neither is more trusted, neither ranks higher. Anyone selling you a ranking advantage for www or for non-www is wrong.

What actually matters is consistency. You need to choose one canonical host and make sure every other version of your URL redirects to it. If both www.example.com and example.com serve your site with a 200 OK, you've split your site in two: links, cached signals, and the odd crawl get divided across two hostnames that Google has to reconcile. That's the real cost, and it's entirely avoidable.

So this post spends almost no time on "which is better for SEO" (the answer is "neither") and most of it on the two things that do have real answers: the handful of technical edge cases where www is genuinely more convenient, and exactly how to redirect the other three variants cleanly.

The four variants you actually have

People say "www vs non-www" as if there are two options. There are four, because the scheme matters too:

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

One of these is your canonical. The other three must 301 redirect to it, in a single hop each, with no chains. Whichever host you choose, HTTPS is non-negotiable in 2026, so your canonical is one of the two https:// versions and the two http:// versions always redirect up to HTTPS.

The technical edge cases where www is easier

If SEO is a wash, is there any reason to prefer one? A couple, and they're about DNS and cookies, not rankings.

Apex domains can't have a CNAME. The naked domain example.com is the "apex" or "root". DNS rules (RFC 1034) say the apex can't have a CNAME record alongside its required NS and SOA records. Many CDNs and hosts want you to point at them with a CNAME, which a subdomain like www can do freely. On the apex you're stuck using an A record with a fixed IP, or relying on your provider's "CNAME flattening" or "ANAME/ALIAS" workaround. If your host offers those (Cloudflare does, via CNAME flattening), the apex is fine. If it doesn't, choosing www as canonical sidesteps the whole problem.

Cookie scope. A cookie set on the apex example.com is sent to every subdomain: www, blog, shop, static, all of them. If you serve static assets from static.example.com, those requests carry your apex cookies for no reason, which slightly bloats every asset request. Using www as your canonical keeps the main-site cookies scoped to www and off a cookieless asset subdomain. For most small sites this is negligible. For asset-heavy sites it's a small real win for www.

Neither of these forces your hand. If your host does CNAME flattening and you don't run a separate asset subdomain, the naked domain is cleaner and shorter, and plenty of large sites use it. Pick on those practical grounds, then never think about it again.

How to pick

A short decision path:

1. Does your CDN or host require a CNAME at the root, with no flattening? Choose www.
2. Do you serve assets from a cookieless subdomain and care about request size? Lean www.
3. Otherwise, choose whichever you prefer to read and say out loud. Non-www is shorter.

Then commit. Set your canonical host in one place and make everything else point at it.

Implementation: 301 everything to one host

Here are clean configs. In every example the goal is the same: all three non-canonical variants land on the canonical in one hop.

nginx, canonical https://example.com (non-www):

# Redirect www to non-www and force HTTPS in one place
server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    # ... your actual site config, ssl_certificate, etc.
}

Apache / .htaccess, canonical https://www.example.com (www):

RewriteEngine On
# Force HTTPS and www together, single redirect
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]

The [OR] and the combined rule matter here: they collapse the HTTPS fix and the www fix into a single 301 rather than chaining an HTTP-to-HTTPS redirect into a separate non-www-to-www redirect. Chained redirects work but they're slower and waste crawl budget; if you already have a chain, see how to fix redirect chains and loops.

Cloudflare (no server access needed): create a Redirect Rule under Rules > Redirect Rules. Set the condition Hostname equals www.example.com (or the inverse), action Dynamic, expression concat("https://example.com", http.request.uri.path), status 301. Cloudflare's "Always Use HTTPS" toggle handles the scheme upgrade separately, so together they cover all four variants.

A note on WordPress: don't do this at the app layer if you can help it. Set your Site Address and WordPress Address in Settings > General to the exact canonical, and handle the host/scheme redirect at nginx, Apache, or Cloudflare. Layering a WordPress SSL plugin on top of a server rule is a classic way to create a loop, which we cover in ERR_TOO_MANY_REDIRECTS.

Verify it, don't assume it

After you deploy, test all four variants. The fastest way is to run each through our redirect checker and confirm two things: every non-canonical variant returns a single 301 straight to the canonical, and the canonical itself returns 200 with no redirect. If you see a 301 that points to another 301, you've built a chain and should collapse it. If a variant returns 200 on its own, it isn't redirecting at all and you've still got a split site.

One more belt-and-braces step: make sure every page also carries a self-referencing <link rel="canonical"> pointing at the canonical host. The redirect handles users and crawlers who hit the wrong variant; the canonical tag reinforces which host is authoritative if a variant ever slips through. Our canonical tags guide covers getting those right. And if you're weighing when a 301 is correct versus a temporary 302, the answer for host consolidation is always 301, but 301 vs 302 explains why.

Frequently Asked Questions

Is www or non-www better for SEO?

Neither. Google treats them as separate sites but ranks them identically once you tell it which is canonical, via a redirect and a canonical tag. There is no ranking advantage either way. Choose based on technical convenience (CDN CNAME requirements, cookie scoping) or simple preference, then apply it consistently.

What happens if both www and non-www load my site?

You've effectively split your site across two hostnames. Links and crawl signals get divided between them, and Google has to work out that they're the same site. It's not a penalty, but it's untidy and can dilute signals. Fix it by 301 redirecting one host to the other so only one version ever returns a 200.

Should I use a 301 or 302 to redirect www to non-www?

A 301 (permanent). Host consolidation is permanent by definition, and a 301 tells search engines to consolidate signals onto the canonical host and update their index. A 302 (temporary) would leave both hosts in play. Only use 302 for genuinely temporary situations, never for choosing a canonical host.

Why can't I add a CNAME to my root domain?

DNS rules don't allow a CNAME record to coexist with the NS and SOA records that every apex domain must have. That's why hosts often ask you to point www (a subdomain, which can use a CNAME) at them. Some providers offer CNAME flattening or ALIAS/ANAME records that work around this on the apex; if yours does, the naked domain is fine as canonical.

Do I still need a canonical tag if I set up the redirect?

Yes, use both. The redirect handles anyone who requests the wrong host. The self-referencing canonical tag reinforces the authoritative URL if a non-canonical variant ever gets crawled or linked directly. They cover slightly different cases, and together they make your canonical host unambiguous.