Compare Items
Please, add items to this compare group or choose not empty group
How to Redirect HTTP to HTTPS
By Crumb Peter
SSL Certificate

How to Redirect HTTP to HTTPS

Last updated: Nov 13, 2025

Redirecting HTTP to HTTPS is one of the most essential steps in securing a website today. Whether you’re running a personal blog or managing a large business application, forcing HTTPS ensures that every visitor accesses your site over a secure, encrypted connection. This protects their data from being intercepted, prevents browser warnings, and improves your site’s credibility and SEO.

In the early years of the internet, websites commonly used plain HTTP, which transmitted data in readable text. Today, browsers like Chrome and Firefox label HTTP sites as “Not Secure”, and Google actively prioritizes HTTPS-enabled websites in search rankings. If your site isn’t redirecting all traffic to HTTPS — even if you’ve installed an SSL certificate — users may still access insecure pages, leaving your site vulnerable.

That’s where an HTTP to HTTPS redirect comes in.

This guide will walk you through:

  • Why redirecting is critical for security, SEO, and user trust

  • How HTTPS redirects actually work behind the scenes

  • Step-by-step instructions to force HTTPS on Apache, Nginx, WordPress, Cloudflare, and cPanel

  • How to prevent redirect loops, SSL errors, and mixed content problems

  • Best practices for long-term HTTPS stability

Why Redirecting HTTP to HTTPS Matters

Redirecting HTTP to HTTPS ensures every visitor lands on the secure version of your website. Even if you’ve installed an SSL certificate, users may still reach the insecure HTTP version unless you set up a proper redirect. This can lead to security risks, browser warnings, and SEO problems.

Here are the main reasons why forcing HTTPS is essential:

  • Protects user data
    HTTPS encrypts all information exchanged between the browser and your server. This prevents attackers from stealing login details, personal information, or payment data.

  • Removes “Not Secure” browser warnings
    Modern browsers like Chrome and Firefox flag HTTP sites as unsafe. Redirecting to HTTPS instantly removes this warning and boosts user trust.

  • Improves SEO rankings
    Google uses HTTPS as a ranking signal. Sites running only on HTTP often rank lower, while fully secure sites enjoy better visibility.

  • Prevents duplicate content problems
    If both HTTP and HTTPS versions of your pages are accessible, search engines treat them as separate URLs. A redirect ensures all authority flows to the secure version.

  • Fixes and prevents mixed content issues
    HTTPS can break when some files (images, scripts, stylesheets) load over HTTP. A global redirect makes it easier to detect and eliminate insecure resources.

  • Creates a consistent, secure user experience
    Every visitor lands on the correct, encrypted version of your site, no matter what link they click or bookmark they use.

  • Required for many modern web features
    Technologies like HTTP/3, service workers, push notifications, and geolocation APIs require HTTPS to function.

Redirecting HTTP to HTTPS is no longer optional—it’s part of the foundation of a secure, trustworthy, search-friendly website.

How HTTP to HTTPS Redirects Work Behind the Scenes

When someone types your website address into the browser, the browser has no way of knowing whether the site should load over HTTP or HTTPS. If both versions are available, the browser will load whichever one the server responds with first. That’s why a redirect is needed — it ensures visitors always reach the secure version no matter what.

Here’s what actually happens behind the scenes when an HTTP to HTTPS redirect is in place:

  • The user tries to access the HTTP version
    The browser sends a request to http://yourdomain.com on port 80. This is an unencrypted request, meaning the contents could be intercepted or modified by anyone on the same network.

  • Your server immediately responds with a redirect rule
    Instead of serving the HTTP page, your server returns a 301 Moved Permanently response. This tells the browser, “This page now lives at the HTTPS version. Always go there.”

  • The browser automatically follows the redirect
    After seeing the 301 redirect, the browser requests the secure URL:
    https://yourdomain.com
    This time, the request goes through port 443 using a secure TLS handshake.

  • The SSL/TLS handshake begins
    Before any data is exchanged, the browser and server perform a handshake that:

    • Verifies the website’s identity using its SSL certificate

    • Agrees on an encryption method

    • Establishes a secure session key for encrypted communication

  • The browser loads the secure page
    Once the handshake is complete, the browser loads the HTTPS version of the site, and users see the padlock icon indicating a secure connection.

  • Future requests may skip HTTP entirely
    If you also enable HSTS (HTTP Strict Transport Security), the browser remembers to never use HTTP again. Even if users type http://, the browser forces HTTPS automatically before sending a request to the server.

This redirection process happens within milliseconds, and users barely notice it — but it ensures every visitor loads the safe, encrypted version of your website.

Redirecting HTTP to HTTPS Using .htaccess (Apache)

