HTTP to HTTPS Redirects: The Complete Guide

Migrating from HTTP to HTTPS is one of the most common redirect operations, and one of the easiest to get wrong. A correct implementation is a single 301 redirect per URL. A botched implementation creates redirect loops, mixed content warnings, SEO ranking drops, and broken functionality.

This guide covers every step: server configuration, redirect rules, mixed content resolution, HSTS deployment, and SEO verification. For the full overview of all redirect types, see our HTTP Redirect Guide.

Why HTTPS matters

HTTPS is no longer optional. It is a baseline requirement for any website. [1]

Before starting the migration, make sure you have a valid SSL certificate installed for your domain and all subdomains. If you need a free certificate, Let's Encrypt is the standard choice.

The redirect architecture

The correct HTTP to HTTPS redirect is a 301 from every HTTP URL to its HTTPS equivalent:

http://example.com/any-page
  --> 301 --> https://example.com/any-page

http://www.example.com/any-page
  --> 301 --> https://www.example.com/any-page

The redirect should preserve the full path and query string. It should not redirect to the homepage or strip URL parameters.

CORRECT:
http://example.com/products?category=shoes&sort=price
  --> https://example.com/products?category=shoes&sort=price

WRONG:
http://example.com/products?category=shoes&sort=price
  --> https://example.com/           (path and query lost)
  --> https://example.com/products   (query string lost)

If you are also consolidating www and non-www, do both in a single hop. Do not create a redirect chain where HTTP redirects to HTTPS, which then redirects non-www to www (or vice versa). Combine them.

Server configuration

Nginx

# Redirect all HTTP traffic to HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# HTTPS server block
server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # ... your site configuration
}

Apache

# In .htaccess or VirtualHost config
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

For more on .htaccess syntax and common patterns, see .htaccess Redirect Rules Guide.

Apache (alternative with mod_alias)

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

IIS (web.config)

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="HTTP to HTTPS" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{HTTPS}" pattern="off" ignoreCase="true" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"
                  redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

For more on IIS redirect rules, see IIS URL Redirect Guide.

CDN-level redirects

Most CDNs offer HTTPS enforcement at the edge, which is the fastest option:

For a detailed walkthrough of Cloudflare redirect configuration, see Cloudflare Redirect Guide.

Avoiding redirect loops

The most common HTTP-to-HTTPS redirect problem is a loop. It happens when your application or origin server does not know the request originally arrived over HTTPS because a load balancer or CDN terminated the SSL connection.

User (HTTPS) --> CDN/LB (terminates SSL) --> Origin (sees HTTP)
Origin: "This is HTTP, redirect to HTTPS"
CDN/LB: follows redirect, terminates SSL again
Origin: "This is still HTTP, redirect to HTTPS"
... (loop)

If you are seeing this error, see How to Fix ERR_TOO_MANY_REDIRECTS for a step-by-step diagnosis.

The fix: trust X-Forwarded-Proto

When a load balancer terminates SSL, it adds an X-Forwarded-Proto: https header. Your redirect rule should check this header:

# Nginx behind a load balancer
server {
    listen 80;

    # Only redirect if the original request was HTTP
    if ($http_x_forwarded_proto = "http") {
        return 301 https://$host$request_uri;
    }
}

# Apache behind a load balancer
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Mixed content: the hidden problem

After enabling HTTPS, your pages may still load resources (images, scripts, stylesheets, fonts) over HTTP. Browsers block or warn about this "mixed content." [2]

Types of mixed content

Finding mixed content

Check your browser's DevTools console for mixed content warnings:

Mixed Content: The page at 'https://example.com/page' was loaded over HTTPS,
but requested an insecure image 'http://example.com/image.jpg'.

Fixing mixed content

Content-Security-Policy: upgrade-insecure-requests

HSTS: making HTTPS permanent

HTTP Strict Transport Security (HSTS) tells browsers to always use HTTPS for your domain, even if the user types http://. This eliminates the initial HTTP request entirely after the first visit. [3]

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

HSTS deployment strategy

Deploy HSTS gradually to avoid locking yourself out:

SEO checklist for HTTP to HTTPS

After implementing the redirect, verify these SEO elements:

• Google Search Console: Add the HTTPS property and verify ownership. The HTTP and HTTPS versions are separate properties.
• Sitemap: Update your sitemap to use HTTPS URLs. Submit the updated sitemap in Search Console.
• Canonical tags: Ensure all <link rel="canonical"> tags use HTTPS URLs.
• Internal links: Update all internal links from HTTP to HTTPS. While the redirect handles them, direct HTTPS links are faster and avoid redirect hops.
• Robots.txt: Ensure the HTTPS version of robots.txt is accessible and correct.
• Structured data: Update any absolute URLs in your JSON-LD or schema markup to HTTPS.
• Social meta tags: Update Open Graph and Twitter Card URLs to HTTPS.
• DNS records: Verify your DNS configuration points to the correct servers for HTTPS.

Verification

After deployment, verify the complete redirect chain:

# Check the redirect
curl -I http://example.com/
# Should show: HTTP/1.1 301 Moved Permanently
#              Location: https://example.com/

# Check HSTS header
curl -I https://example.com/
# Should show: Strict-Transport-Security: max-age=31536000; ...

# Check for mixed content (download page and search for http://)
curl -s https://example.com/ | grep -c "http://"
# Should be 0 (or only in safe contexts like links to external sites)

For a full site audit, use How to Check Redirects in Bulk to verify every URL has correct HTTPS enforcement. For ongoing monitoring of your SSL certificates after migration, use SSL Certificate Expiry to get alerts before your certificate expires and breaks the HTTPS you just set up.

References

1. Google, "HTTPS as a ranking signal," Google Search Central Blog, August 2014. https://developers.google.com/search/blog/2014/08/https-as-ranking-signal
2. MDN Web Docs, "Mixed content," Mozilla, 2024. https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
3. IETF, "RFC 6797 - HTTP Strict Transport Security (HSTS)," November 2012. https://datatracker.ietf.org/doc/html/rfc6797