www to non-www redirect (and vice versa)

Why www and non-www need a redirect

From a technical point of view, www.example.com is a subdomain of example.com. They can point to different servers and serve different content. That is why search engines treat https://example.com/page and https://www.example.com/page as two separate URLs.

If both answer with 200 OK, you get:

• Duplicate content: Google has to guess which version is canonical. Usually it guesses right, but you lose control.
• Split signals: backlinks pointing at both variants are consolidated only if Google clusters them correctly.
• Messy analytics: sessions and referrers split across two hostnames, and cookies set on one host are missing on the other.

A permanent 301 or 308 redirect from the non-preferred host to the preferred one fixes this. It passes PageRank and is a strong canonicalization signal.

www or non-www: which should you choose?

For SEO, it does not matter. Google does not prefer one over the other. What matters is that you choose one and stick to it. A few technical points can tip the decision:

Aspect	www.example.com	example.com
DNS	Can be a CNAME, easy to point at a CDN or hosting platform	Apex domain cannot be a normal CNAME; needs A/AAAA records or provider-specific ALIAS/flattening
Cookies	Cookies stay on www and do not leak to other subdomains	Cookies set with a Domain attribute apply to all subdomains, for example static.example.com
Look	Classic, recognisable as a web address in print	Shorter and more modern

If your site already has history, keep the host that Google currently shows in the search results and that most backlinks point to. Switching without a reason only costs you a round of recrawling.

Keep every signal consistent

The redirect is the strongest signal, but it should not be the only one. If your canonical tags say www while your redirect sends users to non-www, you are sending contradictory signals and Google may pick a canonical you did not intend.

• Canonical tags must use the preferred host and HTTPS: <link rel="canonical" href="https://example.com/page">.
• XML sitemaps should only list final URLs that answer with 200, never URLs that redirect.
• Internal links, navigation and hreflang annotations should use the preferred host directly, so no internal click triggers a redirect.
• CMS settings such as the site URL in WordPress must match the preferred host. Otherwise the CMS and your server redirect back and forth, which ends in a loop.
• Search Console: the old "preferred domain" setting no longer exists. Use a domain property, which covers all hosts and protocols, and let redirects and canonicals do the work.

Redirect snippets

All examples below combine the host normalization with HTTPS, so every variant reaches the final URL in one hop. Replace example.com with your domain.

Apache: redirect www to non-www

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

Apache: redirect non-www to www

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

If TLS is terminated at a proxy or load balancer, replace %{HTTPS} off with %{HTTP:X-Forwarded-Proto} !https. More examples are in the .htaccess guide, and the .htaccess generator builds the rules for you.

nginx: redirect www to non-www

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/fullchain.pem;
    ssl_certificate_key /etc/ssl/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/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
    root /var/www/example.com;
}

For the opposite direction, swap the hostnames: the HTTP block and the HTTPS block for example.com return https://www.example.com$request_uri, and the content is served by the www block. Separate server blocks with return are faster and easier to read than if ($host ...) conditions. See the nginx guide or use the nginx generator.

Other platforms

On managed platforms you usually configure this in the dashboard rather than in a config file. In Vercel and Netlify you add both domains and mark one as primary; the platform redirects the other one (see Vercel and Netlify). On Cloudflare you can use a redirect rule. In WordPress, the site address setting determines the preferred host, and WordPress itself redirects the other variant, provided both reach the same installation.

Switching the preferred host on an existing site

Sometimes you have a good reason to change sides, for example because a new hosting platform only supports a CNAME on www. Treat it like a small migration:

1. Update canonical tags, internal links, hreflang and the XML sitemap to the new host first, or at the same time as the redirect.
2. Flip the redirect direction. Check that no old rule still points the other way, or you create a loop.
3. Update existing redirects elsewhere in your config whose targets use the old host, so they do not turn into chains.
4. Keep the redirect permanently. Old links to the previous host will exist for years.

If you use a domain property in Search Console, it already covers both hosts, so your reports continue without interruption while Google processes the switch.

Common pitfalls

• Missing DNS record: if www has no DNS entry at all, the redirect can never run. Both hosts need to resolve to a server that answers.
• Certificate only for one host: a request to https://www.example.com fails with a certificate error before any redirect happens. Your certificate needs both names, or use separate certificates.
• Two separate redirects: one rule for HTTPS, a second one for www, creates a redirect chain for some variants. Combine them as shown above.
• Losing the path: redirecting everything to the home page instead of keeping $request_uri or %{REQUEST_URI} turns deep links into soft 404s.
• Temporary status codes: a 302 works for users but is only a weak canonicalization signal. Use 301 or 308.
• Conflicting layers: CDN, server and CMS each enforce a different host and bounce the request between them. That is a classic cause of ERR_TOO_MANY_REDIRECTS.

Check all four variants

Your setup is correct when all four combinations end at the same URL, each in at most one hop:

Request	Expected (preferred: https://example.com)
http://example.com/page	301 → https://example.com/page
http://www.example.com/page	301 → https://example.com/page
https://www.example.com/page	301 → https://example.com/page
https://example.com/page	200 OK

Test a single URL in the redirect checker, or paste all four variants, including a deep link with a query string, into the bulk checker. If you are also moving from HTTP to HTTPS, read redirect HTTP to HTTPS for HSTS and mixed content.