If your website runs on an Apache server, the most common and reliable way to force HTTPS is by adding a redirect rule to the .htaccess file. This method works for most shared hosting environments, including cPanel-based hosts, and is the standard solution supported by WordPress, Joomla, Drupal, and many PHP applications.

Here’s how to do it safely and correctly.

Locate or Create the .htaccess File

The .htaccess file usually sits in the root directory of your website (public_html or www).
If the file doesn’t exist, you can create one using any text editor — just make sure the name is .htaccess (with a dot at the beginning and no extension).

Most hosting dashboards also offer a file manager where you can show hidden files and edit .htaccess directly.

Add the HTTPS Redirect Rule

Below is the most reliable and widely supported rule to redirect all HTTP traffic to HTTPS:

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

This rule does three things:

  • RewriteEngine On
    Enables the Apache mod_rewrite module, which must be active for redirects to work.

  • RewriteCond %{HTTPS} off
    Checks whether the current request is not using HTTPS.

  • RewriteRule
    Redirects the request to the exact same URL, but with https:// added.

Because this is a 301 Redirect, it tells browsers and search engines to permanently use the HTTPS version of your site.

Place the Redirect at the Top of the File

The HTTPS redirect should appear before any CMS-generated rules.

For WordPress users, that means placing it above:

# BEGIN WordPress

Placing the redirect at the top ensures:

  • The redirect is applied before other rules run

  • WordPress or other applications don’t override your configuration

Redirecting www to non-www (or vice versa)

If you also want to force both HTTPS and a canonical URL version, here are safe examples:

Force HTTPS and www:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Force HTTPS and non-www:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule ^(.*)$ https://yourdomain.com/$1 [L,R=301]

Make Sure mod_rewrite Is Enabled

Your server must have mod_rewrite active.
If redirects aren’t working, check with your hosting provider or create a phpinfo() file to confirm that mod_rewrite is enabled.

Common Errors and How to Fix Them

Here are the issues most people run into when setting up redirects:

  • Redirect loop
    Often caused by:

    • Cloudflare Flexible SSL

    • CMS redirect plugins

    • Duplicate redirect rules

  • Redirect not working
    Solutions:

    • Clear browser cache

    • Clear server-side cache

    • Restart Apache if you have root access

  • Only the homepage redirects
    Usually caused by placing the redirect inside the wrong directory.

The .htaccess method is one of the most universal ways to force HTTPS, especially for shared hosting or WordPress-based sites.

Redirecting HTTP to HTTPS with Nginx

Nginx is common for high-performance sites and reverse-proxy setups. Forcing HTTPS in Nginx is fast and efficient when done correctly. Below are practical, copy-ready configs, explanations of why they work, and troubleshooting tips so you don’t end up with redirect loops or broken APIs.

How the redirect works

  • Nginx receives a request on port 80 (HTTP) and returns an HTTP 301 redirect to the same path on the HTTPS URL.

  • The browser follows the redirect and connects on port 443 (HTTPS), where the TLS handshake happens and the secure page loads.

  • Use 301 for permanent redirects (SEO friendly). Use 302 only for temporary cases.

Simple, correct redirect for a single domain

server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;# Redirect all HTTP requests to HTTPS preserving host and URI
return 301 https://$host$request_uri;
}

Why this is good

  • return 301 is faster and safer than rewrite for full-site redirects.

  • $host preserves the requested host (www vs non-www); $request_uri preserves path and query string.

  • Works with virtual hosts and multiple server_name entries.

Redirect to a canonical host (force https + non-www)

server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;if ($host = ‘www.example.com’) {
return 301 https://example.com$request_uri;
}

return 301 https://example.com$request_uri;
}

Better approach without if (preferred)

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

Why avoid if when you can: if in Nginx can be error-prone inside server blocks; explicit server blocks are clearer and safer.

Example full HTTPS server block (with certificate)

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.com;ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_session_cache shared:SSL:10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ‘ECDHE-ECDSA-CHACHA20-POLY1305:…’; # use Mozilla config
ssl_prefer_server_ciphers on;

root /var/www/html;
index index.html index.php;

location / {
try_files $uri $uri/ =404;
}
}

Notes

  • Use fullchain.pem (server cert + intermediates) to avoid chain errors.

  • Use modern TLS settings (TLS 1.2+; ideally TLS 1.3). Generate recommended cipher lists from Mozilla SSL Configurator.

Redirects when behind a load balancer or reverse proxy

  • If Nginx sits behind a load balancer or CDN that terminates TLS (e.g., ELB, Cloudflare in Flexible mode), the upstream request may arrive to Nginx as HTTP even when the client used HTTPS. In these cases, base redirects on headers forwarded by the proxy.

Use forwarded header checks

