WWW vs Non-WWW: Set Up the Right Canonical Redirect

Half your visitors type "yoursite.com" and the other half type "www.yoursite.com" out of habit, and both versions load your site — but as far as Google, your SSL certificate, and your analytics are concerned, those are two different addresses. If you haven't picked one and forced everything else to redirect to it, you're quietly splitting SEO value, sometimes serving broken padlocks, and occasionally landing customers in an infinite redirect loop. Here's how to fix it properly, whether you're on shared cPanel hosting or a VPS running Nginx.

Symptom

A few ways this shows up in real support tickets:

• Both https://example.com and https://www.example.com load fine, but Google Search Console flags one as a "duplicate, Google chose different canonical."
• Your SSL certificate covers www.example.com but not the bare domain (or vice versa), so one version throws a name-mismatch warning.
• Analytics traffic is split roughly in half across two "sites" that are really one.
• After adding a redirect rule, the browser shows ERR_TOO_MANY_REDIRECTS — usually because Cloudflare and your origin server are both trying to redirect at the same time.
• Internal links, canonical tags, and the WordPress Site Address don't agree on which version is "real."

Cause

By default, most hosting setups happily answer to both hostnames. cPanel's AutoSSL will even issue a certificate covering both example.com and www.example.com in the same SAN cert, which is convenient but also means nothing forces a decision. Without an explicit redirect, search engines index whichever version they crawl first — sometimes both — and split your backlink and ranking signals between them.

The redirect loop case is almost always a chain of well-meaning rules stepping on each other: WordPress redirecting non-www to www at the application layer, Cloudflare's SSL/TLS mode or a page rule redirecting the other way, and an .htaccess rule doing a third thing. Each one thinks it's finishing the job; together they bounce the browser back and forth until it gives up.

Fix

Pick one canonical version — non-www is the more common default today, but either is fine as long as it's consistent everywhere. Then implement the redirect at exactly one layer, not three.

Option 1: cPanel shared hosting (.htaccess)

Open File Manager (or connect via SFTP) and edit the .htaccess in your site's document root. Add this above the WordPress block (the lines between # BEGIN WordPress and # END WordPress):

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

That forces www → non-www. To go the other direction, swap the condition and target:

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

Use R=301, not R=302 — a 301 tells Google this is permanent and to transfer ranking signals, a 302 tells it "just checking, don't bother updating your index."

Option 2: WordPress Site Address settings

Even with the .htaccess rule in place, go to Settings → General in wp-admin and make sure both WordPress Address (URL) and Site Address (URL) use your canonical version (no www, in this example). If they still say www.example.com, WordPress will generate internal links, feeds, and REST API URLs pointing at the non-canonical host, working against the redirect you just set up. If wp-admin is unreachable because of a redirect loop, fix it directly in the database via phpMyAdmin — the two rows are siteurl and home in wp_options.

Option 3: VPS with Nginx

Do it in the server block instead of .htaccess — it's faster and avoids per-request file parsing. In your site's config (typically under /etc/nginx/conf.d/ or /etc/nginx/sites-available/):

server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    # your normal site config here
}

Test with nginx -t before reloading, then systemctl reload nginx.

If you're behind Cloudflare

Pick one place to redirect — either Cloudflare or your origin, never both. In Cloudflare, go to Rules → Redirect Rules and create a rule matching the non-canonical hostname with a 301 to the canonical one. If you do this, remove any equivalent redirect from .htaccess or your Nginx config, or you'll get the classic bounce-back loop where Cloudflare redirects one way and the origin redirects it right back.

Prevention

Frequently Asked Questions

Which should I choose, www or non-www?

Either is fine from an SEO standpoint — Google treats both as legitimate. Non-www is slightly more common in new sites because it's shorter and easier to say out loud, but if your existing backlinks and bookmarks mostly point to the www version, keep that as canonical instead.

Will this redirect break my existing rankings?

No, as long as it's a 301 (permanent) redirect and not a 302. Search engines follow 301s and consolidate ranking signals onto the target URL within a few crawl cycles.

I added the .htaccess rule and now I get ERR_TOO_MANY_REDIRECTS. What happened?

Something else is already redirecting the opposite direction — most often Cloudflare's SSL/TLS mode set to "Flexible" combined with a WordPress force-HTTPS plugin, or a leftover redirect rule from a previous migration. Check Cloudflare's Redirect Rules and Page Rules first, then your WordPress Site Address settings, before adding more rules.

Do I need to update anything in DNS?

Usually no, as long as both example.com (A record) and www.example.com (CNAME or A record) already resolve to your server. The redirect happens after the connection reaches your server or CDN, not at the DNS level.

Does this affect email (MX records) or subdomains?

No. This redirect only applies to the web (HTTP/HTTPS) traffic for those two specific hostnames — it has no effect on MX records, other subdomains, or any DNS record besides how browsers resolve the bare domain versus the www version.