How to Redirect HTTP to HTTPS the Right Way (Without Loops)

Short answer: Redirect every HTTP request to the same path on HTTPS with a single permanent (301 or 308) redirect, done at the web server or CDN rather than in page code. The redirect should go straight to your preferred hostname (with or without www) in one hop, keep the full path and query string, and never send HTTPS traffic back to HTTP. Test it with curl and fix any redirect loops caused by proxies or CDN settings.

Installing an SSL certificate is only half the job. If people can still open your site over plain HTTP – because they typed the address without https://, followed an old link, or clicked a bookmark – they get the insecure version and Chrome labels it “Not secure”. A correct redirect sends everyone to HTTPS automatically. A careless one creates loops, chains or lost pages. This guide shows how to do it properly on the most common setups.

What a good HTTPS redirect looks like

A correct setup meets five conditions:

1. Every HTTP URL redirects, not just the home page. http://example.com/contact/?ref=ad must end up on https://example.com/contact/?ref=ad.
2. The redirect is permanent – status 301 or 308. Temporary codes (302, 307) tell search engines the move might be undone.
3. It takes one hop. http://www.example.com should go directly to the final address, not to https://www.example.com first and then to https://example.com.
4. HTTPS never points back to HTTP. Any rule that does so creates a loop or a downgrade.
5. The final page answers 200 with a valid certificate for that exact hostname.

Choose your preferred hostname first

Before writing rules, decide whether your canonical address is https://example.com or https://www.example.com. Either is fine; mixing them is not. The choice affects the redirect rules, your certificate (it must cover both names, because visitors will arrive on both), your CMS settings and your sitemap. Once chosen, all four variants should collapse into one:

Redirecting on Apache (.htaccess)

On shared hosting with Apache or LiteSpeed, add rules at the top of the .htaccess file in your web root. This example forces HTTPS and the non-www hostname in one step:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

%{REQUEST_URI} includes the path, and Apache keeps the query string automatically. If your site sits behind a proxy or load balancer that handles HTTPS, %{HTTPS} will always be “off” on the server, which causes a loop. In that case check the forwarded header instead, for example RewriteCond %{HTTP:X-Forwarded-Proto} !https.

Redirecting on Nginx

On Nginx, the cleanest method is a separate server block for plain HTTP that does nothing but redirect:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name www.example.com;
    # certificate directives here
    return 301 https://example.com$request_uri;
}

The main HTTPS server block for example.com then serves the site. Using return is faster and clearer than rewrite rules. After editing, run nginx -t to check the syntax before reloading.

If you use Certbot’s automatic configuration, it may already have added a redirect. Check that it does not create a second hop through www.

WordPress, hosting panels and CDNs

WordPress

In Settings → General, set both “WordPress Address” and “Site Address” to the HTTPS URL. WordPress will then build links with HTTPS, but it will not reliably redirect every request by itself; keep the server-level redirect as well. Plugins that force HTTPS can help on hosts where you cannot edit server rules, but a server rule is faster and less fragile. Old HTTP links inside posts should be replaced in the database, which also prevents mixed content.

Hosting panels

Many panels have a “Force HTTPS” or “HTTPS redirect” switch per domain. It usually writes the same rules shown above. Turn it on only after the certificate is valid for all names, otherwise visitors will be redirected straight into a certificate error.

CDNs and proxies

With a CDN in front of the site, you can redirect at the edge (for example Cloudflare’s “Always Use HTTPS” setting). This is efficient, but watch the SSL mode: if the CDN connects to your server over HTTP (“Flexible” mode) while your server redirects HTTP to HTTPS, every request loops forever. Use a mode where the CDN talks to your origin over HTTPS with a valid certificate.

Fixing redirect loops and chains

“Too many redirects” (ERR_TOO_MANY_REDIRECTS) is the most common problem after switching to HTTPS. Typical causes:

• Proxy or CDN sends HTTP to the origin, and the origin redirects to HTTPS again. Fix the CDN SSL mode or detect X-Forwarded-Proto.
• Two systems disagree on the hostname – the server redirects to non-www while the CMS redirects to www. Make them agree.
• Plugin and server both redirect with slightly different rules. Keep one.
• Cached redirects. Browsers cache 301 responses. Test in a private window or with curl after every change.

