SSL & HTTPS Guides

WWW vs Non-WWW: SSL Certificates and HTTPS Consistency

Learn how www and non-www hostnames affect SSL certificates, HTTPS redirects, canonical URLs and SEO consistency.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 8 min read Beginner

Introduction

The root domain and the www version are different hostnames. For example, example.com and www.example.com may look like the same website to users, but browsers, certificates, DNS and redirects treat them separately.

A good HTTPS setup should decide which version is canonical, make sure SSL covers the required hostnames, and redirect all variants consistently. Without this, visitors may see certificate warnings, search engines may index duplicate URLs, and redirects may become messy.

Quick answer

Quick answer

Choose either www or non-www as the canonical hostname. Make sure your SSL certificate covers both example.com and www.example.com if both can be visited, then redirect the non-canonical version to the canonical HTTPS URL with a clean 301 redirect.

WWW vs non-WWW

www and non-www are separate hostnames.

Root / non-www 
example.com
WWW 
www.example.com

They can point to the same website, but DNS, SSL certificates, redirects and cookies can treat them differently.

For users, both may look like the same site. For technical configuration, they must be handled intentionally.

Which version to choose

Both www and non-www can work well. The important part is consistency.

Use non-www if

  • You want shorter URLs
  • The site is simple
  • Branding prefers the root domain
  • You do not need special www-specific routing

Use www if

  • Your infrastructure expects www
  • You use certain CDN or hosting setups
  • You want clearer hostname separation
  • Your legacy SEO history is already on www

There is no SEO magic in either choice. The problem is not choosing www or non-www; the problem is allowing both to behave inconsistently.

SSL coverage

If visitors can open both root and www, the SSL certificate should cover both names.

Recommended certificate coverage 
example.com
www.example.com

A certificate for example.com does not always cover www.example.com. A certificate for www.example.com does not always cover example.com. Always check the SAN list.

Hostname mismatch example 
Certificate covers:
example.com

Visitor opens:
https://www.example.com

Result:
Possible hostname mismatch warning.

Redirect strategy

After choosing a canonical hostname, redirect all other variants to the final HTTPS version.

Non-www canonical example 
http://example.com → https://example.com
http://www.example.com → https://example.com
https://www.example.com → https://example.com
WWW canonical example 
http://example.com → https://www.example.com
https://example.com → https://www.example.com
http://www.example.com → https://www.example.com

Avoid redirect chains. Ideally, each old variant should go directly to the final canonical HTTPS URL.

Check redirects 
curl -I http://example.com
curl -I https://example.com
curl -I http://www.example.com
curl -I https://www.example.com
Check certificate 
openssl s_client -connect www.example.com:443 -servername www.example.com

These examples are illustrative. Replace example.com with your real domain and choose one canonical hostname.

DNS setup

Root and www DNS records are configured separately.

Common setup 
Root:
example.com A 192.0.2.10

WWW:
www.example.com CNAME example.com

or:

www.example.com A 192.0.2.10

The exact setup depends on your hosting, CDN and DNS provider. The goal is that both hostnames reach the intended endpoint before redirects are applied.

Why this matters

Why this matters

Root/www consistency matters because users, search engines and browsers should see one clear version of the website. If both versions work separately, you can create duplicate URLs, inconsistent canonical tags, analytics fragmentation, redirect chains and SSL mismatch errors.

This is especially important after migrations, new SSL installation, CDN setup, WordPress URL changes or domain reconfiguration.

How to check consistency

Use SSL Checker, Website Status Checker and HTTP Header Checker to test both hostnames.

When checking consistency, review

These seven checks help confirm root and www behave consistently.

SSL certificate

Confirm both root and www are covered if both can be visited.

HTTP root

Check where http://example.com redirects.

HTTPS root

Check whether https://example.com loads or redirects correctly.

HTTP www

Check where http://www.example.com redirects.

HTTPS www

Check whether https://www.example.com loads or redirects correctly.

Final canonical URL

Confirm all variants end at the same preferred HTTPS hostname.

Redirect chain

Confirm there are no unnecessary hops.

Check root and www HTTPS

Use Website Status Checker and SSL Checker to verify redirects, certificate coverage and final URL consistency.

Run Website Status Check →

Common problems

SSL covers root but not www

High

Visitors opening www.example.com may see a certificate mismatch warning.

Next step: Reissue the certificate with both example.com and www.example.com, or redirect correctly with valid coverage.

SSL covers www but not root

High

Visitors opening example.com may see a certificate mismatch warning.

