Your website should have one preferred address: either example.com or www.example.com. Neither format has an inherent SEO advantage. What matters is that visitors and crawlers reach the same HTTPS pages, with the old host redirected permanently to the preferred one.
Before changing anything, note the version that is already indexed, linked, and used in WordPress. Make a backup of your server configuration. If a CDN, host, or reverse proxy already handles redirects, make the change there instead of adding a competing rule in WordPress.
WWW or non-WWW: which should you keep?
Keep the version that your site already uses consistently unless there is a good reason to migrate. Check WordPress Address and Site Address in Settings > General, your current canonical tags, sitemap URLs, internal links, and Search Console data. Google recommends consolidating duplicate URLs using consistent signals, including redirects and canonical URLs; it does not require a particular host style.
Method 1: use your hosting or CDN redirect setting
This is usually the simplest option. Set the non-preferred host to permanently redirect to the HTTPS preferred host, retaining the full path and query string. A request for http://example.com/services/?source=email should land on https://www.example.com/services/?source=email if WWW is your choice. Avoid redirect rules at both the CDN and the origin that point back at each other.
Method 2: use Apache .htaccess
These examples are for a standard Apache site whose document root contains WordPress. Put the chosen rule above the WordPress-generated rewrite block in .htaccess. Replace example.com with your own domain. Apache’s mod_rewrite documentation explains the host-condition and redirect pattern. Do not paste both directions.
Redirect non-WWW to WWW
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]Redirect WWW to non-WWW
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.example.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]These rules change the host and send visitors to HTTPS. They preserve the path; Apache normally carries the original query string when the substitution has no new query string. Your host may already redirect HTTP to HTTPS. A reverse proxy can make server-side HTTPS detection unreliable, so test every variant rather than combining random rules from different tutorials.
Method 3: use an Nginx server redirect
On Nginx, the host should configure a dedicated server block for the old hostname with a permanent redirect to the preferred one. For example, a host administrator may use the following for the HTTPS non-WWW virtual host. The certificate must cover the old hostname too, or visitors can encounter a certificate warning before any redirect runs.
server {
listen 443 ssl;
server_name example.com;
# Configure the certificate and key for example.com here.
return 301 https://www.example.com$request_uri;
}Have your host configure the matching port-80 behavior and certificates. Do not add a partial Nginx block to a live configuration without validating it first.
Method 4: use WordPress only when the server cannot do it
A redirect plugin can be a fallback for sites where you control neither hosting nor CDN rules. It must run only after WordPress loads, so it cannot fix a missing DNS record, an invalid TLS certificate, or a redirect loop occurring before WordPress. Configure one site-wide host rule, not a separate rule for every post. Changing WordPress Address and Site Address alone updates generated URLs; it does not guarantee a proper redirect for every old URL.
Test the redirect before calling it done
- Visit the HTTP and HTTPS versions of both hostnames in a private window. Each should reach the preferred HTTPS host.
- Test a post, a page, and a URL with query parameters. Paths and parameters should survive.
- Check headers with curl and look for a 301 from the old host followed by a 200 on the destination. Avoid multi-hop chains.
- Inspect the destination page canonical tag, XML sitemap, internal links, and WordPress URL settings for the same preferred host.
- Check Search Console after the change for redirect errors, duplicate URLs, and a temporary shift in indexed URLs.
curl -I "http://example.com/sample-page/?ref=test"
curl -I "https://example.com/sample-page/?ref=test"
curl -I "https://www.example.com/sample-page/?ref=test"Common problems
| Symptom | Likely cause | Next check |
|---|---|---|
| Infinite loop | Two rules disagree, or proxy HTTPS is misread. | Inspect CDN and origin rules; test one layer at a time. |
| Homepage works but posts fail | Path handling or WordPress rewrite order is wrong. | Test a known permalink and check .htaccess placement. |
| HTTPS warning before redirect | Old host lacks a valid certificate. | Add both hostnames to TLS coverage. |
| Both hosts show 200 | No host-level redirect is applied. | Check DNS, CDN, web server, and cache behavior. |
If redirects are part of a broader site problem, a three-point website review can help identify the user-facing friction. If the site sends visitors to an unfamiliar domain, use the unexpected redirect guide to check why. If the site is compromised, continue with the malware removal guide.
Replace the example domain before using any code. Back up configuration and test on staging when possible. Hosting and CDN settings vary.