Back up the domain’s .htaccess and record existing application redirects. If a CDN or reverse proxy terminates TLS, confirm how the origin recognises secure requests before adding a direct-origin rule.

1. Open File Manager for the correct domain and navigate to its actual public directory.
2. Open the existing .htaccess rather than replacing the entire file. Keep the application’s managed rewrite block intact.
3. For a direct Apache HTTPS connection, add the example below above the application rules, replacing example.com with the chosen canonical hostname. Start with a temporary redirect while testing.
4. Test HTTP requests for the homepage, a nested page and a URL with a query string. Confirm they reach the corresponding HTTPS URL without a loop.
5. Once verified, change the redirect status to 301 if the move is permanent. Update internal URLs and test forms, login and external integrations.

There should be a short, intentional redirect path ending on valid HTTPS content. Check both www and non-www entry points that customers may use.

Restore the previous file if a redirect loop or server error appears. A proxied connection needs a configuration appropriate to that trusted proxy; blindly trusting an arbitrary forwarded header can produce incorrect security decisions.

The request URI retains the path, and the existing query string is carried through when the substitution does not replace it. Test application-specific redirects before making the response permanent.

• Requesting a Let’s Encrypt certificate in SiteWorx
• Using SiteWorx advanced .htaccess controls carefully
• Fixing a Cloudflare HTTPS redirect loop
• Installing a separately issued certificate in SiteWorx

• InterWorx: HTTP To HTTPS Redirect With .htaccess
• Apache HTTP Server: Flags