How to Redirect HTTP to HTTPS Correctly

Having a certificate is only half the job — you also need to make sure nobody stays on the insecure http:// version of your pages. A correct redirect sends every visitor to HTTPS once, preserves your search rankings, and avoids the loops that take a site offline.

301 vs 302: use the permanent one

The status code you choose matters. A 301 Moved Permanently tells browsers and search engines the HTTPS URL is the canonical, lasting home of the page. Search engines transfer ranking signals to the HTTPS version and browsers cache the redirect, so repeat visitors go straight to HTTPS.

A 302 Found signals a temporary move. Search engines may keep indexing the HTTP URL, and browsers will not cache the redirect the same way. For forcing HTTPS — a permanent decision — a 302 is the wrong tool. Always use 301.

Apache (.htaccess)

On Apache or LiteSpeed, redirect in .htaccess with mod_rewrite. This preserves the host, path and query string:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

If your site sits behind a load balancer or CDN that terminates TLS, the %{HTTPS} variable may always read off because the connection to your origin really is plain HTTP. In that case, check the forwarded header instead:

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx

On Nginx, use a dedicated server block for port 80 that returns a 301. This is cleaner and faster than a rewrite:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Behind a proxy, redirect based on the forwarded protocol instead of assuming the port:

if ($http_x_forwarded_proto = "http") {
    return 301 https://$host$request_uri;
}

Avoiding redirect loops

A redirect loop happens when the server keeps sending the browser back to a URL that redirects again — the browser gives up with an error like ERR_TOO_MANY_REDIRECTS. The usual cause is a CDN or load balancer terminating HTTPS and forwarding plain HTTP to your origin, which then “helpfully” redirects to HTTPS forever.

Another subtle cause is redirecting in two places at once — for example both your application and your web server forcing HTTPS with slightly different rules. Keep the redirect in exactly one place.

Redirect once, not twice

Chaining redirects — http:// to https://, then www to non-www as a separate hop — adds latency and dilutes SEO signals. Where you can, combine host and protocol canonicalization so a visitor reaches the final HTTPS URL in a single 301.

Pair it with HSTS

A redirect still lets the very first request go out over insecure HTTP, where it can be intercepted. HTTP Strict Transport Security closes that gap: once a browser has seen the header, it rewrites http:// to https:// itself before sending anything.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Add HSTS only after your HTTPS redirect is confirmed working across every subdomain, and start with a short max-age. See the full HSTS guide before adding preload, and review your other security headers while you are there.

Verify it worked

After deploying, request an http:// URL and confirm you receive a single 301 to the matching https:// address with the path intact. Run a scan or use our speed test to check the response headers and make sure no loop or mixed content remains.

Frequently asked questions

Related guides