HTTP Strict Transport Security, commonly called HSTS, is a security header that tells browsers to use HTTPS when connecting to your site.

Pressidium EDGE supports HSTS implementation as part of its security layer.

What is HSTS?

HSTS stands for HTTP Strict Transport Security.

When HSTS is active, supported browsers remember that your site should be accessed over HTTPS. This helps reduce the risk of visitors being downgraded to insecure HTTP connections after they have already visited your site over HTTPS.

HSTS is especially useful for production websites that should always load securely.

How Pressidium EDGE helps with HSTS

Pressidium EDGE sits in front of your WordPress origin and becomes the first touchpoint for incoming requests.

As part of the EDGE security layer, HSTS can help enforce secure browser behavior by instructing browsers to use HTTPS for future requests to your site.

HSTS works alongside other EDGE security capabilities, including:

  • Automated SSL certificate issuance and renewal
  • Support for custom SSL certificates
  • Edge WAF protection
  • WordPress-specific security rules
  • DDoS mitigation
  • Bot mitigation
  • IP and geo controls

This helps make HTTPS enforcement part of the edge-delivered security posture for your site.

Use the related SSL and security docs when you need to review SSL setup, troubleshoot certificate issues, or verify that your site loads correctly over HTTPS.

What HSTS protects

HSTS helps protect visitors from certain downgrade and protocol-related risks by telling browsers to avoid insecure HTTP connections for your domain.

It is most useful when:

  • Your site should always be accessed over HTTPS
  • Your SSL certificate is active and valid
  • Your domain is fully ready to serve secure traffic
  • You want browsers to remember secure HTTPS behavior
  • You want to reduce accidental insecure access to your site

What HSTS does not replace

HSTS strengthens HTTPS behavior in the browser, but it does not replace the rest of your security setup.

You should still:

  • Keep SSL certificates active and valid
  • Make sure your site loads correctly over HTTPS
  • Fix mixed content issues
  • Keep WordPress core, plugins, and themes updated
  • Use the Edge WAF and security rules for request-level protection
  • Review Security Events Analytics for suspicious traffic

Before using HSTS

Before relying on HSTS, confirm that:

  • The domain has a valid SSL certificate
  • The site loads correctly over HTTPS
  • Important pages, assets, forms, and admin areas work over HTTPS
  • There are no critical mixed content issues
  • Any required subdomains are also ready for HTTPS if they will be included in the HSTS policy

Reviewing HTTPS and HSTS behavior

To review HTTPS behavior:

  1. Open your site using https://.
  2. Confirm the site loads without browser certificate warnings.
  3. Check important pages, login areas, forms, and checkout flows.
  4. Confirm images, scripts, stylesheets, fonts, and third-party resources load correctly.
  5. Use browser developer tools or an HTTP header checker to confirm whether the Strict-Transport-Security header is present.

Expected result: The site loads securely over HTTPS and the browser does not show certificate or mixed content warnings.

Common questions

Is HSTS the same as SSL?

No. SSL/TLS provides the secure HTTPS connection. HSTS tells browsers to keep using HTTPS for future requests to the domain.

You need a valid SSL certificate before HSTS can work safely.

Does HSTS fix mixed content?

No. HSTS does not fix mixed content by itself.

Mixed content happens when an HTTPS page loads some resources over HTTP. You should fix those URLs in WordPress, your theme, plugins, or content.

Should every site use HSTS?

HSTS is useful for production sites that should always load over HTTPS.

Before using it, make sure HTTPS is fully working across the domain and any required subdomains.

Can HSTS affect subdomains?

It can, depending on the HSTS policy used.

Only include subdomains if every required subdomain is ready to serve HTTPS. Do not include subdomains that still need to support HTTP or do not have valid SSL certificates.

Does HSTS protect against all attacks?

No. HSTS only helps enforce HTTPS behavior in supported browsers.

It does not replace WAF protection, bot mitigation, DDoS protection, WordPress updates, secure coding, or access control.

Common issues and solutions

Browser shows a certificate warning

Symptom: Visitors see a browser warning when opening the site over HTTPS.

Likely causes:

  • The SSL certificate is not active
  • The certificate does not match the domain
  • DNS is not fully pointing to EDGE
  • The certificate has expired
  • A subdomain is being forced to HTTPS without a valid certificate

Resolution steps:

  1. Review the domain’s SSL status.
  2. Confirm DNS is correctly configured.
  3. Check whether the affected hostname has a valid certificate.
  4. Review whether HSTS applies to the affected hostname.
  5. Fix SSL or DNS issues before relying on HSTS.

Verification: Open the affected URL in a browser and confirm it loads over HTTPS without warnings.

Some assets fail to load

Symptom: The page loads, but images, scripts, stylesheets, or fonts are missing.

Likely causes:

  • Mixed content references still use http://
  • A plugin or theme outputs insecure asset URLs
  • A third-party resource is not available over HTTPS
  • Cached content still contains old HTTP URLs

Resolution steps:

  1. Open browser developer tools and check the Console and Network tabs.
  2. Identify assets loading over http://.
  3. Update the affected URLs in WordPress, theme settings, plugin settings, or content.
  4. Purge cache after fixing URLs.
  5. Reload the page over HTTPS.

Verification: Confirm the browser no longer reports mixed content or blocked insecure resources.

A subdomain stops loading correctly

Symptom: A subdomain is forced to HTTPS but does not load correctly.

Likely causes:

  • HSTS applies to subdomains
  • The subdomain does not have a valid SSL certificate
  • The subdomain is not configured to serve HTTPS
  • DNS for the subdomain points somewhere else

Resolution steps:

  1. Confirm whether the affected subdomain should be covered by HTTPS.
  2. Check DNS for the subdomain.
  3. Confirm the subdomain has a valid SSL certificate.
  4. Review whether the HSTS policy includes subdomains.
  5. Adjust the setup only after confirming the intended behavior.

Verification: Open the subdomain over HTTPS and confirm it loads without certificate warnings.

Best practices

  • Use HSTS only after HTTPS is fully working.
  • Confirm SSL is active before enabling or relying on HSTS.
  • Fix mixed content before applying strict HTTPS behavior.
  • Be careful with subdomains. Include them only when they are HTTPS-ready.
  • Use redirects and HSTS together where appropriate. Redirects move users to HTTPS, while HSTS tells browsers to keep using HTTPS.
  • Review SSL and DNS configuration before making security-header changes.

Need help?

Contact Support if:

  • Your site shows certificate warnings
  • A subdomain is being forced to HTTPS unexpectedly
  • You cannot confirm whether HSTS is active
  • Important assets or pages fail after HTTPS enforcement
  • You need help reviewing SSL, DNS, or security-header behavior

Include the affected domain, URL, browser error, timestamp, screenshot, and any recent DNS or SSL changes.

Where to go next