How to redirect HTTP to HTTPS

Overview

An HTTP to HTTPS redirect makes every old http:// URL permanently become its https:// twin with a single 301 response. It protects the search value and the booking/bookmark integrity that the previous HTTP URLs earned. The trick is to have exactly one redirect at the edge, never a chain, and never a redirect from https back to http, which is the classic loop.

The universal rule: one hop

| What | Response code | Where |

| Client visits http://example.com/page | 301 Moved Permanently with Location: https://example.com/page | At the edge (CDN/proxy) or web server |

Only the same host: http://example.com should redirect to https://example.com, not to https://www.something-else.com. If the domain also needs a bare-to-www move, do it in the same edge rule so it stays one suggestion.

1. Nginx

In the server block for port 80:

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

The main server block listens on 443. Verify with nginx -t and reload.

2. Apache (.htaccess or vhost)

In the virtual host or .htaccess in the docroot:

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

Works on shared hosting where only .htaccess is allowed; on Apache config, put it in the port 80 <VirtualHost>.

3. WordPress

• Set site address and WordPress address to https:// in Settings > General.
• Install a redirect plugin or add the FORCE_SSL snippet in wp-config.php.
• The plugin sets the same 301 at the server or wp_redirect layer. Either way a single hop, not a plugin plus a server rule both firing.

4. Cloudflare and other CDNs

If the site runs behind Cloudflare, use the SSL/TLS > Edge Certificates "Always Use HTTPS" toggle before adding a server redirect. Edge-level redirect rules replace http:// with https:// at the proxy, so the origin never sees HTTP at all, which also protects mixed-content upgrades.

The redirect loop trap

A loop happens when the origin requests https but the proxy reverses it, or two software layers point at each other. Symptoms: ERR_TOO_MANY_REDIRECTS in the browser, curl showing endless 301s. The standard cause chain is Cloudflare "Flexible" mode forcing origin http while the origin HTTPS redirect forces https again. Fix: set a proper Full (strict) mode when origin has a valid certificate, or if Flexible stays, drop the origin-level force.

Verifying the redirect chain

• curl -sI http://example.com shows the HTTP/1.1 301 ... line and the Location: header pointing at https.
• curl -sIL https://example.com stops on 200 if no loop.
• Browser test in an incognito window on a few internal links, then a crawl tool that flags a 302 instead of 301 (a 301 is the one that sets a new canonical).

Sending an HSTS header once the move is clean

Once http reliably redirects to https and every subresource loads over https, add a Strict-Transport-Security header on the https response, for example Strict-Transport-Security: max-age=31536000. Browsers that have seen that response then refuse to plain-http requests to the domain from then on. Do not enable HSTS before the redirect and all subresources are clean, or repeat visitors can be locked out of the site during the transition.

Fast but safe edge cases

• If the site is served over https already (padlock fine), the only remaining job is making all inbound http sync up.
• If email or third-party links still point at http, the 301 converts them without breaking the receiving host.
• After the move, update any hard-coded http:// internal URLs you find, because a redirect only fixes the page, not the mixed-content source string; the mixed-content fix article covers that.

The 301 article explains the permanent status in detail; the mixed-content fix article prevents the padlock problems that come after the move.