Should I use www or non-www for my website?

If your site answers on both https://example.com and https://www.example.com, you have the classic www vs non-www problem: two hostnames serving one set of pages. Google can treat each hostname as a distinct URL, so links, shares, and ranking signals can end up split across two versions of every page instead of consolidating on one. The fix is to choose a single canonical host, redirect the other, and reinforce the choice with a canonical link.

Why this matters

Google's canonicalisation guidance is explicit that identical or very similar content can be reached through many URLs, and that Google must pick one URL to show in search results. When you declare no preference, Google chooses for you, and that choice may not be the hostname you want people to see or share. The bigger risk is competition: because the www and bare-host versions are different URLs, an external link might point at www while an internal link or a directory listing points at the bare host. Authority that should accumulate on one page gets divided between two, which is exactly the "split rankings" scenario. Duplicate crawling compounds the problem. Googlebot spends requests fetching two copies of the same page rather than discovering new or updated content, which is a poor use of crawl budget. The decision also affects how cleanly your analytics consolidate: session data, conversions, and referrers recorded against two hostnames are harder to reason about than data on a single one. None of this requires you to guess the "right" answer. The www vs non-www choice is a preference, not a technical mandate, but whichever you pick has to be enforced consistently across redirects, canonical tags, sitemaps, and internal links.

How to fix it

Pick one hostname as canonical and commit to it everywhere. Google lists redirects as the strongest signal that a target URL should be canonical, rel="canonical" link annotations as the next strongest, and sitemap inclusion as a weaker signal, and it notes these methods stack. So the reliable recipe is: add a permanent server-side 301 redirect from the hostname you are dropping to the hostname you are keeping, then add a self-referential rel="canonical" link element on every page that points at the chosen host. Use an absolute URL in the canonical element, because Google recommends absolute paths over relative ones. Do not split the signal by declaring one hostname in a redirect and a different hostname in the canonical tag or sitemap. Finally, make sure your TLS certificate actually covers the host you keep (or is a wildcard certificate for the domain), point all internal links and your XML sitemap at the canonical host, and make sure any hreflang annotations reference the canonical host too.

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

# nginx: 301 from bare host to www
server {
  server_name example.com;
  return 301 https://www.example.com$request_uri;
}

<!-- in the <head> of every page (self-referential canonical) -->
<link rel="canonical" href="https://www.example.com/">

How to verify the fix

Check the redirect first, using a single request so you can see the status code and the Location header. A correct setup returns one 301 Moved Permanently that points at the canonical host, rather than a 200, a redirect loop, or a 302. Then load the canonical host and view the page source (or the Elements panel in browser DevTools) to confirm the self-referential canonical element is present and matches the hostname you redirect to. If both hostnames still return 200 OK with the same content, the redirect is not active yet.

# show status line and Location header, one at a time
curl -sI https://example.com | findstr /I "HTTP Location"
curl -sI https://www.example.com | findstr /I "HTTP"

# expect: HTTP/1.1 301 and Location: https://www.example.com/

Related issues