www vs non-www: Choosing One Host and Redirecting the Rest

In this article
- www vs non-www: does the choice affect rankings?
- How do you set up a www redirect on NGINX in a single hop?
- Which signals must point to the canonical host?
- Why must the certificate and hotlink rules cover both names?
- What do domain variants mean in Search Console during a move?
- How do you verify the cleanup across several domains?
- FAQ
www vs non-www: neither version ranks better. So pick one host per site and send the other to it with a 301. If you own several domains where both hostnames answer, and a cleanup or a domain move is coming up, this one call removes most of the duplication.
www vs non-www: does the choice affect rankings?
No. Neither hostname has a ranking advantage. The harm comes from both answering with the same content: two hosts serving identical pages are duplicate URLs, and duplicates split incoming links and crawl attention. So the real question is which version costs you less to keep.
Choose on practical grounds. Which variant already holds the backlinks and indexed URLs? How are cookies and subdomains used? What DNS setup does your provider allow on the apex (the bare domain)? Then, the part people skip in my opinion, apply the same decision rule to every domain you own.
How do you set up a www redirect on NGINX in a single hop?
Use dedicated server blocks for every non-canonical combination, each returning a 301 straight to the final https canonical host with $request_uri appended. That variable carries the path and the query string, so deep URLs and tracked campaign addresses land where they should.
- Catch plain http on both names in one block.
- Catch https on the secondary name in another.
- Send each of them directly to the final URL, protocol and host included.
- Keep exactly one block that serves content, on the chosen hostname over https.
The classic mistake? Stacking rules. http goes to https first, and only then does the non-www to www 301 (or the reverse) fire. Combine both into one jump, because removing extra redirect hops saves a round trip for visitors and crawlers alike. Line the host rule up with slash handling too, since trailing slash rules on NGINX can quietly add a second redirect. And if an NGINX reverse proxy with EU or USA IPs, such as Jalvo, sits in front of your existing hosting, the redirect is still configured on your own origin.
Which signals must point to the canonical host?
All of them. The redirect, rel=canonical, the sitemap and internal links have to name the same hostname. A 301 is the strongest hint, but older templates often keep the previous address.
- rel=canonical in the head, written with the chosen host and https.
- The sitemap, listing only that version.
- Internal links and navigation, including hardcoded ones in footers and widgets.
- hreflang annotations and structured data URLs.
- The site address setting in your CMS.
Google describes the link element in its guidance on consolidating duplicate URLs: it goes into the head of duplicate pages and points to the canonical page. Mixed signals (say, a canonical naming one host while the redirect targets the other) leave the choice to Google.
Why must the certificate and hotlink rules cover both names?
Because the secondary hostname still receives HTTPS requests. The TLS handshake happens before the 301, so a mismatched certificate blocks the redirect with a browser warning, and an old link to that variant becomes a dead end.
Google’s duplicate URL guidance is explicit: the certificate must match the complete site URL or be a wildcard usable for multiple subdomains. In practice: issue one certificate listing both names and make sure renewal keeps covering them. Hotlink protection needs the same care. Keep valid referers for both hosts in the list, otherwise image requests get rejected during and after the switch.
What do domain variants mean in Search Console during a move?
A switch between www and non-www on the same domain needs no Change of Address. A move to a different domain does. According to Google’s site move guide, the tool is only for going from one domain or subdomain to another, not for HTTP to HTTPS moves, host switches within a domain or path changes. The June 17, 2026 update of that page adds a detail on Change of Address domain variants: for a domain migration, submit the request for all verified variants of the old domain, subdomains and www/non-www included.
If you own several domains, verify every variant of the old domain before the move, or use a Domain property. Check the redirects from the old site too, since Google notes that people frequently point them at wrong, non-existent URLs.
How do you verify the cleanup across several domains?
Every variant of every domain should return exactly one 301 to the same final URL, and that URL should answer 200. Run an identical short check per domain: the four host and protocol combinations on the homepage, then on a deep URL with a query string. Afterwards crawl each site to find internal links and canonicals still naming the old host.
In www vs non-www the choice matters less than consistency. One host, one hop, matching signals, both names on the certificate. That is what keeps each domain clean, whichever prefix you settled on.
FAQ
Is www or non-www better for SEO?
Neither. The gain comes from consistency: one version serving content and a permanent redirect from the other.
Do I need the Change of Address tool when switching from non-www to www?
No, not when the domain stays the same. The tool applies when you move to a different domain or subdomain, and then you submit it for all verified variants of the old domain.
Can I use a 302 instead of a 301 for the host redirect?
Permanent choice, permanent redirect. A temporary one suggests the old address may return, which works against consolidation. Keep the rule in place indefinitely, because old links to the secondary name do not disappear.


