How to Redirect HTTP to HTTPS: A Practical Guide to Secure, SEO-Friendly Site Migration

Written by: Abigail Ivy
Published on:

How to Redirect HTTP to HTTPS

Redirecting HTTP to HTTPS is one of the most important technical SEO and security upgrades you can make.

It protects user data, improves trust, and helps search engines understand that your secure version should be indexed and ranked.

If you still have pages available over HTTP, this guide shows how to redirect them correctly across common web servers, CMS platforms, and CDN setups without losing traffic or creating duplicate content issues.

Why HTTPS matters for modern websites

HTTPS uses Transport Layer Security (TLS) to encrypt data between a browser and a web server.

That encryption helps prevent interception, tampering, and credential theft, especially on login forms, checkout pages, and contact forms.

Search engines also treat HTTPS as a trust signal.

Google has confirmed that HTTPS is a ranking signal, and browsers such as Chrome mark HTTP pages as “Not Secure,” which can reduce user confidence and conversions.

  • Security: encrypts traffic and reduces man-in-the-middle risk
  • SEO: consolidates indexing on the secure canonical version
  • Trust: improves browser warnings and user confidence
  • Performance: works with HTTP/2 and HTTP/3 on most modern hosts

What you should do before redirecting

Before you redirect HTTP to HTTPS, make sure the secure version of your site is fully ready.

A redirect alone does not fix mixed content, broken canonical tags, or missing certificates.

Confirm your SSL/TLS certificate is active

Install a valid certificate from a trusted certificate authority such as Let’s Encrypt, DigiCert, GlobalSign, or Sectigo.

Check that the certificate covers all required hostnames, including www and non-www versions if both are used.

Update internal URLs

Replace hardcoded HTTP links in navigation menus, templates, XML sitemaps, image links, JavaScript files, and CSS assets.

Relative URLs are safer, but absolute HTTP links can still cause mixed content warnings.

Check canonical and hreflang tags

Canonical tags should point to the HTTPS version of each page.

If your site uses hreflang for international targeting, each alternate URL should also reference the secure version.

Back up configuration files

Before changing rewrite rules or server directives, save a backup of your configuration files.

A small syntax error in Apache, Nginx, or a reverse proxy config can take the site offline.

How to redirect HTTP to HTTPS on Apache

Apache websites usually use .htaccess or the main virtual host configuration to force HTTPS.

The best approach depends on whether you have access to server-level settings.

Using .htaccess

Add the following rule near the top of your .htaccess file, before other rewrite logic:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

This sends a permanent 301 redirect from every HTTP request to the same path on HTTPS.

Using Apache virtual host configuration

If you control the server config, define a separate HTTP virtual host and redirect it cleanly:

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

Server-level redirects are faster and easier to maintain than .htaccess rules, especially on high-traffic sites.

How to redirect HTTP to HTTPS on Nginx

Nginx uses server blocks rather than .htaccess files.

The standard method is to create an HTTP server block that points all requests to the HTTPS version.

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

If you prefer to preserve the hostname exactly as requested, you can redirect to the same host over HTTPS:

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

Make sure the HTTPS server block includes a valid certificate, proper TLS protocol settings, and a matching server_name entry.

How to redirect HTTP to HTTPS in WordPress

WordPress sites often combine server redirects with platform-level settings to avoid loops and mixed content issues.

The safest method is to enforce HTTPS at the web server level and then update WordPress URLs.

  • Change the WordPress Address and Site Address in Settings > General to use https://
  • Use a plugin such as Really Simple SSL only if you cannot edit server settings directly
  • Search and replace internal HTTP links in the database if needed
  • Regenerate XML sitemaps so they list HTTPS URLs

For large sites, use a database-aware search and replace tool rather than editing content manually.

How to redirect HTTP to HTTPS on other platforms

Many managed hosts and site builders offer a one-click HTTPS redirect or force-SSL toggle.

The exact steps vary, but the goal is the same: ensure every HTTP request returns a 301 response to the secure URL.

cPanel and Plesk

These control panels often include SSL management tools and redirect options.

Enable the certificate first, then use the redirect feature or custom rewrite rules to force HTTPS.

Cloudflare

If you use Cloudflare, enable Always Use HTTPS and verify SSL mode is set correctly.

Flexible SSL can cause redirect loops if your origin server also forces HTTPS incorrectly, so Full or Full (strict) is usually the better choice.

Shopify, Wix, and Squarespace

Hosted platforms typically manage HTTPS automatically.

Your main task is to ensure custom domains are connected correctly and that all internal links, apps, and embeds use secure URLs.

What type of redirect should you use?

Use a 301 redirect for permanent HTTP to HTTPS migration.

A 301 tells browsers and search engines that the change is permanent and helps transfer ranking signals to the secure version.

A 302 redirect is temporary and is usually the wrong choice for a site-wide HTTPS migration.

Temporary redirects can slow canonical consolidation and make it harder for search engines to settle on the preferred URL.

How to avoid SEO problems after the redirect

Redirecting HTTP to HTTPS is only part of the migration.

To preserve organic visibility, every major signal should consistently point to the secure version.

  • Update XML sitemaps to list HTTPS URLs only
  • Change canonical tags to HTTPS
  • Revise robots.txt references if they contain absolute URLs
  • Update Open Graph and Twitter Card URLs
  • Refresh backlinks you control, such as social profiles and directory listings

It is also important to monitor Google Search Console after the migration.

Check indexing coverage, page experience data, and crawl errors for signs that search engines are still discovering HTTP URLs.

How to test whether HTTP to HTTPS redirect is working

Testing confirms that your redirect is permanent, consistent, and free of loops.

Start with a simple browser test, then verify the response code with a header checker or command-line tool.

What should you check?

  • HTTP URLs return a 301 status code
  • The destination URL begins with https://
  • WWW and non-WWW versions redirect consistently
  • No redirect chains add extra hops
  • Mixed content warnings do not appear in the browser console

You can also use curl -I http://example.com to inspect headers and confirm that the server returns the expected redirect response.

Common redirect mistakes to avoid

Many HTTPS migrations fail because of small configuration issues rather than the redirect itself.

Avoid these common errors to keep the transition clean.

  • Redirect loops: often caused by conflicting server, CMS, or CDN rules
  • Mixed content: secure pages loading images, scripts, or fonts over HTTP
  • Redirect chains: HTTP to www to HTTPS to non-WWW can waste crawl budget
  • Canonical conflicts: pages that point to HTTP while redirects point to HTTPS
  • Partial coverage: redirecting only the homepage instead of the full site

A good implementation redirects every HTTP URL directly to its HTTPS equivalent in a single hop.

When to involve your hosting provider or developer

If your site uses a custom application, load balancer, reverse proxy, or multisite architecture, the redirect logic may need coordination across several layers.

In those cases, involve your hosting provider or web developer to prevent duplicated rules or certificate mismatches.

Enterprise setups may also need HSTS, load balancer configuration, and DNS checks to ensure the secure version is enforced consistently across subdomains and regional endpoints.