WWW vs Non-WWW: Fix SSL Warnings and Duplicate URLs

Your site loads fine at example.com but throws an SSL warning at www.example.com — or Google Search Console is complaining that you have two versions of the same homepage indexed. This is the www vs non-www problem, and it trips up almost every site owner at least once. Here's how to pick a canonical version and make the redirect actually stick.

Symptom

You'll usually notice one of these:

• Visiting www.yoursite.com shows a browser SSL warning, but yoursite.com is fine (or vice versa).
• Both www. and non-www. versions load — with no redirect between them — so search engines see duplicate pages.
• Google Search Console shows split impressions/clicks between the two hostnames, or flags "duplicate, without user-selected canonical."
• Login sessions or WooCommerce carts get dropped when a visitor lands on the "wrong" version and cookies don't carry over.
• Social share previews or backlinks point to one version, but internal links use the other, and analytics numbers look fragmented across two properties.

Why This Happens

The root cause is almost always that www and non-www are, technically, two different hostnames. DNS doesn't know they're "the same site" — that's a decision only your web server or CMS enforces. If nobody's told it to, both resolve and both serve content independently.

A few specific ways this bites people:

1. DNS is set up for both, but no redirect exists. You added an A record for the apex domain and a CNAME for www, both pointing at your server, and stopped there.
2. The SSL certificate only covers one hostname. A single-domain certificate for yoursite.com doesn't cover www.yoursite.com unless you requested it as a Subject Alternative Name (SAN) or used a wildcard. AutoSSL in cPanel normally requests both automatically, but if the www subdomain was added later, or DCV failed for it, you can end up with a cert that's missing one name.
3. WordPress's Site Address doesn't match what visitors type. WordPress redirects based on the siteurl/home values in the database (or wp-config.php constants), not DNS. If those are set to the non-www version, WordPress will 301 www traffic to non-www — but only once the page actually loads over a valid connection. A broken cert on www stops that redirect from ever happening because the browser blocks the connection first.
4. The redirect is set up as a 302 instead of a 301, so search engines never fully consolidate ranking signals onto one URL.
5. A redirect loop. Someone adds "redirect www to non-www" at the .htaccess level and "redirect non-www to www" at the Cloudflare or CDN level, and the two fight each other.

The Fix

1. Decide on one canonical version

There's no SEO advantage either way — pick based on what's already indexed or what looks cleaner in your branding, then commit. Check Search Console > Settings to see which version currently has more indexed pages if you're unsure.

2. Make sure DNS resolves both

In cPanel's Zone Editor (or your DNS provider), confirm you have:

yoursite.com.       A     203.0.113.10
www.yoursite.com.   CNAME yoursite.com.

Both need to resolve before you can redirect between them — you can't redirect traffic that never reaches your server.

3. Get an SSL certificate that covers both names

In WHM/cPanel, open SSL/TLS Status and check whether AutoSSL has issued a certificate covering both yoursite.com AND www.yoursite.com. If www is missing:

• Confirm the www subdomain is listed under that account in WHM (it should be, by default, unless it was explicitly removed).
• Re-run AutoSSL: WHM > SSL/TLS > Manage AutoSSL > Run AutoSSL for the account.
• If domain control validation (DCV) is failing for www, it's usually because the www CNAME/A record doesn't point at the same server AutoSSL is validating from — fix the DNS record from step 2 first, then re-run.

If you're on a VPS running Certbot manually, request both names in one certificate:

sudo certbot --nginx -d yoursite.com -d www.yoursite.com

4. Set the canonical URL in WordPress

Go to Settings > General and set both "WordPress Address (URL)" and "Site Address (URL)" to your chosen canonical version, e.g. https://yoursite.com (no www). If wp-admin is unreachable because of a redirect loop, set it directly in wp-config.php instead, above the "That's all, stop editing!" line:

define('WP_HOME', 'https://yoursite.com');
define('WP_SITEURL', 'https://yoursite.com');

5. Force the redirect at the server level (don't rely on WordPress alone)

WordPress's own redirect only fires after PHP loads — better to redirect at the web server so it's instant and works even if WordPress breaks. For Apache/LiteSpeed, add this near the top of .htaccess, before the WordPress block:

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

Flip the condition if you're standardizing on www instead:

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

On Nginx, put it in the server block:

server {
    listen 443 ssl;
    server_name www.yoursite.com;
    return 301 https://yoursite.com$request_uri;
}

6. If you're behind Cloudflare

Turn off any "www rewrite" Page Rule or Bulk Redirect you don't need, and let the origin server handle the redirect from step 5. Running redirects in two places (Cloudflare and .htaccess) is the most common cause of redirect loops — pick one layer and remove the rule from the other.

Verify It

Check both directions resolve to a single 301 and land on your canonical URL, with a valid certificate on both hostnames:

curl -Iv https://www.yoursite.com
curl -Iv https://yoursite.com

You want to see HTTP/1.1 301 Moved Permanently and a Location: header pointing at your chosen version, with no certificate errors in the SSL certificate verify ok line. Then update Search Console's canonical settings and your XML sitemap so both list the same hostname.

Prevention

• Whenever you add a domain in cPanel, immediately check that both the apex and www resolve and are covered by SSL — don't wait for a customer complaint.
• Keep the redirect rule in exactly one place (server config OR CDN, never both) and document which one it lives in.
• After any DNS migration or nameserver change, re-run AutoSSL and re-test both hostnames before calling the migration done.
• Set WP_HOME/WP_SITEURL as constants in wp-config.php rather than relying solely on the database — it survives database restores and staging clones cleanly.