HTTP to HTTPS Redirect: How to Set It Up and Test It

An HTTP to HTTPS redirect sends every visitor and search engine that requests the insecure http:// version of a page straight to the secure https:// version, using a permanent 301 redirect in a single hop. You set it up at server, CDN or hosting level, then test it with a redirect checker or curl.

Key takeaways

• Use a permanent, server-side redirect (301 or 308), never a JavaScript or meta refresh redirect, for the HTTP to HTTPS move.
• Every old URL should reach its final HTTPS address in one hop, including the www and non-www variants.
• Set the redirect in one place only (server, Cloudflare or hosting panel) to avoid loops and chains.
• Add HSTS only after the redirect has worked without problems for a while.
• Update internal links, canonical tags and your XML sitemap so they point at HTTPS directly.

What is an HTTP to HTTPS redirect and why does it matter for SEO?

An HTTP to HTTPS redirect is a server instruction that says “this page now lives at the secure address”, so browsers and Google move to the HTTPS URL automatically. Without it, your site can exist twice: once on HTTP and once on HTTPS.

That duplication causes real problems. Backlinks pointing at the old HTTP address may not pass their full value to the pages you want ranked, Google may index the wrong version, and visitors who type your domain without “https” may see a “Not secure” warning in Chrome. For a business site, that warning alone is enough to lose an enquiry.

A 301 redirect is a permanent redirect status code. According to Google’s Search Central documentation on redirects, permanent server-side redirects such as 301 and 308 are the strongest signal that the target URL should become the canonical one shown in search results. That is exactly what you want when moving to HTTPS.

How do I check if my site already redirects HTTP to HTTPS?

Type your domain with http:// in front of it into a browser and see whether the address bar switches to https://. Then repeat the test for the www and non-www versions and for an inner page, because many sites only redirect the home page.

Check these four starting points for your home page and at least one deep URL, such as a service page or blog post:

1. http://example.com/
2. http://www.example.com/
3. https://example.com/
4. https://www.example.com/

Three of these should redirect to the fourth (whichever version you have chosen as the main one), and the fourth should load with a 200 status. If you want a quick overall picture before you start, run your domain through my free SEO audit tool. It flags HTTPS issues alongside other technical problems, so you can see what else needs fixing while you are in the server settings.

How do I set up an HTTP to HTTPS redirect?

You set up the redirect in one layer of your stack: the web server (Apache or Nginx), a CDN such as Cloudflare, or a toggle in your hosting control panel. Before you start, make sure a valid SSL certificate is installed and HTTPS pages load correctly, otherwise the redirect will send people to an error page.

Option 1: Apache (.htaccess)

Most shared hosting in India runs Apache or LiteSpeed, which both read the .htaccess file in your site’s root folder. Back up the file first, then add these lines near the top, above the WordPress block:

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

This sends any non-HTTPS request to the same host and path on HTTPS. If you also want to force one hostname (for example always www), combine both rules so the redirect goes straight to https://www.example.com/ rather than taking two steps.

Option 2: Nginx

On a VPS or cloud server running Nginx, add a separate server block that listens on port 80 and returns a permanent redirect:

server {

listen 80;

server_name example.com www.example.com;

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

}

Using return with a fixed hostname keeps it to a single hop. Test the configuration with nginx -t before reloading, so a typo does not take the site offline.

Option 3: Cloudflare

If your domain uses Cloudflare, go to SSL/TLS, then Edge Certificates, and switch on “Always Use HTTPS”. Set the SSL/TLS encryption mode to Full or Full (strict), not Flexible, if your server has its own certificate. I explain why in the mistakes section below.

Option 4: Hosting control panel

Many hosts offer a “Force HTTPS” switch. In cPanel it usually sits under Domains, and other panels have something similar in their SSL section. This is the easiest route for non-technical owners, but check that it creates a 301 and not a 302.

WordPress note

In WordPress, go to Settings, then General, and change both “WordPress Address (URL)” and “Site Address (URL)” to start with https://. This makes WordPress generate HTTPS links. It does not redirect old HTTP requests on its own, so you still need one of the options above or an SSL plugin that adds the redirect.

Which method should I choose?

Choose the layer you control most reliably and use only that one. Stacking several methods is the most common cause of loops and chains that I find.

Method	Best for	Watch out for
Apache / LiteSpeed .htaccess	Shared hosting, most WordPress sites	Plugins or updates overwriting the file; rule placed below the WordPress block
Nginx server block	VPS and cloud servers	Forgetting the www host; not testing config before reload
Cloudflare “Always Use HTTPS”	Sites already proxied through Cloudflare	Flexible SSL mode causing redirect loops
Hosting “Force HTTPS” toggle	Owners without server access	Some panels use 302; check the status code
WordPress SSL plugin	Quick fix when nothing else is possible	Duplicating a server rule; redirect lost if plugin is removed

How do I test the redirect properly?

A proper test confirms three things: the status code is 301 (or 308), there is only one hop, and the final page returns 200. A browser alone will not show you this, because it follows redirects silently.

