iFastHostingHow to force HTTPS on your website
A certificate being installed does not redirect anyone by itself. Here is the rule that sends every visitor to the secure version automatically.
Installing a certificate makes HTTPS available. It does not make HTTPS the only way to reach your site — until you add a redirect, the plain http:// version keeps working alongside the secure one, and anyone using an old link, a bookmark, or a search result that still points at the HTTP version lands there instead of the encrypted page. Forcing HTTPS closes that gap by redirecting every request to the secure address automatically.
Why this needs a separate step
A certificate and a redirect solve two different problems. The certificate makes encryption available to anyone who requests the HTTPS address. The redirect makes sure everyone ends up requesting it, including visitors who never typed https:// in the first place. Without the redirect, your site is technically capable of being secure but still serving a meaningful share of visitors an unencrypted page by default.
Test the https:// version of your site directly first. Redirecting everyone to a version that is not actually working correctly turns a minor inconvenience into every visitor seeing an error.
The redirect rule
On the great majority of hosting accounts, this is added to the .htaccess file in your site's root folder. Open it with the file manager in your control panel, or connect over FTP, and add the following near the top of the file, before other rewrite rules:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Reading it line by line: the first line turns on the rewrite engine if it is not already active elsewhere in the file. The condition checks whether the current request arrived over plain HTTP. The rule then rewrites any such request to the same host and path, but with https:// in front, and sends a 301 permanent redirect telling browsers and search engines this is now the correct address to use.
Do not add a second one — a file with more than one RewriteEngine On line is unusual but harmless; the redirect condition and rule are what matters, and they should sit above any existing rewrite rules for your CMS so the HTTPS check happens first.
Back up before you edit
A syntax error in .htaccess is one of the few mistakes on shared hosting capable of taking an entire site offline instantly, with a generic server error rather than a helpful message. Before making any change:
- Download or copy the current
.htaccessfile somewhere safe. - Make one change at a time rather than combining this with other edits.
- Load the site immediately after saving, so you know straight away whether the change caused a problem.
If the site does stop loading after a save, restore the backed-up file and it returns to exactly how it was before.
Testing it properly
Your own browser will often show the correct result even from a broken redirect, because it may already have the HTTPS version cached. Test properly instead:
- Open a private or incognito window, which starts with no cached state.
- Type the address starting with
http://explicitly, rather than letting the browser choose. - Confirm the address bar changes to
https://automatically and the page loads without warnings. - Repeat with an internal page, not just the homepage, since some CMS platforms handle their own routing in ways that can interact unexpectedly with server-level rewrite rules.
After the redirect is working
Two follow-up checks are worth doing once every request lands on HTTPS reliably.
First, check for mixed content warnings — pages that now load over HTTPS but still reference an image, script or stylesheet with a hardcoded http:// address, which shows as a broken padlock even though the redirect itself is working correctly.
Second, once you are confident HTTPS is stable and every visitor is reaching it, consider enabling HSTS, which tells browsers to skip the redirect entirely on future visits and go straight to HTTPS. That is covered in what HSTS is and in how to add security headers to your site, alongside the other headers worth setting at the same time.
If the redirect creates a loop instead
A redirect loop — the browser reporting too many redirects — usually means something downstream is undoing the redirect, most commonly a CMS setting or a caching layer that still thinks the site should be served over HTTP. Check your CMS's own site address setting matches https://, and clear any page cache after making the change, since a cached HTTP response can keep reappearing even after the server-side rule is correct.
Frequently asked questions
Will this break my website if something goes wrong?
A mistake in .htaccess can make the entire site inaccessible, which is why keeping a copy of the original file before editing matters. If the site stops loading after a change, restore the backup and the site returns to how it was.
Do I still need this if my CMS has an "always use HTTPS" setting?
Use both if available. A CMS-level setting affects links the CMS generates itself, but does not stop a visitor reaching the plain HTTP version directly through an old link, a bookmark, or a search result — only a server-level redirect does that.
Related reading
Free SSL is already included and issues itself automatically. This covers how to confirm it, speed it up, and add a certificate you bought separately.
What is HSTS?A header that tells browsers to never even attempt the insecure version of your site again, closing a gap a redirect alone leaves open.
How to fix mixed content warningsA secure page quietly loading an image, script or stylesheet over plain HTTP. Here is how to find every instance and fix it properly.
How to add security headers to your siteA handful of response headers close off entire categories of attack for very little effort. Here is what each does and how to add them.