How to Fix HSTS Errors

HSTS errors come in two flavours: warnings from a security scanner that your HTTP Strict Transport Security header is missing or weak, and the blocking error page a browser shows when it refuses to load a site because of a broken HTTPS setup. Both matter, and both are fixable. This guide covers the common HSTS errors, why they happen, and exactly how to resolve them so your site loads securely for everyone.

If you want a refresher on the header itself before troubleshooting, start with our explainer on what HSTS is and then come back here.

Error 1: The HSTS header is missing

The most common finding is simply that no Strict-Transport-Security header is present. Fix it by sending the header on every HTTPS response. On Apache add a Header directive to your configuration, on Nginx add an add_header line to the server block, and on WordPress hook into the send_headers action or use a security-headers plugin. A safe starting value is max-age=31536000; includeSubDomains. Deploy it, then reload the server so the change is live.

Error 2: The max-age is too short

Some scanners flag an HSTS header whose max-age is only a few minutes or hours. A short lifetime means the protection expires almost immediately, so returning visitors are exposed again. Raise max-age to at least six months, and ideally a full year, which is 31536000 seconds. There is rarely a reason to use a small value on a production site that is committed to HTTPS.

Error 3: Subdomains are unprotected

Without includeSubDomains, your policy protects only the exact hostname that sent it. Assets, apps and login subdomains can still be reached over insecure HTTP. Add the includeSubDomains keyword, but only after confirming every subdomain genuinely serves HTTPS, otherwise you will take working subdomains offline. This is one of the most common self-inflicted HSTS errors, so test carefully before rolling it out.

Error 4: The browser blocks the site with an HSTS error

When a browser shows a message that it cannot guarantee a secure connection and will not let the visitor continue, an active HSTS policy is doing its job by refusing an insecure or invalid certificate. The real fault is almost always the certificate: it has expired, does not match the domain, or is missing part of its chain. Fix the certificate itself, because with HSTS active there is deliberately no way for the visitor to click through the warning. Once the certificate is valid, the error disappears.

Error 5: Mixed content undermines HSTS

If your pages still reference scripts, styles or images over http, browsers may block them once HTTPS is enforced, breaking layout or functionality. Update every internal reference to https or to protocol-relative paths so the whole page loads securely. Clean HTTPS everywhere is what makes an aggressive HSTS policy safe to keep.

Testing after you fix HSTS errors

Because browsers cache the HSTS policy, you may need to clear it locally while testing. Modern browsers let you delete the stored policy for a single domain through their security settings, so you can retest a fresh connection. Change the header, clear the local policy, reload, and confirm the header now reads exactly as intended.

Confirm the fix with a scan

The quickest way to be sure your HSTS errors are gone is to re-scan the site. Run a security scan with EzyAudit AI and check that the Strict-Transport-Security header is present, has a long max-age, and covers subdomains where appropriate. Our report explains each header in plain language, so you know not just that it passed but why. See the full range of checks we perform. For the underlying specification, consult IETF RFC 6797, which defines HSTS behaviour in detail.

Resolving HSTS errors keeps your encryption reliable and your visitors safe from downgrade attacks. Scan your website now to confirm every header is configured correctly.