How to redirect HTTP to HTTPS in htaccess
If you want to force secure browsing on an Apache site, learning how to redirect HTTP to HTTPS in htaccess is one of the most useful server-side fixes you can make.
Done correctly, it protects data in transit, improves user trust, and supports modern SEO expectations.
The challenge is that a small .htaccess mistake can create redirect loops, mixed content warnings, or broken canonical URLs, so it helps to understand the exact rules before deploying them.
Why HTTPS redirection matters
HTTPS uses TLS encryption to protect traffic between a browser and your web server.
Search engines such as Google have long treated HTTPS as a ranking signal, and modern browsers label non-secure pages as unsafe or “Not Secure.”
Redirecting all HTTP requests to HTTPS ensures users always land on the secure version of your site.
It also helps consolidate crawl signals, which matters when you want a single canonical URL for each page.
- Protects login credentials, forms, and session cookies
- Reduces the risk of interception on public networks
- Improves trust in browsers and email-linked landing pages
- Helps search engines index the preferred HTTPS version
Before you edit .htaccess
.htaccess is an Apache configuration file that controls rules at the directory level.
It only works if the Apache server allows overrides with AllowOverride, and it should be placed in the document root or the relevant directory.
Before changing anything, make sure your SSL certificate is already installed and working.
If HTTPS is not valid yet, a redirect will send users to an error page or certificate warning.
- Back up the existing .htaccess file
- Confirm the site loads over
https://without errors - Check whether your host uses Apache, LiteSpeed, or an Apache-compatible stack
- Identify whether WordPress, Laravel, or another app writes to .htaccess automatically
Basic .htaccess redirect for all traffic
The most common approach is to place a rewrite rule near the top of the file.
This version redirects every HTTP request to the same URI on HTTPS.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>This snippet uses Apache’s mod_rewrite module.
The RewriteCond checks whether HTTPS is off, and the RewriteRule sends the browser to the secure version with a permanent 301 redirect.
What each line does
<IfModule mod_rewrite.c>prevents errors if rewrite support is unavailableRewriteEngine Onenables rewrite processing for the directoryRewriteCond %{HTTPS} !=onmatches requests that are not already secureRewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]redirects to the same host and path over HTTPS
Alternative rule for shared hosting and proxies
Some hosting environments sit behind a reverse proxy, load balancer, or CDN such as Cloudflare.
In those cases, the %{HTTPS} variable may not always reflect the visitor’s original connection correctly.
If your host recommends checking the forwarded protocol header, use a rule like this:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>Use this only if your infrastructure actually sets X-Forwarded-Proto.
On a standard single-server Apache setup, the simpler HTTPS condition is usually enough.
Redirect only one domain version
If your site has multiple hostnames, such as example.com and www.example.com, it is best to combine HTTPS enforcement with a single preferred domain.
Otherwise, search engines may see duplicate versions.
Example: force all traffic to https://www.example.com.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]
</IfModule>This rule sends both insecure and non-preferred hostnames to one canonical destination.
If your preferred version is non-www, replace www.example.com accordingly.
WordPress-specific placement tips
For WordPress, place the redirect code above the block marked by # BEGIN WordPress.
WordPress may rewrite URLs internally, so placing custom redirect logic below that block can cause conflicts or be overwritten by updates.
Typical WordPress sites also need matching settings in the admin dashboard under Settings > General, where both the WordPress Address and Site Address should use https://.
- Keep the HTTPS redirect above WordPress-generated rules
- Update internal links, menus, and hardcoded image URLs
- Check plugins that generate absolute URLs
- Verify your sitemap uses HTTPS URLs
Avoiding redirect loops
A redirect loop happens when the browser is sent between HTTP and HTTPS repeatedly.
The most common causes are overlapping rules, a proxy configuration mismatch, or a CDN forcing HTTPS while Apache also misdetects the request scheme.
To troubleshoot, inspect the browser’s network tab or use a command-line request to see where the redirect points.
If a CDN is in front of the server, confirm whether it should handle the redirect at the edge instead of Apache.
Common causes of loops
- Both the CDN and .htaccess are forcing the same redirect in incompatible ways
- The server sees HTTPS differently because SSL terminates at a proxy
- Multiple rewrite blocks conflict with each other
- Old CMS rules still reference the HTTP version
Testing the redirect after deployment
After updating .htaccess, test both the root URL and a deep page URL.
The secure page should load directly with a 301 status, and the destination should preserve the path and query string.
You can verify with tools such as curl -I http://example.com/page, browser developer tools, online redirect checkers, or server logs.
Look for a clean single-hop redirect rather than a chain of multiple 301s.
- HTTP returns 301 Moved Permanently
- HTTPS returns 200 OK
- No mixed content warnings appear in the browser
- Canonical tags point to HTTPS URLs
SEO and technical details that matter
A 301 redirect tells search engines that the HTTP URL has permanently moved to HTTPS.
Over time, ranking signals and backlinks should consolidate to the secure version, but this works best when every related signal is also updated.
That means updating XML sitemaps, canonical tags, hreflang annotations, Open Graph URLs, structured data references, and any internal links generated by templates or plugins.
If any of those still point to HTTP, you may see duplicate crawl paths or mixed content issues.
Checklist for a clean migration
- Install a valid TLS certificate
- Force HTTP to HTTPS with a 301 redirect in .htaccess
- Update canonical and alternate language URLs
- Replace HTTP assets in CSS, JavaScript, and HTML
- Submit the HTTPS property in Google Search Console
- Monitor crawl errors and server logs after launch
When .htaccess is not the best place
.htaccess is convenient, but it is not always ideal for every stack.
On Nginx, redirects are configured in server blocks instead of .htaccess.
On platforms using managed edge security, a control panel or CDN rule may be cleaner and faster.
If your host recommends handling HTTPS redirects at the server or CDN layer, follow that guidance.
Centralized redirect management can reduce per-request overhead and simplify troubleshooting.
Quick reference example
If you need a simple, widely compatible rule for Apache, this is the version most site owners start with:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>Use it as the basis for a full migration, then verify the redirect, clean up internal links, and confirm that all traffic lands on the secure canonical URL.