1. Use curl. On a Mac, Linux or Windows terminal, run curl -I http://example.com/. Look for HTTP/1.1 301 and a Location: header pointing at the HTTPS URL.
2. Follow the chain. Run curl -sIL http://example.com/about/. Each block in the output is one hop. You want two blocks: the 301 and the final 200.
3. Test deep URLs. Pick a blog post, a page with a query string (for example ?ref=whatsapp) and an image URL. The path and parameters should be preserved.
4. Check Search Console. Use the URL Inspection tool on the HTTP version of a key page. Over time, Google should report the HTTPS URL as the canonical.
5. Crawl the site. A crawler such as Screaming Frog (free up to 500 URLs) will list any internal links still pointing at HTTP, and any chains.

Example (illustrative): imagine a site that returns http://example.in → https://example.in → https://www.example.in. It works in the browser, but every request takes two hops. Changing the rule to send all HTTP requests directly to https://www.example.in fixes it in one line.

What are the most common HTTP to HTTPS redirect mistakes?

The most common mistakes are redirect loops, redirect chains, using temporary redirects, and leaving internal links on HTTP. Each one is easy to fix once you know where to look.

Problem	Typical cause	Fix
“Too many redirects” error	Cloudflare Flexible SSL plus a server redirect to HTTPS	Switch Cloudflare to Full (strict) or remove the server rule
Redirect chain (2+ hops)	HTTP and www rules applied separately	Redirect straight to the final host on HTTPS
302 instead of 301	Hosting toggle or plugin default	Change the rule to R=301 or return 301
Only the home page redirects	Rule written for “/” only	Use a pattern that captures the full path
Mixed content warnings	Images, scripts or CSS loaded over HTTP	Update URLs in the database and theme files
Internal links still on HTTP	Old content and menus never updated	Search and replace HTTP links with HTTPS

The Cloudflare loop deserves a fuller explanation. In Flexible mode, Cloudflare talks to your server over plain HTTP. Your server sees an HTTP request and redirects to HTTPS, Cloudflare fetches it over HTTP again, and the cycle repeats. Cloudflare’s own troubleshooting guide for too many redirects covers this case and recommends changing the encryption mode.

Redirect chains also waste crawl effort and slow down visitors on mobile data. If you have older redirects from previous URL changes, my guide on finding and fixing broken links shows how to spot and clean up links that point to redirected or missing pages.

Should I enable HSTS after the redirect?

Yes, but only once the redirect has run without issues for a few weeks. HSTS (HTTP Strict Transport Security) is a response header that tells browsers to always use HTTPS for your domain, so they skip the insecure request entirely on later visits.

A typical header looks like this: Strict-Transport-Security: max-age=31536000; includeSubDomains. The max-age value is in seconds, so 31536000 is one year. Start with a short value, such as one day, to make sure nothing breaks, then increase it.

Be careful with includeSubDomains. If any subdomain (a mail panel, an old staging site, a booking system) does not have a working certificate, browsers will refuse to load it. Adding your domain to the browser preload list is harder to undo still, so treat it as a final step rather than a starting point.

What else should I update after moving to HTTPS?

After the redirect works, update everything that still points at the old HTTP address, so Google and visitors reach HTTPS directly instead of relying on the redirect. Redirects are a safety net, not a replacement for clean links.

• Canonical tags: every page should declare its HTTPS URL as canonical.
• XML sitemap: list only HTTPS URLs and resubmit it in Search Console.
• Internal links and menus: replace hard-coded HTTP links in content, widgets and theme files.
• Search Console: add the HTTPS property, or use a Domain property that covers both.
• Google Business Profile and social profiles: update the website link.
• Analytics and ad accounts: update the default URL so reports and landing pages match.

When I audit sites at TechnoSubrat, leftover HTTP links in sitemaps and canonical tags are among the issues I see most often after an HTTPS move. My technical SEO checklist for business websites lists these alongside other checks worth running after any site change. If your HTTPS move is part of a redesign or new build, it is worth getting it right in the website development stage rather than patching it later.

When should I get expert help?

Get help if you see “too many redirects” errors you cannot trace, if your site sits behind several layers (CDN, firewall, load balancer), or if traffic dropped after moving to HTTPS. These usually need someone who can read server responses and logs.

It is also worth a second opinion if your site has a long history of URL changes. Old redirect rules from previous migrations often stack up with the new HTTPS rule, and untangling them by trial and error can make things worse. For a wider view of how redirects fit into a full review, see my step-by-step guide on how to do an SEO audit.

What are the next steps for your site?

Start by running the four-URL test above on your home page and one inner page, then check the status codes with curl. Fix any loops or chains first, then update canonicals, the sitemap and internal links.

1. Run your domain through the free audit to see HTTPS and other technical issues in one report.
2. Choose one redirect method and remove any duplicates.
3. Test with curl -sIL until every variant reaches the final URL in one hop.
4. Update internal links, canonicals and the sitemap, then resubmit in Search Console.
5. Add HSTS with a short max-age, and increase it once you are confident.

If you would rather have it set up and checked for you, contact Subrat Patnaik with your domain and I will tell you what needs fixing.

Frequently asked questions