Chains are less dramatic but still worth fixing: each extra hop adds a round trip on mobile and dilutes signals. Aim for exactly one redirect from any variant to the final URL.

How to test your redirects

Use curl, which shows each step without browser caching:

curl -sI http://example.com/some/page/?x=1 | grep -i -E "^HTTP|^location"
curl -sIL http://www.example.com/ | grep -i -E "^HTTP|^location"

Check that the first response is 301 or 308, the Location header points to the final HTTPS URL with the same path and query string, and the last response is 200. Repeat for all four hostname variants and for a deep page, an image and a URL that should return 404 (it should still redirect to HTTPS first, then return 404).

After the redirect works everywhere, consider adding HSTS, which tells browsers to use HTTPS automatically on future visits. Add it only when you are sure every subdomain you include can serve HTTPS. The MDN reference on Strict-Transport-Security explains the options.

Update everything that still points to HTTP

A redirect catches old requests, but you should not rely on it for links you control. Every internal link that still uses HTTP costs visitors an extra round trip, and some resources loaded over HTTP will be blocked as mixed content. Once the redirect works, go through this list:

• Internal links and navigation menus – replace http:// with https:// in the database or templates, using a search-and-replace tool that handles serialized data if you use WordPress.
• Canonical tags and hreflang tags – they must point to the final HTTPS URLs, otherwise search engines receive conflicting signals.
• XML sitemaps – regenerate them so they list only HTTPS addresses, and submit the new sitemap in your search console.
• Images, scripts and fonts – hard-coded HTTP sources in themes, widgets or page builders cause mixed content warnings.
• External profiles and ads – update the website link in social profiles, business listings, e-mail signatures and advertising campaigns.
• Third-party tools – analytics, payment callbacks and webhooks sometimes store the full HTTP address and must be updated by hand.

Doing this once removes thousands of unnecessary redirects over the life of the site and makes the HTTPS version the only one anybody ever sees.

Common mistakes to avoid

• Redirecting only the home page, so deep links from other sites stay on HTTP.
• Redirecting everything to the home page instead of the same path.
• Using JavaScript or meta refresh redirects instead of a server response.
• Turning on “force HTTPS” before the certificate covers www and non-www.
• Forgetting canonical tags, sitemaps and internal links that still point to HTTP.
• Leaving an old HTTP-only subdomain (for example a forgotten landing page) that was never included.

How Site AI Audit checks your redirects

The connection step of a Site AI Audit check tests whether the HTTP version of your site redirects to HTTPS and whether the certificate is valid, and the crawl reports redirects and broken links it finds on up to 50 pages in the free check. Each finding comes with a plain-language explanation and a fix. It is a quick way to confirm that the rules you just wrote behave the way you expect for real visitors. Run a free check after you change your redirect rules.

Related reading

• What Is an SSL Certificate and Why Does Your Website Need One?
• SSL Certificate Expired: What Happens and How to Fix It Fast

The bottom line

A good HTTPS redirect is invisible: every old address lands on the same page over HTTPS in a single permanent hop. Pick one hostname, redirect at the server or CDN, preserve the path and query string, watch out for proxy-related loops, and test every variant with curl. Once that works, update internal links and consider HSTS.

FAQ

Should I use a 301 or 302 redirect for HTTPS?

Use a 301 or 308, because the move to HTTPS is permanent. A 302 or 307 signals a temporary move, so search engines may keep the HTTP URL as the main version for longer.

Why do I get “too many redirects” after enabling HTTPS?

Usually a proxy or CDN connects to your server over HTTP while the server redirects everything to HTTPS, so the request circles forever. Switch the CDN to an HTTPS mode or make the server check the X-Forwarded-Proto header.

Will redirecting to HTTPS hurt my search rankings?

A clean, permanent, page-to-page redirect is the method search engines recommend for moving to HTTPS. Short fluctuations can happen while pages are recrawled, but lasting losses usually come from mistakes such as redirecting everything to the home page.

Do I still need a server redirect if WordPress uses HTTPS URLs?

Yes. WordPress settings change the links it generates, but old HTTP links, bookmarks and direct requests for files still need a server or CDN rule to be redirected reliably.

Should the redirect keep the query string?

Yes. Query strings carry campaign tags, search terms and filters. Dropping them breaks tracking and can land visitors on the wrong content, so make sure the rule passes them through unchanged.