Using www and non-www domains with an SSL certificate

Deciding whether your website lives at example.com or www.example.com is one of the oldest dilemmas on the web. While it might seem like a trivial preference, the choice carries significant technical and SEO implications once you introduce SSL certificates into the mix. Modern browsers display an explicit “Not Secure” warning for any page lacking a valid HTTPS connection, and if you aren’t careful, managing traffic between your www and non-www variants can inadvertently trigger those warnings.

The challenge lies in the fact that search engines and web browsers treat the www and non-www versions of your domain as entirely separate entities. If both resolve to your server but only one is secured, or if they are not properly linked together, visitors might hit a security error wall before they ever see your homepage.

In this guide, we will walk through the proper way to configure www non-www SSL setups, establish a 301 redirect canonical path, and ensure your visitors—whether they type the prefix or not—arrive safely at a single, encrypted destination.

Understanding www vs non-www and SSL Certificate Coverage

From a DNS perspective, the root domain (example.com) and the www subdomain (www.example.com) are distinct records pointing at your server. To secure both, you cannot rely on a single-factor certificate. You must install an SSL certificate that explicitly covers both hostnames.

The Role of SAN and Let’s Encrypt

Historically, securing multiple hostnames required complex configurations. Today, this is handled using a Subject Alternative Name (SAN) certificate. A SAN allows a single certificate to secure multiple domains or subdomains.

For most small business owners, the easiest way to achieve this is through Let’s Encrypt, which issues free SSL certificates. A standard Let’s Encrypt SAN certificate auto-provisions both the root domain and the www variant by default. By utilizing Let’s Encrypt, you ensure that regardless of which version a user types into their browser, a valid SSL/TLS handshake can be established.

Preventing Mixed Content Warnings and Security Errors

If your non-preferred hostname resolves but lacks SSL coverage, any visitor arriving via HTTPS on that specific variant will be greeted with a browser security error. Furthermore, if traffic is incorrectly forwarded over HTTPS to HTTP content, browsers will block elements on the page, resulting in mixed content warnings. Properly securing both variants is mandatory to establish trust, prevent malicious attacks like SSL stripping, and maintain a professional user experience.

Configuring Permanent 301 Redirects for Canonical Hostnames

Once both variants are secured with an SSL certificates, your next step is to choose a canonical (primary) hostname. To prevent duplicate content SEO penalties, you must implement a permanent 301 redirect from your non-preferred hostname to your canonical preferred hostname.

This is essential for consolidating page ranking signals. Search engines like Google allocate ranking signals (like backlinks) to specific URLs. If users link to both example.com and www.example.com, splitting your traffic means splitting your authority. A 301 redirect consolidates all of that ranking power onto a single domain.

Implementing Canonical Redirects on Apache and Nginx

Apache RewriteEngine Rules for .htaccess and Server Configs

In Apache environments, canonical redirects are efficiently handled using RewriteEngine rules in your .htaccess file or central server configuration. If your canonical domain is the non-www version, you would add the following to force all www traffic to the root domain:

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

This rule checks if HTTPS is off or if the request included the www prefix, then issues a 301 redirect to the secure, non-www version. A similar rule can be inverted if you prefer the www variant as your primary.

Nginx Server Blocks for 301 Redirects to the Canonical Host

Nginx administrators should configure separate server blocks for the non-primary hostname that return a 301 redirect to the canonical server block. This is highly efficient and processes incredibly fast. If your primary site is www.example.com, your Nginx configuration would look like this:

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

Note that even the non-canonical block must include the SSL certificate paths. If SSL is not configured on the redirecting block, browsers will throw a security error before the redirect can even execute.

Leveraging CDNs and Edge Redirects for SSL Termination

If you are utilizing a Content Delivery Network like Cloudflare, you can manage www versus non-www redirects before traffic ever hits your origin server. CDNs allow seamless SSL termination at the edge, meaning you can enforce Strict HTTPS and manage edge redirects natively from their dashboard.

This setup significantly minimizes origin SSL CPU overhead on hosting options like shared hosting or a Managed VPS. The CDN handles the cryptographic math required for HTTPS handshakes for millions of visitors, passing only standard HTTP requests back to your origin server behind the scenes.

Managing SSL AutoSSL in Hosting Control Panels

If you operate your business through control panels like cPanel or DirectAdmin, these platforms include an AutoSSL feature that handles certificates automatically. However, when migrating between preferred domains on managed infrastructure, you must verify that autoSSL generation covers the (sub)domain aliases you intend to redirect.

If you set up a redirect but delete the DNS record or disable the alias in cPanel before AutoSSL renews the certificate, the redirect destination will break at renewal time. Always verify that both root domains and mapped subdomains are listed in the AutoSSL queue to prevent automated certificate renewal failures.

Configuring Reverse Proxies and Load Balancers for HTTPS Traffic

For dedicated servers and private cloud deployments utilizing reverse proxies like HAProxy or load balancers, offloading SSL to the proxy introduces a new challenge: the backend application needs to know if the original request was encrypted.

Passing the X-Forwarded-Proto Header

You must ensure the X-Forwarded-Proto header is passed to the backend application. If your load balancer communicates with your application server over HTTP (port 80), but the original user connected over HTTPS (port 443), the backend might assume HTTP is being used. Without this header, frameworks like WordPress or Laravel will attempt to loop the 301 redirect indefinitely, resulting in an “ERR_TOO_MANY_REDIRECTS” error in the browser.

# HAProxy example for forwarding proto
http-request set-header X-Forwarded-Proto https if { ssl_fc }

Best Practices

• Secure before you redirect: Always install valid SSL certificates covering both www and non-www variants before enforcing redirects to avoid locking users out of an unsecured endpoint.
• Consolidate your DNS: Ensure DNS A records exist for both the root domain and the www subdomain, pointing to the same origin server or CDN IP.
• Use Let’s Encrypt SANs: Take advantage of free Let’s Encrypt SAN capabilities to simultaneously secure multiple domain formats with a single certificate.
• Mind your redirects on CDNs: When using Cloudflare or similar services, use edge rules or page rules for redirects to save Origin CPU resources.
• HSTS implementation timing: Only configure HSTS headers once you are 100% certain that all domains and subdomains resolve correctly over HTTPS without certificate errors.

Troubleshooting

Conclusion

Making the choice between www and non-www is less about preference and more about strict, secure architecture. By utilizing a Let’s Encrypt SAN certificate to cover both variants, setting a permanent 301 redirect canonical structure, and correctly passing headers through any reverse proxies or CDNs, you guarantee that search engines view your site as a single entity and that users always land safely on an encrypted connection.

Once these systems are implemented carefully across your hosting environments—whether utilizing OwnWebServers managed cloud VPS platforms or dedicated infrastructure—you can safely add HSTS to lock down your traffic permanently. Taking these steps transforms your domain handling from a potential security liability into a robust, SEO-friendly foundation for your business growth.

Frequently Asked Questions