# How to Redirect HTTP to HTTPS Using .htaccess
After you install an SSL certificate, the job is only half done. Visitors can still reach your site over an insecure `http://` connection unless you actively send them to `https://`. The most common way to do that on an Apache-based host is with a small set of rules in an `.htaccess` file. This guide walks through what the file is, where to find it, the exact redirect code to paste, and how to avoid the pitfalls that turn a five-minute task into an afternoon of troubleshooting.
## What Is an `.htaccess` File?
An `.htaccess` file is a plain-text configuration file that Apache (and Apache-compatible web servers such as LiteSpeed) reads on every request. Its filename is literally `.htaccess` — a dot-prefixed, extension-less name — and it lives in the directory it controls, usually the web root.
Because the server evaluates the file per request, `.htaccess` lets you override global server settings at the directory level without touching the main server configuration. That makes it the go-to place for redirects, URL rewriting, access control, and a range of other server behaviors.
If you run a content management system such as WordPress, the platform almost certainly created an `.htaccess` file for you during installation. You will typically find it inside the `htdocs`, `public_html`, or `www` folder of your hosting account.
## Why Redirect HTTP to HTTPS?
Even with a valid certificate installed, leaving HTTP accessible creates two problems:
– **Security:** Plain HTTP traffic can be read or modified in transit. Login cookies, form submissions, and personal data all travel in the clear.
– **SEO and trust:** Search engines treat `http://` and `https://` as separate URLs. Without a redirect, you split link equity, risk duplicate-content issues, and show browsers a “Not Secure” warning that erodes visitor confidence.
A 301 redirect tells clients and crawlers that the HTTPS version is the permanent home of every page. It passes link value forward and ensures no one ever lands on the insecure URL again.
## Step 1 — Locate or Create the `.htaccess` File
**If the file already exists** (common with WordPress and most CMS installs), open it directly. You will usually find it in your website’s web-root folder — `htdocs` on many shared hosts, `public_html` on cPanel accounts.
**If the file does not exist**, create it yourself. The recommended method is your hosting provider’s file manager (e.g., cPanel File Manager), because some local operating systems — especially Windows — handle dot-prefixed filenames poorly and may refuse to create or rename a file named `.htaccess` without an extension.
Create a new file named exactly `.htaccess` (no leading “file” or trailing “.txt”) and save it in the same web-root folder where your `index.php` or `index.html` lives.
## Step 2 — Add the Redirect Rules
Open the `.htaccess` file in the file manager or in any plain-text editor (Notepad, VS Code, nano, etc.). Add the following block of code:
“`apache
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:CF-Visitor} !{“scheme”:”https”}
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
“`
Save the file and upload it back to the server if you edited it locally.
### What Each Line Does
| Line | Purpose |
| — | — |
| `RewriteEngine On` | Enables Apache’s URL-rewriting engine, which is required for any rewrite rule to take effect. |
| `RewriteCond %{HTTP:X-Forwarded-Proto} !https` | Detects requests that arrived over HTTP behind a proxy or load balancer (common on cloud and CDN setups). |
| `RewriteCond %{HTTPS} off` | Catches requests where the direct connection to the server is not encrypted. |
| `RewriteCond %{HTTP:CF-Visitor} !{“scheme”:”https”}` | Handles requests routed through Cloudflare, which reports the original scheme in the `CF-Visitor` header. |
| `RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]` | Performs the permanent (301) redirect, preserving the host name and the full path/query string. |
The three `RewriteCond` lines use OR-style logic: the redirect fires if **any** of the conditions matches an insecure request. This makes the snippet robust across standard, proxied, and Cloudflare-fronted environments.
> **Source:** This redirect snippet is adapted from a community reference published on the InfinityFree support forum (https://forum.infinityfree.com/docs?topic=49322).
## Step 3 — Test the Redirect
1. Open a new private/incognito browser window.
2. Type your site’s plain HTTP URL, for example `http://example.com/some-page/`.
3. Confirm the address bar switches to `https://` and the page loads normally.
4. Use a redirect-checker tool or your browser’s network panel to confirm the response is a **301** (Moved Permanently), not a 302 or 307.
If everything resolves correctly, your site is now enforcing HTTPS.
## Before You Begin: A Quick Checklist
Technical tutorials are easiest to follow when you first confirm your environment. Different server versions, control panels, and plugin combinations can change where a setting lives or how a command behaves. Before editing any file:
– **Confirm your server software.** This method requires Apache or an Apache-compatible server (LiteSpeed, OpenLiteSpeed). If you are on **Nginx**, `.htaccess` is not used at all — redirects are configured directly in the server block (e.g., a `return 301 https://$host$request_uri;` directive).
– **Check your SSL certificate.** The redirect only helps if HTTPS actually works. Browse to your site over `https://` manually first; if you get a certificate error, install or renew your certificate before adding the redirect rules.
– **Back up the file.** Copy the current `.htaccess` to a safe location (e.g., `.htaccess.bak`) before changing it. On WordPress sites, consider a full database and files backup as well.
– **Verify permissions.** Make sure your hosting user has write access to the web-root folder.
– **Test incrementally.** After each change, check the site in a fresh browser window. Don’t stack five edits and then try to figure out which one broke things.
## Common Problems and How to Fix Them
### “Too many redirects” (ERR_TOO_MANY_REDIRECTS)
This loop usually means your site sits behind a proxy or CDN that terminates TLS for you, but your redirect conditions don’t account for it. Make sure all three `RewriteCond` lines are present, especially the `X-Forwarded-Proto` and `CF-Visitor` checks. On WordPress, also confirm that the **Site Address (URL)** and **WordPress Address (URL)** in *Settings → General* both start with `https://`.
### The redirect does nothing
Verify that `mod_rewrite` is enabled on the server. On shared hosting it almost always is; on a VPS you may need to run `sudo a2enmod rewrite` and restart Apache. Also confirm the file is named `.htaccess` (not `.htaccess.txt`) and located in the correct web-root directory.
### WordPress overwrites your rules
Some plugins regenerate the `.htaccess` file and can wipe custom additions. Keep a copy of your redirect block and re-add it after any permalink save or security-plugin reconfiguration.
## After the Fix: Keep Good Records
Solving this once doesn’t guarantee it stays solved. Host migrations, certificate renewals, plugin updates, and theme changes can all silently undo a redirect. Take a moment to document:
– The exact code you added and where.
– The date of the change.
– The verification result (URL tested, expected 301 response).
– Any server or plugin versions in play.
When you later move to a new host or upgrade your stack, those notes will save you a long debugging session.
## Frequently Asked Questions
**Do I need a plugin for this on WordPress?** No. A few lines in `.htaccess` handle it at the server level, which is faster and more reliable than a PHP-based plugin. Plugins can still be useful if your host does not allow `.htaccess` overrides, but check with your provider first.
**Will the redirect hurt my SEO?** The opposite. A proper 301 redirect consolidates your pages onto the secure URL, prevents duplicate-content problems, and aligns with what search engines now expect by default.
**What about `www` vs non-`www`?** This snippet preserves whichever host the visitor typed. If you also want to normalize between `www` and non-`www`, add a separate canonicalization rule or set it through your host’s control panel.
**Is the `CF-Visitor` line necessary if I don’t use Cloudflare?** No. Leaving it in does no harm, but you can safely remove the `CF-Visitor` condition if your traffic never passes through Cloudflare.
—
*This guide covers the standard Apache `.htaccess` approach. Server software, control-panel versions, and hosting environments change over time — always test after editing configuration files and keep a backup so you can roll back quickly.*