server {
listen 80;
server_name example.com;# If behind a proxy that sets X-Forwarded-Proto
set $is_https ”;
if ($http_x_forwarded_proto = ‘https’) {
set $is_https ‘on’;
}

if ($is_https != ‘on’) {
return 301 https://$host$request_uri;
}

# normal handling…
}

Better: configure the proxy to set X-Forwarded-Proto and use map for performance:

map $http_x_forwarded_proto $redirect_to_https {
default 1;
https 0;
}server {
listen 80;
server_name example.com;

if ($redirect_to_https) {
return 301 https://$host$request_uri;
}

# …
}

Cloudflare-specific advice

  • Avoid using Cloudflare Flexible SSL while redirecting on origin; Flexible accepts HTTPS at Cloudflare but connects to origin via HTTP — this usually creates redirect loops if your origin always redirects HTTP→HTTPS.

  • Recommended: set Cloudflare SSL mode to Full or Full (Strict) and use an origin certificate or a CA-signed cert on the origin.

  • After changing Cloudflare settings, purge cache and wait a few minutes for edge propagation.

Common problems and how to debug them

  • Redirect loop: often caused by proxy/CDN mismatch, multiple redirect rules, or HSTS with wrong host. Test with:

    • curl -I http://example.com to see the redirect chain

    • curl -I -L http://example.com to follow redirects and see HTTP status codes

  • Only homepage redirects or incorrect paths: check your server_name and where the redirect block is placed; ensure it’s in the site’s root server block.

  • TLS handshake errors after redirect: verify certificate paths and permissions; use openssl s_client -connect example.com:443 -servername example.com to inspect the chain and cert presented.

  • Too aggressive caching: edge caches or CDN settings might serve old redirects; purge caches after making config changes.

Testing tips

  • Test from a fresh browser or incognito window to avoid cached redirects and HSTS effects.

  • Check response codes and Location header: curl -I http://example.com should return 301 with Location: https://example.com/....

  • Use SSL Labs (Qualys) or openssl to verify TLS configuration on port 443.

Advanced: force HTTPS only for certain locations

  • Useful for APIs that accept both HTTP and HTTPS for legacy clients:

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

location /legacy/ {
# do not redirect
proxy_pass http://backend_upstream;
}
}

Reloading Nginx safely

  • Test config first, then reload:

sudo nginx -t
sudo systemctl reload nginx

If reload fails, nginx -t tells you the syntax error. Use systemctl status nginx to view logs.

SEO considerations

  • Use 301 Moved Permanently for the redirect to transfer SEO signals.

  • Ensure canonical tags and sitemaps use HTTPS URLs.

  • After redirecting, update internal links and sitemap to point to HTTPS to speed reindexing.

Summary of best practices for Nginx redirect

  • Use return 301 https://$host$request_uri in an HTTP server block for simplicity and speed.

  • Put redirect rules in dedicated server blocks for clarity (avoid if where possible).

  • Ensure your HTTPS server block has a valid full chain certificate.

  • Handle proxy headers properly when behind a load balancer or CDN.

  • Test redirects and TLS with curl, openssl, and SSL Labs; purge caches as needed.

Redirecting HTTP to HTTPS in WordPress

WordPress sites are a special case because the CMS can rewrite URLs, plugins can add redirects, and themes often hard-code links. That means a simple server redirect may not be enough — or it can even create redirect loops. Below are practical, copy-paste steps and checks that work for most WordPress installs, from the simplest to the safest, plus how to diagnose common problems.

Make a backup first

  • Export your database and files (or create a snapshot in your host panel) before making changes.

  • If something goes wrong you can restore quickly. Never run search-replace on a live site without a backup.

Confirm HTTPS works on the server first

  • Install the SSL certificate and verify https://yourdomain.com loads cleanly before forcing redirects.

  • Use openssl s_client -connect yourdomain.com:443 -servername yourdomain.com or SSL Labs to confirm the chain is valid.

Quick, low-risk fixes (try these first)

  • Update WordPress Address and Site Address to https:// in Settings → General. This changes the canonical URL WordPress uses for links.

  • Add define('FORCE_SSL_ADMIN', true); to wp-config.php to force the admin area to HTTPS. Place it above /* That's all, stop editing */.

