I don’t see a strong reason not to enable HTTPS for every website, other than it not being a priority because it works fine right now.
Many B2B companies’ web sites are basically just product information, with no user interaction beyond perhaps search feature and a Contact Us page. The Contact Us form probably submits securely to something like Hubspot, Google Forms, or Mailchimp. The content integrity aspects of securing the connection provide minimal value because it’s not a high value target: in the absence of user logins or other immediately actionable material on it, no one is making irreversible or expensive-to-reverse decisions based on information presented on the site without further human interaction.
When a website is little more than an inert brochure, it may seem like it is more worthwhile to ensure that your actual physical brochures handed out at conferences have not been swapped out by a competitor.
Not so, and there are some good reasons to enable HTTPS for your informational website.
It demonstrates the company’s pride in its security posture. Do you sell a product or service that requires security in some way? If you operate an online business, you almost assuredly do. You’re collecting or handling customers’ personally identifiable information and financial information minimally. If you treat everything else securely, so why even for a moment allow a (potential) customer to question that devotion to security by leaving their first interaction with you unsecured?
The lack of HTTPS could go unnoticed for a long time. In fact, you may never hear from a user disappointed that you don’t serve all content securely. However, that could change. While browsers already mark as insecure HTTP sites having password or credit card fields, Google will eventually actively mark anything not served over HTTPS as “Not secure”.
Setting up HTTPS establishes a necessary certificate workflow used while serving over HTTP/2. HTTP/2 promises a faster web and HTTPS is virtually required to support it. HTTP/2 is here but there are probably other optimizations for your site that you could do and see bigger gains. Try reducing page generation, transfer, or load time by at least using WP Super Cache for your WordPress site. Or, get all of this — including HTTPS–easily by using caching proxy like CloudFlare.
Speaking of WordPress, even when there’s not really anywhere for users to input data, WordPress sites still must be administered. No HTTPS means that the administration panel is unsecured during use. That makes me uneasy and you a target for interception at a coffee shop or spearfishing when you can’t tell the difference between mycompany.com and myc0mpany.com. I’ll bet you didn’t see the difference between those two URLs just now. HTTPS would at least let you see that you’re on the site you expect via HTTPS Extended Validation.
Some users want any input to be secured, even site searches. HTTPS secures user input when they’re searching the site with that search function.
HTTPS keeps intermediaries — ISPs, employer proxies, coffee shop WiFi proxies, etc. — from modifying pages in transit. HTTPS protect your users from content injected after it left your server. It protects you from taking the blame for someone else’s malicious action.
Lastly, advanced HTML5 features, e.g. geolocation require HTTPS, so if you ever wanted to put some kind of user-focused map on the site, you’ll have to serve via HTTPS.
It takes a little more time and money to manage. Buying a certificate and managing it, including renewing it, can be tricky. If your company already has a wildcard cert for *.mycompany.com for your other services, why not reuse that for https://www.mycompany.com?
If cost is an issue, there is an option: LetsEncrypt eliminates the upfront purchase of an HTTPS certificate. Automation of the LetsEncrypt renewal process eliminates most of the recurring maintenance time and money costs.
Securing your read-only website is probably not a priority compared to other things, like generating leads or other marketing initiatives, but if it’s as short of a task as signing up for CloudFlare or StackPath, it’s almost assuredly worth doing.
I’d had this post sitting in drafts for approximately a month when I happened across https://doesmysiteneedhttps.com. That site has some great counter-arguments for commonly cited reasons not to bother with HTTPS. It will help you on your quest to secure everything!