Next step: Include the root domain in the certificate or fix hostname strategy.

Both versions load separately

Medium

example.com and www.example.com show the same content without canonical redirects.

Next step: Choose one canonical version and 301 redirect the other.

Redirect chain is too long

Medium

HTTP root may redirect to HTTP www, then HTTPS www, then another URL.

Next step: Simplify redirects so each variant goes directly to the final canonical URL.

Redirect loop between root and www

High

Conflicting rules send visitors back and forth between hostnames.

Next step: Review hosting, CDN, server and application redirect rules.

WordPress URLs conflict

Medium

WordPress Address and Site Address may not match the intended canonical hostname.

Next step: Update WordPress URLs and replace old internal links if needed.

CDN uses different hostname behavior

Medium

The CDN may redirect or serve SSL differently from the origin server.

Next step: Review CDN edge certificate, page rules and origin redirect settings.

Canonical tags do not match redirects

Low

Pages redirect to one hostname but canonical tags point to another.

Next step: Update canonical URLs to the final HTTPS hostname.

How to fix consistency

  1. Step 1: Choose the canonical hostname

    Decide whether the final website should use https://example.com or https://www.example.com.

  2. Step 2: Check SSL coverage

    Make sure the certificate covers both root and www if users can request both.

  3. Step 3: Check DNS

    Confirm both root and www point to the intended hosting, CDN or proxy endpoint.

  4. Step 4: Set clean 301 redirects

    Redirect every non-canonical variant directly to the final HTTPS URL.

  5. Step 5: Avoid duplicate redirect systems

    Do not create conflicting redirects in hosting panel, CDN, .htaccess, Nginx and WordPress at the same time.

  6. Step 6: Update application settings

    Update WordPress, CMS, canonical tags, sitemap URLs and internal links.

  7. Step 7: Test all variants

    Check HTTP and HTTPS versions of both root and www from outside the server.

WordPress and CMS

For WordPress and many CMS platforms, root/www consistency also depends on application settings.

  • WordPress Address URL
  • Site Address URL
  • Canonical tags
  • Sitemap URLs
  • Internal links
  • Media URLs
  • Plugin redirect settings
  • Cache and CDN plugin settings

If WordPress is set to www but the server redirects to non-www, redirect loops or login issues can happen.

SEO checklist

Confirm the following for a consistent root/www HTTPS setup.

  • One canonical hostname is selected
  • All variants 301 redirect to the canonical HTTPS URL
  • Canonical tags use the same hostname
  • Sitemap URLs use the same hostname
  • Internal links use HTTPS canonical URLs
  • Search Console property is checked
  • No redirect chains or loops exist
  • Old backlinks still resolve correctly

Search engines can handle either www or non-www, but consistency matters.

CDN and proxy

If a CDN or reverse proxy is used, root/www behavior may be controlled at the CDN edge, origin server or application level.

  • Root hostname configured in CDN
  • WWW hostname configured in CDN
  • Edge certificate covers both names
  • Origin certificate covers required names
  • CDN redirect rules
  • Origin redirect rules
  • Forwarded protocol headers
  • Cache rules

Many root/www problems happen when CDN and origin redirects do not agree.

Frequently asked questions

Is www better than non-www?

Neither is universally better. Choose one and keep redirects, SSL and canonical URLs consistent.

Does SSL for example.com cover www.example.com?

Only if www.example.com is included in the certificate SAN list.

Should both www and non-www work?

Both should resolve safely, but one should redirect to the canonical version.

Should I use 301 redirects?

Yes, for a permanent root/www and HTTP/HTTPS canonical setup.

Can inconsistent www settings affect SEO?

Yes. Inconsistent hostnames can create duplicate URLs, redirect chains and canonical confusion.

Why do I get a redirect loop between www and non-www?

Conflicting rules in hosting, CDN, web server or CMS may be forcing opposite hostnames.

Should my sitemap use www or non-www?

Use the same canonical HTTPS hostname that your redirects use.

Use these free tools to verify your configuration after applying changes.

Website Status Checker SSL Checker HTTP Header Checker DNS Lookup Domain Health Checker
Enforcing HTTPS with HTTP to HTTPS Redirects 8 min read Fixing Domain Mismatch Errors in SSL Certificates 8 min read How to Check Your SSL Certificate 8 min read Migrating to HTTPS: SEO and Performance Considerations 8 min read Mixed Content Issues: How to Find and Fix Them 8 min read
Browse all SSL & HTTPS guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.