If you run a WordPress site over HTTPS, HSTS is one of those headers that feels like a no-brainer right up until it locks you into a bad decision.

I like HSTS. I use it on production sites. But I don’t recommend flipping it on casually, especially on WordPress installs with old plugins, mixed-content debt, weird subdomains, or a hosting setup you don’t fully control.

This guide compares the upside and downside of HSTS for WordPress, and where it makes sense versus where it can bite you.

What HSTS actually does

HSTS stands for HTTP Strict Transport Security. It tells browsers:

  • only connect to this site over HTTPS
  • if someone tries http://, rewrite it to https:// before making the request
  • optionally apply that rule to subdomains too

A typical header looks like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains

And if you want browser preload list eligibility:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

For WordPress site owners, the practical effect is simple: once a browser sees the header, that visitor’s browser will stop trusting HTTP for your domain for the duration of max-age.

That closes a real attack window: the first insecure hop where traffic could be downgraded, intercepted, or redirected.

Why HSTS is attractive on WordPress

WordPress sites often sit behind a stack of components:

  • CDN
  • reverse proxy
  • managed host
  • plugins doing redirects
  • login flows through /wp-login.php and /wp-admin/

That complexity creates lots of chances for HTTP to sneak back in accidentally. HSTS helps clean that up at the browser level.

Pros of HSTS for WordPress

1. It kills protocol downgrade mistakes

Even if a user types http://example.com, the browser upgrades to HTTPS after it has learned your policy.

That matters because WordPress sites frequently accumulate old links from:

  • legacy content
  • pasted media URLs
  • plugin-generated assets
  • old theme templates
  • hardcoded admin links

A redirect from HTTP to HTTPS is good. A browser refusing HTTP entirely is better.

2. It protects login and admin traffic better

WordPress admins are juicy targets. If someone can mess with the connection before HTTPS is established, login pages and authenticated sessions become more exposed.

HSTS reduces that risk. /wp-admin/ and /wp-login.php should never be reachable over plain HTTP in any meaningful sense.

3. It helps enforce HTTPS discipline across the stack

I’ve seen teams say “we’re HTTPS-only” while still serving a forgotten subdomain, asset host, or admin tool over HTTP.

HSTS forces you to be honest. If you enable it properly, weak spots become obvious fast.

4. It pairs well with other security headers

HSTS isn’t a complete hardening strategy, but it belongs in the same conversation as:

  • Content-Security-Policy
  • X-Content-Type-Options
  • Referrer-Policy
  • Permissions-Policy

If you want a quick baseline check, run a free scan at HeaderTest. It’s a fast way to see whether your WordPress setup is actually sending the headers you think it is.

The downside: HSTS is easy to misapply

This is where most guides get too cheerful. HSTS is great when your HTTPS setup is mature. It’s painful when it isn’t.

Cons of HSTS for WordPress

1. Bad rollouts are sticky

Once a browser caches your HSTS policy, you can’t instantly undo it for that visitor.

If you set:

Strict-Transport-Security: max-age=31536000

you’ve told browsers to enforce HTTPS for a year.

If you later break TLS, misconfigure your certificate, or move infrastructure around badly, users may be locked out until the issue is fixed. That’s the whole point of HSTS — and also the operational risk.

2. includeSubDomains can break stuff you forgot existed

This is the big one.

A lot of WordPress businesses have side systems on subdomains:

  • staging.example.com
  • dev.example.com
  • old.example.com
  • mail.example.com
  • help.example.com
  • random agency leftovers nobody documented

If you enable:

Strict-Transport-Security: max-age=31536000; includeSubDomains

every subdomain must support valid HTTPS. Not “most.” All of them that users might hit.

I’ve seen this break staging sites, old vendor panels, and forgotten microsites.

3. Preload is basically a one-way door for many teams

The preload token lets you submit your domain to browser preload lists. That means browsers hardcode HTTPS-only behavior for your site even before the first visit.

That’s powerful. It’s also something I would not do lightly on a WordPress property unless:

  • the domain is stable
  • all subdomains are audited
  • TLS management is boring and reliable
  • the team understands the rollback pain

Preload is great for mature organizations. It is not a fun experiment for a marketing site with mystery DNS entries from 2019.

4. It doesn’t fix mixed content or app-level mistakes

