An SSL certificate alone is not enough to ensure that browsers always use a secure connection. If a site is available over HTTP, an attacker may, in certain network scenarios, attempt to intercept the first request or redirect a user to an unsecured version of the page.
HSTS, or HTTP Strict Transport Security, tells the browser that the domain must be opened only over HTTPS. Below, we explain how to prepare WordPress, Elementor, the server and subdomains for HSTS, and why you should not rush to enable the preload parameter.
What HSTS Is and What It Protects Against
HSTS is a special HTTP header called Strict-Transport-Security. After receiving this header, the browser automatically changes requests to the domain from http:// to HTTPS for the specified period. Users do not need to enter the secure address manually each time.
The mechanism reduces the risk of downgrade attacks, in which a user is forced from HTTPS to HTTP. It also helps prevent the accidental opening of an unsecured version of the site through an old link.
HSTS does not install an SSL certificate, encrypt the server or replace HTTP-to-HTTPS redirects. The server must still process HTTP requests correctly and redirect them to the secure address. HSTS is an additional browser rule, not an alternative to basic HTTPS configuration.
- The browser stores the policy only after a successful HTTPS connection.
- Once enabled, HTTP requests to the domain may be automatically converted to HTTPS.
- If the certificate becomes invalid, the browser may block access instead of switching to HTTP.
- The HSTS policy is stored in the browser, so it cannot be quickly canceled for all visitors with a single server-side setting.
What Parameters the Strict-Transport-Security Header Has
The basic header contains the max-age parameter, which defines the period in seconds during which the browser applies the policy. For a production site, at least 15552000 seconds, or approximately 180 days, is commonly used. A standard long-term option is 31536000 seconds, or one year.
The includeSubDomains parameter extends the rule to all subdomains. Enable it only when every subdomain has working HTTPS and a valid certificate. This applies not only to the WordPress site, but also to mail services, testing environments, control panels, APIs, CDNs and other services hosted on subdomains.
The preload parameter is intended to add a domain to browser preload lists. It is not simply an “enhanced version” of HSTS: it requires additional conditions, including a long max-age, includeSubDomains and complete HTTPS availability for all subdomains. Correcting an erroneous preload submission can take a long time.
- Cautious start: Strict-Transport-Security: max-age=300
- After testing: Strict-Transport-Security: max-age=15552000
- For a stable domain: Strict-Transport-Security: max-age=31536000; includeSubDomains
- Add preload only after a separate audit of the domain and all its subdomains.
Preparing WordPress for Enforced HTTPS
Before adding HSTS, make sure WordPress uses the correct URLs. Both the WordPress Address and the Site Address must use https:// rather than http://. If an HTTP address remains in the configuration, database or proxy settings, it may cause redirect loops, incorrect canonical URLs or mixed content.
Also verify that the HTTP version of every important page consistently redirects to the corresponding HTTPS address in a single step. Test the homepage, posts, pages with forms, search, the login page and the administration panel separately.
If the site operates behind a CDN or reverse proxy, protocol information must be passed to WordPress correctly. Otherwise, the server may treat the request as HTTP even when the visitor is already connected over HTTPS, resulting in endless redirects.
- Check the WordPress and Site Addresses: both must begin with https://.
- Make sure the HTTP → HTTPS redirect does not create chains or loops.
- Check the certificate for the main domain and all required subdomains.
- Clear the WordPress, CDN and browser caches after changing the protocol.
- Do not enable HSTS on a test domain if its infrastructure changes frequently.
How to Add HSTS on the Web Server
The most reliable approach is to add HSTS at the web server or reverse proxy level so that the header is sent with all responses, not only with pages generated by WordPress. It is important that the header be delivered over HTTPS. Adding the header to HTTP responses does not provide useful protection.
The examples below are typical configurations. Create a backup before changing the configuration and check its syntax afterward. The exact location of the directive depends on the server structure, control panel and proxy setup.
For Apache:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15552000"
</IfModule>
For Nginx:
add_header Strict-Transport-Security "max-age=15552000" always;
Option with Subdomains
If all subdomains have been checked and are available over HTTPS, you can use includeSubDomains:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Adding HSTS Through WordPress
Some security tools or custom code can add the header through WordPress. This approach is acceptable, but it must be tested for error responses, redirects, static files and responses generated by the server or CDN. If the header is added in multiple places, make sure the different values do not conflict.
Checking Elementor and Mixed Content
After switching to HTTPS, part of a page may remain accessible while individual resources continue loading over http://. This is known as mixed content. The browser may block scripts, fonts, images or styles loaded this way, causing an Elementor page to display incorrectly.
Check the page HTML, the browser console and the network requests tab. Pay particular attention to background images, videos, fonts, iframes, external libraries and URLs in CSS. After correcting the URLs, clear the cache and, if necessary, rebuild Elementor's generated CSS files using the builder's available tools.
Do not mechanically replace every occurrence of http:// in the database without creating a backup. WordPress data may be serialized, so an incorrect replacement can damage widget or plugin settings.
- Check the browser console for Mixed Content messages.
- Replace HTTP URLs for images, fonts, scripts and styles with HTTPS.
- Check external iframes and resources from third-party services.
- After making changes, clear the browser, WordPress, CDN and builder CSS caches.
- Review pages in private browsing mode so that you are not relying on an old cache.
Safely Enabling HSTS in Stages
HSTS is best introduced gradually. First, set a short max-age to test the site's behavior in real browsers. If there are no problems, increase the period to 15552000 or 31536000 seconds.
After each change, check not only the homepage but also authentication, the administration panel, forms, file uploads, APIs, payment integrations and pages served by a separate server. Test mobile devices and different browsers as well.
Add includeSubDomains only after inventorying your DNS records and servers. The inventory should include even rarely used subdomains such as staging, old, dev, mail, status, api and service addresses. If even one of them does not support HTTPS, the inherited policy may block access.
- Stage 1: Check certificates, redirects and mixed content.
- Stage 2: Enable a short max-age without includeSubDomains.
- Stage 3: Review logs, browser errors and administration panel functionality.
- Stage 4: Increase max-age after the site has stabilized.
- Stage 5: Add includeSubDomains, and only then consider preload.
Common Errors and Troubleshooting
The most common mistake is adding HSTS with includeSubDomains and preload immediately, without checking older subdomains. Another issue is configuring the header in WordPress but overlooking a CDN or load balancer that overwrites or removes it.
You can view the actual header in the browser's developer tools or by using the curl command. Check the HTTPS response, not only the result of the redirect from HTTP.
- An incorrect max-age value or a syntax error in the header.
- HSTS is added only to HTML responses but is missing from other HTTPS responses.
- The HTTP redirect leads to another domain, an incorrect port or an intermediate URL.
- The certificate does not cover a subdomain that inherited the policy.
- After testing, the problem appears to have disappeared, but the browser is still using an old cache.
- preload was enabled before the audit of all subdomains was complete.
curl -I https://example.com
The response should contain a line such as:
Strict-Transport-Security: max-age=15552000
Frequently asked questions
Is HSTS alone enough to protect WordPress?
No. HSTS only forces the browser to use HTTPS after receiving the policy. You also need a valid SSL certificate, a correct HTTP redirect, an up-to-date WordPress installation and secure page resources.
Do I need to enable includeSubDomains immediately?
No. First check all subdomains and services. If even one of them does not have working HTTPS, the parameter may make it inaccessible in browsers.
Can HSTS be canceled after a mistake?
You can reduce max-age on the server, but a browser that has already stored a longer period may not immediately apply the new value if HTTPS access is unavailable. This is why the policy should be tested gradually and preload should not be enabled hastily.
Does HSTS protect users during their first visit to the site?
A standard HSTS policy starts working after the first successful HTTPS visit. Preload is used to provide protection before the first request, but it has strict requirements and can make access recovery more difficult.
Conclusion
For WordPress, HSTS should be treated as a final layer after HTTPS, redirects and the absence of mixed content have been configured correctly. First check the site, Elementor, the administration panel, the CDN and all subdomains, then increase max-age.
The safest approach is to enable HSTS gradually, without rushing to use includeSubDomains or preload. This lets you enforce HTTPS without creating unexpected problems for users and services operating alongside the site.