YES
Your site needs HTTPS.

"But my site doesn't have forms or collect information from users."

Doesn't matter. HTTPS protects more than just form data! HTTPS keeps the URLs, headers, and contents of all transferred pages confidential.

"There's nothing sensitive on my site anyway."

Your site is a liability! Just because your site is hosted safely in your account doesn't mean it won't travel through cables and boxes controlled by who knows how many corporate- and state-owned entities. Do you really want someone injecting scripts, images, or ad content onto your page so that it looks like you put them there? Or changing the words on your page? Or using your site to attack other sites? This stuff happens: on airlines (a lot, and again), in China, even ISPs do it (a lot). And HTTPS prevents all of it. It guarantees content integrity and the ability to detect tampering. If we encrypt only secret content, then we automatically paint a target on those transmissions. Keep which of your transmissions contain secrets secret by encrypting everything.

"The site is HTTP, but our forms are submitted over HTTPS."

This is as bad as not using any HTTPS at all! All the attacker has to do is change the link or form action to a URL on his/her own server. There's no way to detect this because it happens over the wire with plain HTTP. Encrypt the WHOLE site and redirect HTTP to HTTPS.

"I can't afford a certificate."

They're free.

"HTTPS is difficult to set up and maintain."

It just works if Caddy is your web server. Yes, including certificate renewals. No thought required. For everyone else, HTTPS can still be automated by using a Let's Encrypt client of your choice.

"Attackers can still impersonate my site, even if I use HTTPS."

They can try, but as long as your private key stays private, browsers will show warnings if attackers present a mismatched or invalid TLS certificate. And if the attacker does not use HTTPS at all, browsers should mark the imposter page as insecure. To this end, HTTPS guarantees authenticity.

"Domain-validated (DV) certificates aren't secure."

Yes they are. Just don't lose control over your DNS and choose a competent certificate authority (as opposed to less competent or troublesome ones). There is absolutely no difference in the cryptography in a DV certificate compared to that of an extended validation (EV) certificate.

"But CAs can misissue for my site any day <...or any other complaint about the CA system>."

Look, this discussion isn't about PKI. It's the best system we've got for right now. Deal with it and secure your site. Use CAA records to restrict which CAs can issue certificates for your site, then cross your fingers and hope transparency and oversight works (it does, so far).

"HTTPS doesn't hide the size of the content, leaking clues to attackers."

TLS 1.3 and HTTP/2 have padding frames to inflate the size of the ciphertext.

"HTTPS doesn't hide the DNS lookup."

Of course not. DNS != HTTP. But is that really a valid reason not to encrypt the connection between your website and its visitors?? (Hint: no.)

"HTTPS is slow."

No it's not. Sites with modern servers load faster over HTTPS than over HTTP because of HTTP/2.

"Phishing sites use HTTPS."

... so you won't?

"Our site displays ads over HTTP."

Sorry, not sorry. Doesn't change the fact that your site still needs HTTPS. Switching to HTTPS with ads still over HTTP will cause mixed content warnings in browsers, so you better figure out a cute way to wiggle out of that ad publishing contract that looked really attractive when you first signed it, or convince your ad network to move to HTTPS before you do.

"It works over HTTP just fine."

That's what Oil and Gas International thought, too. Until browsers started flagging HTTP pages as insecure.

"But TLS proxies break the guarantees of HTTPS."

Only if the end user's computer is modified to trust the TLS proxy. This requires administrator (root) privileges, so the owner of the computer must allow it. Besides, HTTPS interception can usually be detected by web servers.

"At least I can still serve my site over both HTTP and HTTPS."

The only reason you should open port 80 on your server is to redirect all requests to port 443 and then close the connection on port 80. (Someday, maybe we can drop port 80 altogether.)

"My site is only accessible internally or with a VPN."

How much do you trust the corporation or state that owns the infrastructure? And the companies that produced the hardware that comprises your network? Or the VPN provider?

"We hash the passwords."

Good for you. Now please tell me you're collecting them via HTTPS. ... you are, right?

"HTTPS impacts SEO."

You're right—HTTPS improves it! Switching site URLs improperly may impact your search rankings, but HTTPS actually improves them. Just do the switch properly according to the search engine you're optimizing for, and everything will be fine, with only temporary side-effects at most.

"It's the browser's job to keep users safe."

True, but incomplete. It is not SOLELY the browser's job. Browsers can only keep the users safe if the server provides credentials through an HTTPS certificate. As a site owner, it's your responsibility to provide these credentials for your clients.

— HOW TO GET ON HTTPS —

The easiest way is through Let's Encrypt and the Caddy web server, which enables HTTPS for all your sites automatically. You can also use a simple, stand-alone Let's Encrypt client called lego, which runs on every platform.

If you prefer a little more setup and system integration with traditional web servers, the EFF's client Certbot will suit you well.

There are plenty of other ways to get your site on HTTPS without much trouble. Das Surma has a guide for several web servers and CDNs like Cloudflare can make your site available over HTTPS for minimal fees, if any at all.