Any HSTS/nosniff Issues with Performance and Compatibilities?


I am about to enable HSTS but, before I do, I would like to know if there are any drawbacks to enabling it, such as:

  1. Does it cause or hinder any performance-related settings/issues?
  2. Are there any Network or Edge Certificate settings within Cloudflare that could interfere with HSTS?
  3. Most devices and browsers support nosniff, so should I enable that or are there things to look out for before enabling it?
  4. Are there compatibility issues with WordPress/WordPress admin pages?
  5. Will it affect our AMP pages at all?

I do have an SSL certificate and Cloudflare is on Full Strict; none of that will ever change!

If someone could help me a bit I would greatly appreciate it!

Thanks and regards,


That is really great to hear! :wink:
Regarding HSTS, just make sure to stay on HTTPS and keep having the SSL covered your domain(s) while having it enabled.

Basically, it forces web browsers to open websites with secure HTTPS connections only.

So, if anyone tries to open a web page using HTTP, their browser will block that request and show the error message.

That could be the only drawback.

If disabled, the solution for a user/visitor would be to clear it’s web browser’s cache to make it work back over HTTP (not HTTPS) as far as I remember when I had this issue with one domain where SSL certificate has been used, then expired and webmaster did not renew it, just switched to HTTP while the domain has had HSTS enabled.
The end result was the users have had cached HTTPS version, and when trying to open that website, they got error.
Later on, the SSL certficiate was renewed and all got back to HTTPS :wink:

Therefore, regarding your questions of HSTS being disabled, WordPress, Google, SEO, AMP, yes it would impact all of it one by one.

1 Like

(You seem to be aware of all this, so here is how to suck eggs.)

If you have already eliminated all mixed content, and everything is served over HTTPS, then HSTS will give a very slight performance improvement for users who type into the address bar in their browsers.

It can be dangerous if anything is either not available on a HTTPS connection, or your certificates are ever invalid. There is no “click here to make this warning message disappear”. If you are confident, HSTS is very safe. If you have Flexible, it is probably not safe.

I would consider “Always Use HTTPS” to be essential if using HSTS. I think that the Opportunistic TLS is redundant with HSTS and Always Use HTTPS.

I’ve never had an issue with nosniff, but I don’t have too many users running IE6. I believe it has implications for CORB, so perhaps some quick research is needed before making a change.

No particular compatibility with WP, provided it already works over HTTPS.

TLS is mandatory for AMP, so HSTS should do nothing.


Thank you both @michael and @fritexvz for your help!

So enabling the HSTS will actually improve SEO, AMP, WordPress, and Google? And disabling it in the future will have a negative impact, correct?

I have HTTP/2 and HTTP/3 enabled as I don’t think the two would conflict with each other or HSTS.

I also want to add that we set up a page rule for* to be forwarded to$1. If someone just types in they will get redirected to our HTTPS site properly with HSTS enabled, correct? This is pretty important since people do not usually type in the full URL as you (fritexvz) stated they would need to do that? However, Michael, you stated that they could type in a domain without HTTPS and they will see a slight performance improvement. If either one of you could clarify a little further I would greatly appreciate it!

Thank you again for the help and information!

No. If HSTS is enabled, and you do something that means HTTPS does not work correctly, then your site will be broken. Just monitor your certificates to make sure they do not expire and you’ll be good to go.

No conflicts. HTTP/3 requires HTTPS, as does Cloudflare’s deployment of HTTP/2.

I’m assuming that you have “Always Use HTTPS” enabled, so all requests to get an instant redirect to Once users have seen the HSTS header, they avoid needing that redirect. Redirects take a little bit of time, and you save that. But it is minor.

The target of a redirect should always be a https URL.

If you plan on doing HSTS preload then you will need to (temporarily) change this to*. The HSTS Preload checking tool requires the initial http → https redirect to stay on the same hostname.

Yes, I have it on. That’s amazing. If I were to type in then the browser would already know to output the HTTPS without having to go by a redirect via server-side eh? That’s pretty cool.

That* is already in use. For some reason, if someone typed in they would get an infinite redirect loop and the browser would never display an error. It would just be a loop. So I added the* and Cloudflare said it was in use so I did* and it worked and the redirect error was gone. I could implement a page rule to bypass* from the cache for it to redirect to our https://www properly.

When you say, temporary, do you mean to reenable that Forward URL page rule we implemented or just delete it after a few days or a week? I wonder if that redirect error will go away when HSTS is enabled.

Never mind, I think I was messing something up? I also applied a http://** rule to Always Use HTTPS then I just use* to be forwarded to$1 to avoid duplicate content penalties. Without putting HTTP or HTTPS that rule will cover both protocols according to a Must Use Cloudflare Page Rules Cloudflare tutorial. Will this be fine or will it present an issue and I should use the HTTPS protocol?

I am not too sure what the definition of temporary is. Do I delete that rule after a certain period of time as in when the browsers have successfully stored the information? I assume I should also be able to delete the page rule http://**: Always Use HTTPS as well?

Thank you for your help!

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.