www and non-www are technically different hosts. One version must be chosen as canonical, and the other must be redirected to the HTTPS canonical target with a single 301. The certificate must cover both hosts, and subdomains must not be accidentally redirected to the main domain with a broad regex.
www.example.com -> example.com
301 Moved Permanently
SSL_ERROR_BAD_CERT_DOMAIN
Redirect loop
Canonical host mismatchwww and non-www are technically different hosts. One version must be chosen as canonical, and the other must be redirected to the HTTPS canonical target with a single 301. The certificate must cover both hosts, and subdomains must not be accidentally redirected to the main domain with a broad regex.
Do not expect a `.htaccess` result without reserving the Apache, LiteSpeed, Plesk proxy or NGINX-only structure.
Back up the current file with the date; Find the directive and line in the Apache/LiteSpeed error log.
Do not change redirect, rewrite, header and access rules all at the same time.
Measure the status, Location, Content-Type and redirect number with curl and check the cache layers separately.
Do not use any Host header from the user as a redirect target.
Meaning: The www and non-www rules redirect to each other.
Possible cause: Two panel or two `.htaccess` rules.
Meaning: TLS verification fails before the redirect takes place.
Possible cause: Sertifika SAN listesinde www yok.
Meaning: The host condition is too broad.
Possible cause: All `*.example.com` subdomains are matching.
Meaning: Protocol and host are in separate rules.
Possible cause: HTTPS first, then non-www.
Meaning: The Home/Site URL points to a different canonical host.
Possible cause: Application URL setting.
Meaning: The panel and `.htaccess` use different targets.
Possible cause: Two management points.
Meaning: The edge and origin target different hosts.
Possible cause: Double redirect.
Meaning: Host variations may be separate URL-prefix properties.
Possible cause: Normal ownership separation.
No records matching this expression were found.
for u in http://example.com https://example.com http://www.example.com https://www.example.com; do curl -sS -o /dev/null -w "$u -> %{http_code} %{url_effective} redirects:%{num_redirects}\n" -L "$u"; doneCompares all basic URL variations.
curl -sIL --max-redirs 10 http://www.example.com/path?x=1 | grep -iE '^HTTP|^location:'Shows the redirect chain with path and query.
echo | openssl s_client -connect example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -ext subjectAltNameShows whether the certificate covers the www and non-www hosts.
grep -nE 'HTTP_HOST|SERVER_NAME|www\\.|example\\.com|R=301' .htaccessFinds the canonical host rules.
dig +short example.com A; dig +short www.example.com A; dig +short www.example.com CNAMEShows the DNS targets for www and the root domain.
curl -sL https://example.com/path | grep -ioE '<link[^>]+rel=["'"']canonical["'"'][^>]*>' | head -n 1Shows the target page's canonical host.
RewriteCond %{HTTP_HOST} www.example.com
RewriteRule ^ http://example.com%{REQUEST_URI} [R=301,L]RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]RewriteCond %{HTTP_HOST} !^example\.com$
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]RewriteCond %{HTTP_HOST} ^(?:www\.)?example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]The full host condition and final HTTPS target can be managed in a single rule set.
DNS proxy and edge redirect may conflict with origin rules.
The application and panel domain settings must match the chosen host.
No. NGINX does not read `.htaccess` files. The rule must be translated to a `server` or `location` configuration.
Usually not; Apache evaluates the `.htaccess` file on each request. However, a reload or restart is required for VirtualHost, module, or AllowOverride changes.
A dated backup of the existing file should be taken, the active document root verified, and the change tested on staging or during low-traffic periods.
In cPanel it is usually inside `public_html`, in Plesk inside `httpdocs`; addon domains and subdomains may have a different document root.
LiteSpeed supports most rules through Apache compatibility; some module and handler behaviors may differ.
Full directive and line record in Apache/LiteSpeed error log. The file should be restored according to the log instead of being deleted randomly.
Domain should not be added directly without verifying domain, document root, proxy, WordPress, and server structure. Examples should be adapted and tested.
We examine redirection, rewrite, CORS, access and 500 errors with logs in cPanel, Plesk, LiteSpeed, WordPress, custom PHP and WISECP structures.