www vs non-www: Why Google Needs One Version of Your Site

By Ugur Saritepe · July 9, 2026

The www vs non-www debate has a boring answer: neither ranks better, and Google has no preference. What actually costs you traffic is running both at once. To Google, http://yoursite.com, https://yoursite.com, and their two www twins are four separate URLs, and every one that answers without a redirect is a live duplicate copy of your whole site.

The 30-second self-diagnosis

Run this in a terminal with your own domain. It asks all four versions of your homepage how they answer:

for u in "http://yourdomain.com/" "http://www.yourdomain.com/" \
  "https://yourdomain.com/" "https://www.yourdomain.com/"; do
  curl -sI -o /dev/null --max-time 10 \
    -w "%{http_code}  $u  ->  %{redirect_url}\n" "$u"
done

Here is the real output for traffictriage.com, run while writing this in July 2026:

308  http://traffictriage.com/      ->  https://traffictriage.com/
308  http://www.traffictriage.com/  ->  https://www.traffictriage.com/
200  https://traffictriage.com/     ->
308  https://www.traffictriage.com/ ->  https://traffictriage.com/

That is the healthy shape: exactly one 200, and every other version answering a permanent redirect (301 or 308) toward it. Anything else sorts you into one of four failure modes:

• Two or more lines show 200. Multiple live copies, the serious one. Go to cause 1.
• An SSL error instead of a status code. A certificate problem on one variant. Go to cause 2.
• A 302 or 307 anywhere. A temporary redirect doing a permanent job. Go to cause 3.
• A redirect that points at another redirect. A chain. Go to cause 4.

Why Google needs one version

Google indexes URLs, not sites. When the same page answers 200 at four addresses, Google's canonicalization system has to guess which one is the real page, fold the rest into it, and it makes that call per URL. A permanent redirect removes the guesswork: it is the strongest signal you can send about which version counts, stronger than the canonical tag hint on its own.

Duplicates also split your signals while the guessing happens. Some sites link to your www version, some to the bare domain; if both are live, each copy collects links and crawls separately until Google decides they are the same. And every page on your site existing at four addresses means crawlers can burn four requests to learn one page.

Honest framing: a duplicate-version setup rarely sinks an established site by itself. But on a new site with a handful of links and a weak crawl budget, ambiguity is expensive, and it is one of the first things worth ruling out. It is Check #5 of the eight in our Triage Report, and the rest of this Checks Explained series covers the other seven.

The four ways the check fails

1. Multiple live copies with no redirect

Two or more variants answer 200 and never redirect. This is the failure the check scores Critical, and the most common one we see: typically https://yourdomain.com and https://www.yourdomain.com both serving the full site as equals. It has no visible symptom. The site works either way in a browser, which is exactly why it survives for years.

Fix: pick one canonical version and permanently redirect the other three to it, each in a single hop. Which one to pick: whichever Google already indexes. Search site:yourdomain.com and keep the host you see in the results. On managed platforms this is a setting, not code: on Vercel, assign both domains to the project and mark one as primary, and the platform answers 308 for the rest (that is where our own output above comes from). On Apache shared hosting, one .htaccess rule closes scheme and host in a single hop:

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

Google's own redirect documentation recommends exactly this: a permanent server-side redirect is, in their words, the best way to ensure that Google Search and people are directed to the correct page.

2. An SSL certificate error on one variant

The usual shape: the certificate covers yourdomain.com but nobody added www.yourdomain.com to it, or the reverse. Visitors who type the uncovered variant get a full-page browser warning instead of your site. Worse, that variant cannot even redirect itself to safety: the certificate check happens before any HTTP answer is sent, so a redirect rule cannot save you. The fix has to happen at the certificate.

30-second check:

curl -vI https://www.yourdomain.com/ 2>&1 | grep -iE "verify ok|alternative"

Good: SSL certificate verify ok. Bad: SSL: no alternative certificate subject name matches target host name. We verified both outputs with curl 8.x while writing this.

Fix:reissue the certificate with both hostnames on it. Let's Encrypt certificates list every hostname explicitly, so request the apex and the www name together. On managed hosts, adding the missing hostname in the domain panel usually triggers a certificate that covers it. While you are here: serving HTTPS at all is table stakes. Google announced HTTPS as a ranking signal in 2014, a lightweight one, but browsers marking your http version "Not secure" costs you visitors regardless of rankings.

3. A temporary redirect doing a permanent job