HSTS only enforces HTTPS transport. It does not fix:

  • insecure hardcoded asset URLs in themes
  • plugin output that references http://
  • broken canonical URLs
  • reverse proxy misconfiguration
  • WordPress thinking the site URL is HTTP

You still need to clean up your app.

5. Shared hosting and plugin-based header hacks can get messy

Some WordPress users add HSTS via a security plugin, some via .htaccess, some at Nginx, some at Cloudflare, some at the load balancer.

That can lead to inconsistent behavior. I prefer setting security headers at the edge or web server layer, not deep inside WordPress, because plugins get disabled, environments drift, and app-level logic is easier to bypass accidentally.

Comparison: HSTS vs just doing HTTPS redirects

A lot of WordPress sites stop at 301 redirects from HTTP to HTTPS.

That’s better than nothing, but here’s the practical difference:

HTTPS redirect only

Pros

  • easy to deploy
  • easy to undo
  • low risk for messy environments

Cons

  • first request can still happen over HTTP
  • vulnerable to downgrade or interception before redirect
  • relies on server behavior every time

HSTS enabled

Pros

  • browser upgrades before making insecure requests
  • stronger protection for logins and session traffic
  • enforces long-term HTTPS behavior

Cons

  • mistakes linger in browser cache
  • subdomain issues become your problem fast
  • bad for poorly audited infrastructure

My opinion: redirects are the baseline. HSTS is the upgrade once you’ve earned it.

When HSTS is a good fit for a WordPress site

I’d enable HSTS when all of this is true:

  • the main site is fully HTTPS with a valid cert
  • WordPress Address and Site Address both use https://
  • no mixed content remains
  • CDN/proxy setup correctly forwards HTTPS
  • all relevant subdomains are known and audited
  • certificate renewal is automated and boring
  • staging and dev environments are separated from production domains

If that sounds like your setup, HSTS is a smart move.

When I’d hold off

I would wait if any of these are true:

  • you still find random http:// URLs in the database
  • some subdomains are unmanaged or undocumented
  • you rely on old plugins that generate inconsistent URLs
  • your host or proxy setup is flaky
  • you’re thinking about preloading before you’ve even tested a short max-age

That last one is common. Teams jump from zero to preload because a checklist told them to. That’s backwards.

A safer rollout plan for WordPress

Start small. Always.

Phase 1: short max-age

Use something like:

Strict-Transport-Security: max-age=300

That’s 5 minutes. Low risk, easy to test.

Phase 2: increase gradually

Then move to:

Strict-Transport-Security: max-age=86400

Then maybe:

Strict-Transport-Security: max-age=2592000

Then the common long-term value:

Strict-Transport-Security: max-age=31536000

Phase 3: add includeSubDomains only after an audit

Don’t assume. Verify every subdomain you care about.

Phase 4: consider preload last

Only when you’re sure you want that commitment.

How to set HSTS on WordPress sites

Best place: web server, reverse proxy, or CDN.

Nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Cloudflare

You can enable HSTS in the dashboard, which is often cleaner than relying on WordPress plugins.

I avoid setting HSTS in PHP unless I have no better option.

Common WordPress-specific mistakes

A few I keep seeing:

  • enabling HSTS before fixing siteurl and home
  • forgetting media or asset URLs hardcoded as HTTP
  • applying includeSubDomains while staging is still insecure
  • using preload on domains with ancient mail/help/admin subdomains
  • assuming a plugin can manage this safely across all environments

WordPress makes it easy to ship changes quickly. That’s great until a security header turns a small config mistake into a support incident.

My take

For a well-run WordPress site, HSTS is worth it. It’s one of the cleaner wins in browser security.

For a chaotic WordPress site, HSTS is still worth it eventually — just not as your first move.

If you’re comparing options, the real choice isn’t “HSTS or no HSTS.” It’s:

  • redirects only for basic HTTPS hygiene
  • HSTS for stronger enforcement once your setup is stable
  • HSTS with includeSubDomains and preload only when your domain operations are truly under control

That last level is where people overreach.

My default recommendation for most WordPress teams: enable HTTPS everywhere, clean up mixed content, verify subdomains, deploy HSTS with a short max-age, and ramp up slowly. That gives you the security benefit without turning one forgotten subdomain into a self-inflicted outage.