Check website

www vs non-www: pick one and redirect the other

·4 min read

In the www vs non-www debate, neither version ranks better. Google treats https://www.example.com and https://example.com as two URLs that can serve the same page, asks you to pick one as canonical and to redirect the rest. The choice only matters for cookies and DNS, so pick based on those, send every other version to your pick with one 301, and make every URL you publish use the same host.

Does www vs non-www matter for SEO?

No. Google's guide to consolidating duplicate URLs lists host variants among the ways one page can be reached and tells you to pick one of those URLs as the canonical. It states no preference for either host.

What does hurt is serving both. If example.com and www.example.com both return 200 for every page, you have two copies of the site. Google then picks the canonical for you, and links and shares keep pointing at both. Any choice you enforce beats no choice.

The real technical differences between www and non-www

There are two, and both are about what lives on your subdomains.

www (www.example.com) Non-www (example.com)
DNS A plain CNAME to your host or CDN works A CNAME is not allowed at the zone apex, so you need A/AAAA records or a provider's flattening feature
Cookies scoped to the whole domain Can stay on www and skip other subdomains Domain=example.com reaches every subdomain
Looks Longer Shorter

DNS at the apex. RFC 1034 says that when a CNAME record exists at a name, "no other data should be present" there (section 3.6.2). The apex of a zone must hold the zone's SOA and NS records (section 4.2.1), so a standard CNAME cannot sit on example.com. Hosting platforms that hand you a hostname to CNAME to work cleanly on www. On the bare domain you depend on your DNS provider to fake it. Cloudflare, for example, flattens a CNAME at the apex by resolving it and returning the final IP address. Most DNS providers now offer something similar.

Cookie scope. MDN's Set-Cookie reference says a cookie without a Domain attribute goes back only to the host that set it, and a cookie with Domain set reaches that domain and all its subdomains. So a non-www site is only a problem if you set Domain=example.com, for example to share a login with app.example.com. Then every request to static.example.com or docs.example.com carries those cookies too. On www you can share cookies between www and nothing else.

If you have no subdomain plans, stay on whichever host you already have. Moving costs more than either difference is worth.

How to redirect www to non-www, plus HTTP to HTTPS

Send each of the other three versions straight to the final URL in one 301 or 308. A request for http://www.example.com/pricing should land on https://example.com/pricing without stopping at https://www.example.com/pricing first. Two separate rules, one for HTTPS and one for the host, are how most sites end up with a redirect chain on every old link.

In nginx, with non-www as the canonical host:

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/ssl/example.com.pem;
    ssl_certificate_key /etc/ssl/example.com.key;
    return 301 https://example.com$request_uri;
}

Your main server block for example.com on 443 serves the site. Keep $request_uri so paths and query strings survive. The www host still needs a valid certificate, because the browser checks it before it ever sees your 301.

One exception to the single hop. If you plan to submit the domain to the HSTS preload list, hstspreload.org requires an HTTP to HTTPS redirect on the same host first. So http://www.example.com goes to https://www.example.com, then to https://example.com. Two hops is fine. Google's crawlers follow up to 10 redirect hops, per its HTTP status code documentation.

Use a permanent status. A 302 between hosts tells Google the move is temporary. The 301 vs 302 guide covers when each applies. If the redirect loops, your CDN and origin probably disagree about HTTPS, which the ERR_TOO_MANY_REDIRECTS post walks through.

Google calls redirects a strong canonical signal, sitemap entries a weak one, and asks you to link to the canonical URL rather than a duplicate.

  1. Make every rel="canonical" tag use the chosen host and https. See the canonical tag guide for the rest of the rules.
  2. List only canonical-host URLs in your XML sitemap and in the Sitemap: line of robots.txt.
  3. Fix absolute internal links, menus and footers. A hardcoded https://www. link on a non-www site means every click costs a redirect.
  4. Update og:url, hreflang tags and any JSON-LD url fields.
  5. Set the site URL in your CMS to the chosen host, so new content stops generating the old one.

Check your www and HTTPS redirects

The Redirect Chain & HTTP Header Checker requests the HTTP and HTTPS versions of both your bare domain and www and reports whether all four end at one URL. It flags HTTP that never upgrades to HTTPS, apex and www both serving pages, and versions that land on different origins, and it looks up A and AAAA records for both hosts.

It also follows the URL you enter hop by hop, up to 10 redirects. It shows each hop's status code, flags chains of two or more redirects, temporary redirects that change host, HTTPS sent back to HTTP and missing HSTS, and suggests the server rule to change. A run costs 10 credits. It reads HTTP redirects only, so JavaScript and meta refresh redirects past the first document are out of scope, and it does not read your canonical tags or sitemap.

Keep reading