.htaccess redirect for WordPress (universal server-side)

  • Put this at the very top of your .htaccess (above the WordPress # BEGIN block) so it runs before WP rules:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

  • The extra X-Forwarded-Proto check helps when behind proxies/CDNs that forward the original protocol.

Use a plugin if you prefer UI (safe but check conflicts)

  • Really Simple SSL — auto-detects and sets up redirects, but can hide mixed content issues. Use it to get started, then replace with server redirects once fixed.

  • Better Search Replace — use to fix hardcoded http:// URLs in the DB (see command below).

Fix hardcoded HTTP links in content and database

  • Common sources of mixed content: post content, widgets, theme options, serialized plugin data.

  • Best practice: use WP-CLI (safer) or a plugin with serialization support.

WP-CLI search/replace example (recommended)

  • From the web root, after backup:

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables --precise --recurse-objects --dry-run
# remove --dry-run when output looks correct

  • --precise and --recurse-objects preserve serialized data correctly.

Handle CDN, reverse proxy, and caching layers

  • If using Cloudflare, set SSL mode to Full (Strict) and enable Always Use HTTPS/Automatic HTTPS Rewrites. Avoid Flexible mode — it commonly causes redirect loops.

  • Purge CDN cache and any page cache (WP Super Cache, W3TC, LiteSpeed Cache) after changes. Old cached redirects or pages with HTTP links will persist otherwise.

Fix redirect loops and admin lockouts

  • If you get locked out of wp-admin after forcing HTTPS, you can temporarily disable plugins by renaming wp-content/plugins to plugins.off (or move plugin folders) to rule out plugin conflicts.

  • Clear browser cache and test in an incognito window. HSTS can make browsers remember HTTPS permanently; use a fresh browser if you need to bypass HSTS for testing.

Ensure login and REST API compatibility

  • REST API and AJAX endpoints must use HTTPS. If your JS calls fail with mixed content or CORS, update admin-ajax.php and any fetch/XHR endpoints to https://.

  • For headless or decoupled setups, update API base URLs in environment configs.

Force HTTPS for admin, logins, and cookies

  • Add to wp-config.php:

define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true); // some older WP versions or plugins use this

  • Check cookie settings and secure flags in plugins that manage auth cookies; ensure cookies are marked Secure.

Add HSTS only when you’re ready

  • Don’t enable HSTS until:

    • All subdomains that need HTTPS are on TLS (or you exclude includeSubDomains)

    • You understand preload implications (preload is effectively permanent)

  • Example header via .htaccess or server config:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

  • For testing, use a short max-age (like 86400) first.

Search engines and SEO cleanup after redirect

  • Update canonical tags and sitemaps to HTTPS versions.

  • Resubmit your sitemap in Google Search Console (add the HTTPS property).

  • Update links in external places you control (social profiles, ad platforms).

Testing checklist after forcing HTTPS

  • curl -I http://yourdomain.com should return 301 with Location: https://...

  • curl -I -L http://yourdomain.com should eventually return 200 for HTTPS page.

  • Confirm no mixed content in the browser console (F12 → Console).

  • Run SSL Labs test to confirm TLS setup.

  • Search your site for http://yourdomain.com strings (Screaming Frog, grep in DB dump).

Troubleshooting common WordPress problems

  • Persistent mixed content: some plugins/themes store absolute URLs. Use WP-CLI or serialized search-replace.

  • Redirect loop after Cloudflare + origin redirect: set Cloudflare to Full (Strict), or remove origin redirect and let Cloudflare handle HTTPS redirection.

  • Only homepage redirects: check if your redirect rule is in a subdirectory or the site is served from a different document root.

  • Images still loading via HTTP (broken thumbnails): regenerate thumbnails and run DB replace on wp_posts and wp_postmeta.

Rollout tips and staging best practices

  • Test on a staging site (duplicate the site and its SSL setup) before changing production.

  • Use short max-age for HSTS in staging and lengthen in production once verified.

  • For multisite, remember each site’s domain and network settings may need updating individually.

Quick summary (what to do, in order)

  • Install and verify SSL certificate on the server.

  • Update Site Address and WordPress Address to https:// in settings.

  • Add FORCE_SSL_ADMIN to wp-config.php.

  • Add server-level redirect (prefer server over plugin).

  • Fix all http:// URLs in the DB using WP-CLI.

  • Purge CDN and page caches.

  • Test thoroughly and enable HSTS only when confident.

Share:
Crumb Peter
administrator
    Crumb Peter is a passionate cyber security enthusiast, driven by a constant desire to stay ahead of the curve in this ever-evolving landscape. With an insatiable thirst for knowledge, Crumb actively seeks out and absorbs new advancements in the web and cyber security niche.

    Powered by
    ►
    Necessary cookies enable essential site features like secure log-ins and consent preference adjustments. They do not store personal data.
    None
    ►
    Functional cookies support features like content sharing on social media, collecting feedback, and enabling third-party tools.
    None
    ►
    Analytical cookies track visitor interactions, providing insights on metrics like visitor count, bounce rate, and traffic sources.
    None
    ►
    Advertisement cookies deliver personalized ads based on your previous visits and analyze the effectiveness of ad campaigns.
    None
    Powered by