That is really great to hear!
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
Therefore, regarding your questions of HSTS being disabled, WordPress, Google, SEO, AMP, yes it would impact all of it one by one.
(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 example.com 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.
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 our-domain.com/* to be forwarded to https://www.ourdomain.com/$1. If someone just types in our-domain.com 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!
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 http://example.com get an instant redirect to https://example.com. 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 https://our-domain.com/*. 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 my-domain.com 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 https://our-domain.com/* is already in use. For some reason, if someone typed in https://our-domain.com/ 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 https://our-domain.com/* and Cloudflare said it was in use so I did our-domain.com/* and it worked and the redirect error was gone. I could implement a page rule to bypass https://our-domain.com/* 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://*my-domain.com/* rule to Always Use HTTPS then I just use our-domain.com/* to be forwarded to https://www.our-domain.com/$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://*my-domain.com/*: Always Use HTTPS as well?
