WWW vs Non-WWW: Which Is Better for SEO?

Every few months somebody asks whether dropping the www will give them a ranking boost, usually after reading that it looks “more modern”. It won’t. Google has no preference. But the question isn’t pointless, because the choice has technical consequences that matter far more than SEO, and sites that never make the choice do have a measurable problem.

Does www vs non-www matter for SEO?

To Google, www.example.com and example.com are separate hostnames. Each URL on them is a separate URL. If both answer with the same page and a 200 status, you have a duplicate of every page. Google will cluster them and pick one as canonical. Nothing is penalised, but your links get split while Google works it out, and reports in Search Console get confusing.

So the SEO answer has two parts. Which one you pick: irrelevant. That you pick one, and enforce it with a redirect: necessary.

The technical differences that do matter

The DNS point is the one that has bitten many people. RFC 1034 doesn’t allow a CNAME at the zone apex alongside the SOA and NS records that must be there. Platforms that hand you a hostname to CNAME to, such as some hosting and CDN services, work naturally with www but need provider-specific workarounds at the apex. Cloudflare solves it with CNAME flattening, other DNS providers with ALIAS records. If your DNS host offers neither and your platform only gives you a CNAME target, www is the pragmatic choice.

The cookie point matters for larger setups. If you set a cookie with Domain=example.com, browsers send it to static.example.com and every other subdomain too. With the site on www, you can keep session cookies host-only and serve assets from a cookie-free subdomain. For a small site that’s irrelevant.

My own default: non-www for short brand domains on a modern DNS provider, www when the hosting platform wants a CNAME and the DNS host can’t flatten.

Redirect www to non-www in nginx

Separate server blocks, one per job:

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;
    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;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name 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;
}

The first block catches plain http for both names and goes straight to the final https URL. No chain via https://www. The certificate must include both names, which with certbot means -d example.com -d www.example.com.

For the opposite direction, swap the hostnames: the https block for example.com returns 301 https://www.example.com$request_uri.

Redirect www to non-www in Apache

In the .htaccess at the document root:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

The first rule handles www on both protocols, the second catches plain http on the bare domain. Both target the final URL, so no request needs two hops. Behind a load balancer or proxy that terminates TLS, %{HTTPS} is always off; check %{HTTP:X-Forwarded-Proto} instead or you’ll build a loop.

Redirect with Cloudflare

With the zone on Cloudflare and the www record proxied, add a Single Redirect Rule:

• Expression: http.host eq "www.example.com"
• Type: Dynamic, concat("https://example.com", http.request.uri.path)
• Status 301, preserve query string on

Turn on “Always Use HTTPS” for the http-to-https part. Cloudflare’s free plan includes enough redirect rules for this.

Testing all four variants

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

http://example.com/ -> 301 https://example.com/
http://www.example.com/ -> 301 https://example.com/
https://www.example.com/ -> 301 https://example.com/
https://example.com/ -> 200 

Three 301s pointing at the same final URL and one 200. Anything else, such as two 200s or a redirect to https://www followed by another, needs fixing.

Mistakes that show up after the switch

The redirect is usually the easy part. What goes wrong is everything that still carries the old hostname.

• Canonical tags from the CMS: WordPress builds canonicals from the Site Address setting. If that still says www while the server redirects to the bare domain, every page declares a canonical that redirects. Google sees conflicting signals and may keep the old version longer.
• The XML sitemap. Sitemap plugins cache aggressively. Open /sitemap.xml after the switch and check the hostnames by eye.
• Hardcoded absolute links. Old posts, footer menus and email templates often contain full URLs. They work through the redirect, but each click costs a hop and each crawl confirms the old host. A database search and replace fixes most of them.
• Third-party settings: analytics, consent tools and payment providers sometimes have the allowed hostname configured. A payment callback to the wrong host can fail silently.
• Cookies. Users logged in on www won’t be logged in on the bare domain. Expect a few support questions on launch day.

None of these hurt rankings for long. They just slow down the moment where Google and your reports show only one hostname.

Do you need Search Console’s Change of Address?

No. Google says explicitly that the tool is not for moving between www and non-www on the same domain. Redirects and canonical tags are enough. The tool exists for real domain changes, as explained in the Change of Address guide. If you’re also moving from http to https at the same time, the HTTPS migration checklist covers that part, and the 301 redirect guide has more server examples.

The same logic applies one level up when you own several names: if example.co.uk and example.com both show the site, that’s the www problem across domains, handled in multiple domains on one website.

Short domains make the choice easier

The shorter the bare domain, the more natural non-www feels on a business card. If you’re still choosing a name, a short .com or .io domain works in either form. See what’s still free with the domain search, then set the canonical hostname before the first page goes live, which is the cheapest moment to decide.

Step by step

1. Pick the canonical hostnameChoose www or non-www based on DNS, CDN and cookie needs, and write the decision down.
2. Make sure both hostnames resolve and have certificatesCreate DNS records for both and cover both names in the TLS certificate, or the redirect fails for https visitors.
3. Add a 301 from the other hostnameConfigure nginx, Apache or a Cloudflare Redirect Rule so every path on the non-canonical host redirects in one hop.
4. Align internal signalsUse the canonical hostname in internal links, rel=canonical tags, hreflang and the XML sitemap.
5. Test all four combinationsRequest http and https for both hostnames with curl and confirm each ends on the canonical URL after at most one redirect.