Server Side TLS
wiki.mozilla.org
wiki.mozilla.org
That aside, your site looks at valuable resource. Thank you for publishing it.
I don't want to disagree with you but I do. I most certainly agree that HTTPS must be everywhere and it's easier than ever before. Where I disagree comes with less experienced developers. I can write a quick PHP / Rails / Node / whatever web server to show some website real fast, deploy by uploading it to a shared hosting package or something fancier like elastic beanstalk, and it's done and up there. Yes it's on HTTP but it's so easy. Now you want to add HTTPS to it? It's not easy. Let's Encrypt makes some aspects of it easier but until the amount of fiction is similar to the process of deploying HTTP you'll never see HTTPS ubiquity in my opinion.
Try Caddy with automatic HTTPS [0] in reverse proxy mode [1].
granted, you're already giving up this control when you host with any 3rd party, but the CAs are being reckless if they encourage it.
Personally, I'd deploy HSTS incrementally and wait until such time there is a majority of subdomains that are TLS capable before deploying includeSubDomains. Otherwise, there could likely be some nasty surprises.
Arbitrarily enabling includeSubDomains is going to lead to nasty surprises if there is no prior coordination.
I'd argue that all, not most, subdomains must be HTTPS capable (I won't say TLS generally, either; this is only dealing with HTTP). Any that aren't will not be accessible by a user agent that recently (within the max-age) visited the parent domain if it had an HSTS header with that flag.
For command line, this his nice: https://github.com/iSECPartners/sslyze
It especially useful in locked-up environments where the server-to-server communication must be TLS, yet both servers are not directly accessible from the 'public' internet.
[1] https://mozilla.github.io/server-side-tls/ssl-config-generat...
<hostname> { tls <your email> proxy / localhost:<port> }
Don't do this. After I did it, my 3 websites were completely wiped-out from search results. From 3k UU to 20-30UU /day.
Did you try to recover the traffic? If yes, what did you try and did it work?
Also, after setting the permanent redirect, I believe it would be a good idea to update the internal navigation of the site so that all links are formed with https. That way, both the crawlers and the web server will have less work to do and eventually, the entire site will be indexed/updated in the search engines with the https protocol.
nginx was redirecting everything with 301.
I let once website work on http and https and made most links protocol-independent, only site map and search results are forced to https. There was a thread about it on reddit where a few more people said the same.
I slightly recovered from it, got 101 UU yesterday.
If it has been a while (at least a month or two) since the changes were made and the traffic has not returned, that would be a cause for concern.