A 302 or 307 tells Google the move is temporary. Per Google's redirect documentation, Googlebot follows a temporary redirect, but the indexing pipeline does not take it as a signal that the target should be canonical. In practice that means Google may keep the old URL in the index indefinitely, because you told it the old URL is coming back.

The PageRank part is a myth worth retiring: Google confirmed in 2016 that no 3xx redirect loses PageRank. The cost of a wrong redirect type is not lost authority, it is canonical ambiguity. The fix is also the cheapest in this article: change the status code in your redirect config from 302 to 301, or 307 to 308. The two permanent codes are equivalent for search; 308 additionally preserves the request method, which matters for forms, not for SEO.

This failure is quiet enough that I shipped it myself. While writing this article I ran the four-variant loop on my own portfolio site, ugursaritepe.com, and found the apex answering a 307 to the www version. As of July 2026 it had been doing that the whole time. The site worked, nothing looked broken, and no browser will ever tell you.

4. A redirect chain to the canonical URL

A chain is a redirect that lands on another redirect: http://www.yourdomain.com hops to https://www.yourdomain.com, which hops again to https://yourdomain.com. Two hops instead of one. Google's crawlers follow up to 10 redirect hops, so a two-hop chain will not break indexing. The cost is smaller and constant: every hop is an extra round trip for every visitor on the chained URL, and every crawl of it spends two requests to reach one page.

Where to spend the effort: on the URLs people actually reach. Full disclosure, the two-hop example above is our own site: http://www.traffictriage.com/ takes two 308s to reach the apex, because the edge closes the scheme and the host in separate steps. That corner variant gets close to zero real traffic, which is why the Triage Report measures the chain from the URL you submit, the address you actually publish, and scores chains as Monitor rather than Critical. What must never be chained: the URLs in your sitemap and your internal links. Point both at the final form, same scheme, same host, same trailing-slash style. Framework-level settings can stack extra hops on top of the host-level ones; cause 5 in our Vercel triage guide covers the Next.js version of that trap.

How to confirm the fix worked

Re-run the four-variant loop from the top of this article. You are looking for exactly one 200 and three permanent redirects, each pointing directly at the canonical URL. Then trace the variant you fixed and count the hops:

curl -sIL https://www.yourdomain.com/ | grep -iE "^HTTP|^location"

Good: one redirect status, one location line, then 200. Bad: two or more redirect statuses before the final 200. Once HTTPS has been stable for a while, you can add an HSTS header (Strict-Transport-Security) so returning browsers skip the http hop entirely. There is nothing to submit to Google for this fix: the duplicates consolidate on their own as pages get recrawled, typically over days to a few weeks. A site:yourdomain.com search a few weeks later should show every result on one host.

From experience: nearly 1 in 3 sites fails this check

Of the 28 sites we ran through the Triage engine between July 4 and July 9, 2026, eight failed this check at Critical: five were serving multiple live copies with no redirect between them, and three had an SSL certificate error on an https variant. Three more earned a Monitor flag, two of those for temporary redirects. That is 11 of 28 with a version problem, on a check most owners have never heard of.

The pattern that sticks with me is how invisible the serious case is. Every one of the five multiple-copy sites rendered perfectly in a browser on either address; the owners had nothing to notice. Add my own 307 from cause 3 and the lesson is the same either way: you do not find this class of problem by looking at your site. You find it by asking all four versions what they answer.

FAQ

Is www or non-www better for SEO?

Neither. Google has no preference and ranks both the same. What matters is that exactly one version is live and the other answers a permanent redirect to it. Pick whichever version is already indexed and stop thinking about it.

Do 301 redirects lose PageRank?

No. Google confirmed in 2016 that no 3xx redirect loses PageRank, and that includes 301, 302, 307, and 308. The real cost of a wrong redirect is canonical ambiguity: a temporary redirect tells Google to keep the old URL indexed.

Can I use a canonical tag instead of a redirect?

Not for site versions. A canonical tag is a hint Google can ignore; a redirect is enforcement. With only a canonical tag, both copies stay live, users and links keep landing on both, and you depend on Google guessing right. Use redirects to close duplicate versions, and canonical tags for pages that genuinely must stay live at two URLs.

Should I switch an established site from www to non-www?

No, unless you have a reason unrelated to rankings. Switching buys zero SEO benefit and costs weeks of recrawling while Google re-consolidates every page onto the new host. If your site is already consistent on one version, leave it alone.