How to Fix: HSTS header configured

HSTS header configured is an important SEO check in the Security & Trust category. This is a high-priority SEO issue that should be addressed soon. It has a significant impact on your SEO performance.

What this check is really about

This check verifies that your site sends the Strict-Transport-Security response header — HSTS. In plain terms, HSTS tells the browser: from now on, only ever talk to this site over HTTPS, and do not even attempt plain HTTP, even if a link or a typed address says otherwise. It closes the small but real window where a first request over HTTP can be intercepted or downgraded before your redirect to HTTPS has a chance to fire.

This is filed as MEDIUM difficulty for a good reason: it is a genuinely powerful header with a genuinely sharp edge. Configured well it is a clean security win. Configured carelessly, it can make a site unreachable in a way you cannot quickly undo. Respect it.

Why Does This Matter for SEO?

Security is part of how Google and your users judge trust, and HSTS is a concrete signal of it:

• It enforces HTTPS everywhere, protecting users from downgrade and man-in-the-middle attacks on that first request.
• HTTPS has been a confirmed Google ranking signal for years; HSTS is the discipline that makes your HTTPS airtight.
• It eliminates the initial insecure hop, which tightens performance and removes an easy attack surface.
• It is a visible marker of a professionally secured site — the kind of trust signal that matters most in the Security & Trust category.

How to Check This Issue

Confirm what your server sends today:

1. Run the SEO Roadmap audit to see whether the HSTS header is present.
2. Open browser dev tools (F12) → Network, load your site, click the main document request, and look for Strict-Transport-Security in the response headers.
3. Run your domain through a security-headers scanner or an SSL test for a full report and a grade.
4. Before you commit, verify that every subdomain and every asset already loads cleanly over HTTPS — that check is what keeps the fix safe.

How to Fix This in WordPress

Difficulty Level: MEDIUM – This fix requires some technical knowledge or familiarity with WordPress settings and plugins.

Estimated Time: 10 min

Step 1: Make sure HTTPS is fully working first

This is non-negotiable and it is where the caution lives. Confirm you have a valid SSL certificate, that the whole site and every subdomain load over HTTPS with no mixed-content warnings, and that HTTP already redirects to HTTPS. HSTS assumes HTTPS is flawless — if anything is still served over HTTP, adding HSTS will break it, and browsers will keep enforcing the broken state.

Step 2: Add the header at the server level

HSTS is a server response header. The cleanest home for it is your server config or a security plugin. On Apache it goes in .htaccess or the vhost; on Nginx in the server block; many managed hosts and CDNs (Cloudflare included) expose an HSTS toggle in their dashboard, which is often the safest route because it is easy to switch off again.

Step 3: Start with a short max-age

Do not begin with a one-year policy. Set a short max-age first — say 300 seconds — confirm everything still works, then ramp it up to a longer duration once you are confident. Add includeSubDomains only after you have verified every subdomain is HTTPS-clean, and treat the preload flag as a deliberate, separate decision, not a default.

Step 4: Verify

1. Clear your WordPress cache if you’re using a caching plugin.
2. Reload and confirm the Strict-Transport-Security header now appears in the response.
3. Re-run the SEO Roadmap audit and re-scan with a security-headers tool.

Understand preload before you touch it — it is nearly permanent

Here is the caveat I will not let a client skip, because it is the one that turns a ten-minute win into a months-long headache. HSTS with the preload directive can get your domain baked into a list that ships inside the browsers themselves. When that happens, the “only HTTPS, ever” rule is enforced before your server is even contacted — and removing a domain from that list is slow, sometimes taking months to propagate through browser releases.

So my rule is simple. Add HSTS for your own domain with a sensible max-age today; that is reversible on a reasonable timescale. Do not add includeSubDomains until every subdomain is provably HTTPS-only, because it will take the whole family down with it if one is not. And do not submit to preload at all unless you are certain your entire domain will be HTTPS-only for the foreseeable future. Preload is a commitment, not a setting. Treat it like one.

Recommended Tools & Plugins

These tools can help you fix and prevent this issue:

• Yoast SEO – Comprehensive SEO plugin with built-in checks
• Rank Math – Feature-rich SEO plugin with detailed analysis
• Google Search Console – Free tool to monitor your site’s search presence
• SEO Roadmap – Complete SEO audit and action plan tool

The mistake I see most often

Enabling HSTS — often with includeSubDomains and preload straight away — on a site that still has one subdomain or a stray asset served over HTTP. Everything looks fine to the person who set it up, and then a subdomain becomes unreachable and cannot be quickly rolled back. Get HTTPS perfect first, start with a short max-age, and add includeSubDomains and preload only as deliberate, verified steps.

This guide is part of the SEO Roadmap knowledge base – your complete resource for WordPress SEO optimization.