Forcing HTTPS on your website ensures that every visitor is automatically sent to the secure version of your pages. This protects login forms, contact forms, checkout pages, and all other data exchanged between the browser and your site. It also helps avoid duplicate content issues, mixed signals for search engines, and “Not secure” warnings that can reduce trust and conversions.
If your website already has a valid SSL certificate installed, the next step is to make sure all traffic uses HTTPS consistently. In a hosting or control panel environment, this usually means setting up a redirect from HTTP to HTTPS, checking your application settings, and making sure internal links and resources also load securely.
Why forcing HTTPS matters
SSL/TLS encrypts traffic between the visitor and the server. However, encryption only helps if users actually reach the secure version of your website. Without a redirect in place, some visitors may still land on http:// URLs through old bookmarks, shared links, search results, or manually typed addresses.
Forcing HTTPS gives you several practical benefits:
- Better security: login details, personal data, and form submissions stay encrypted.
- Improved trust: browsers display the secure connection as expected, without warning messages.
- Cleaner SEO signals: search engines see one canonical secure version of each page.
- Fewer duplicate URLs: http:// and https:// versions do not compete with each other.
- Better compatibility: modern browsers and services expect secure connections by default.
In managed hosting environments, HTTPS enforcement is often part of the standard website security setup. If it is not enabled automatically, you can usually configure it through the control panel, web server rules, or the CMS itself.
Before you force HTTPS
Make sure the following items are ready before applying redirects:
- An active SSL certificate installed for the domain and any required subdomains.
- The certificate is valid and not expired.
- Your website opens correctly over https:// without certificate warnings.
- You know whether your site is served by Apache, Nginx, or both.
- You have access to your hosting control panel, such as Plesk, or to the site configuration files if needed.
If the SSL certificate is not yet installed, fix that first. A redirect from HTTP to HTTPS will not solve certificate problems. In fact, it may make them more visible if the secure destination is broken.
How to force HTTPS in Plesk
In Plesk, the process is usually straightforward. Depending on the hosting setup, you may have a built-in option to redirect all HTTP traffic to HTTPS.
Use the hosting control panel
- Log in to Plesk.
- Open the website or domain settings.
- Look for the option related to HTTPS redirection or Force permanent SEO-safe 301 redirect from HTTP to HTTPS.
- Enable the setting and save the changes.
This creates a permanent redirect, which is usually the correct choice for a live website. It tells browsers and search engines that the secure version is the preferred address.
Check the web server configuration
Some hosting plans use Nginx as a reverse proxy in front of Apache. In that case, the control panel setting may generate the correct redirect automatically. If not, the rule can be added at the web server level. The exact method depends on your hosting environment and permissions.
After enabling the redirect, test:
- http://yourdomain.com
- http://www.yourdomain.com
Both should send visitors to the matching https:// version without an extra manual step.
How to force HTTPS in Apache
If your site runs on Apache and you have access to the site configuration or .htaccess, you can add a redirect rule. This is a common approach for shared hosting and many managed hosting plans.
Redirect all HTTP traffic to HTTPS
A simple Apache rule in .htaccess can look like this:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
This rule checks whether the request is already secure. If not, it redirects to the same URL on HTTPS using a 301 permanent redirect.
Preserve domain variations
If your site uses both the non-www and www versions, decide which one should be the primary hostname. Then make sure both HTTP variants redirect to the same HTTPS canonical version. For example:
- http://example.com → https://example.com
- http://www.example.com → https://example.com
Consistency matters for SEO and user experience. If both hostnames remain active, search engines may treat them as separate URLs unless the redirects are configured carefully.
How to force HTTPS in Nginx
If your server uses Nginx, the redirect is usually defined in the server block that listens on port 80.
A typical configuration pattern is:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
This sends all HTTP requests to the secure version. If your preferred hostname is the www version, change the destination accordingly.
On many hosting platforms, you may not edit Nginx directly. In that case, use the control panel option or ask support to apply the redirect at the server level.
How to force HTTPS in WordPress
If your website runs on WordPress, forcing HTTPS requires both a redirect and the correct site URLs in WordPress settings.
Update the WordPress Address and Site Address
In the WordPress admin area, go to Settings and then General. Make sure both of these fields use https://:
- WordPress Address (URL)
- Site Address (URL)
If these values still use http://, the site may redirect in unexpected ways or keep generating insecure links.
Add a redirect at server level
For WordPress sites, it is usually better to enforce HTTPS at the web server or control panel level rather than relying only on a plugin. Server-level redirects are faster, cleaner, and less dependent on application behavior.
Check insecure resources
After forcing HTTPS, inspect the front end for mixed content. Common problem areas include:
- Images loaded from old http:// URLs
- Stylesheets or JavaScript files referenced insecurely
- Embedded fonts, videos, or iframes from non-secure sources
- Hard-coded links in theme files or page builders
If the browser still shows a warning, mixed content is often the reason.
Common redirect methods and when to use them
The right method depends on your hosting stack and your level of access.
- Control panel redirect: best for most hosting users and managed hosting accounts.
- .htaccess redirect: useful on Apache-based hosting with file access.
- Nginx server block redirect: best for Nginx or reverse proxy setups.
- CMS setting or plugin: helpful, but usually not the only step.
In a managed hosting environment, the control panel is often the safest place to start. It reduces the risk of syntax errors and keeps the redirect aligned with the rest of the hosting configuration.
How to avoid redirect loops
A redirect loop happens when the browser is sent back and forth between HTTP and HTTPS, or between www and non-www versions. This usually happens because of conflicting rules in more than one place.
Typical causes include:
- Redirects in both the control panel and
.htaccess - CMS settings still pointing to http://
- Proxy or load balancer headers not being interpreted correctly
- Conflicting www and non-www redirects
If you see a “too many redirects” error, review all redirect layers one by one. Keep the setup simple: one preferred hostname, one HTTPS redirect rule, and one canonical destination.
How to test whether HTTPS is forced correctly
After making the change, test it carefully.
Manual checks
- Open http://example.com in a browser and confirm it goes to https://example.com.
- Test both the root domain and key internal pages.
- Check the www and non-www versions if both are used.
- Refresh pages with forms, login areas, or shopping cart functionality.
Technical checks
- Verify that the redirect uses a 301 status code.
- Confirm that the secure page returns a normal 200 response.
- Inspect the browser address bar for the lock icon or secure connection indicator.
- Use browser developer tools to check for mixed content warnings.
If you manage multiple pages, a crawler or SEO tool can help verify that all HTTP URLs now resolve to HTTPS correctly.
Mixed content after enabling HTTPS
Forcing HTTPS does not automatically fix every resource on the page. Mixed content occurs when the main page is loaded over HTTPS, but some assets still load over HTTP.
This can happen with:
- Old links stored in the database
- Theme or template files containing hard-coded URLs
- Third-party scripts or widgets that still use HTTP
- External resources that do not support HTTPS
To resolve mixed content:
- Replace insecure internal links with HTTPS versions.
- Update the site database if your CMS stores full URLs.
- Use relative paths where appropriate.
- Remove or replace third-party assets that do not support secure delivery.
In a hosting support context, mixed content is one of the most common reasons a site still appears insecure even after SSL is installed correctly.
SEO considerations when forcing HTTPS
Search engines generally prefer secure websites. Once HTTPS is enabled, make sure your site sends clear signals so indexing remains stable.
- Use 301 redirects from HTTP to HTTPS.
- Set the HTTPS version as the canonical URL.
- Update internal links to use HTTPS.
- Regenerate your XML sitemap with HTTPS URLs.
- Submit the secure version in search engine webmaster tools if needed.
It is also important to avoid changing multiple URL patterns at the same time unless necessary. For example, do not switch from HTTP to HTTPS and from non-www to www in several separate steps if you can consolidate them into one clean redirect path.
Best practices for hosting environments
To keep HTTPS enforcement reliable over time, follow these best practices:
- Renew SSL certificates before they expire.
- Keep one preferred canonical hostname.
- Use server-level redirects where possible.
- Check new plugins, themes, or scripts for insecure URLs.
- Test after major site changes, migrations, or DNS updates.
If your hosting platform offers automatic SSL provisioning and HTTPS redirect settings, use them. These features reduce manual work and lower the chance of misconfiguration.
Frequently asked questions
Is a 301 redirect the right choice for HTTP to HTTPS?
Yes. A 301 redirect is the standard choice for permanently moving visitors from HTTP to HTTPS. It tells browsers and search engines that the secure version should be used going forward.
Will forcing HTTPS improve SEO?
HTTPS itself is not a major ranking shortcut, but it helps search engines understand that your site is secure and properly configured. It also avoids duplicate URL issues and supports a better user experience, which can help indirectly.
Can I force HTTPS without changing my website code?
Yes, in many cases. You can enforce HTTPS at the hosting control panel, Apache, or Nginx level. That is usually the cleanest approach because it catches all requests before the application loads.
Why does my site still show “Not secure” after enabling HTTPS?
Most often this is caused by mixed content, an expired certificate, or a page still loading a resource over HTTP. Check the browser console and inspect the page source for insecure links.
Should I force HTTPS on every page?
Yes, if your website has an SSL certificate installed and supports HTTPS properly. In modern hosting environments, the secure version should be the default for the entire site.
What if I use Cloudflare or another proxy?
If a proxy or CDN sits in front of your hosting account, make sure the SSL settings are aligned on both sides. Otherwise, redirects may loop or the origin server may not detect HTTPS correctly.
Conclusion
Forcing HTTPS is one of the most important steps after installing an SSL certificate. It ensures that visitors always use the secure version of your website, improves trust, and helps search engines treat your URLs consistently. In most hosting and control panel environments, the safest approach is to set a permanent 301 redirect, confirm that the preferred domain is consistent, and check for mixed content after the change.
If you are using a managed hosting platform, Plesk, Apache, or Nginx, the exact implementation may differ, but the goal is always the same: one secure, canonical version of your site that loads cleanly over HTTPS.