HTTPS is the floor, not the ceiling

Google announced HTTPS as a ranking signal back in August 2014, and a decade later it has stopped being a tiebreaker and started being a prerequisite. Chrome, Firefox, and Safari flag plain HTTP pages as "Not Secure" in the address bar, which kills click-through rates from organic results before a user has even read your title tag. If your site still answers on port 80 without a redirect, you are bleeding traffic for reasons unrelated to content quality.

The ranking lift from HTTPS itself is small (Google has called it "lightweight"), but the second-order effects compound. Referrer data only passes from HTTPS to HTTPS, so analytics attribution gets cleaner. HTTP/2 and HTTP/3, which deliver real performance wins for Core Web Vitals, only run over TLS in every browser shipping today. Service workers, Web Push, geolocation, and the clipboard API all refuse to run on insecure origins.

That is the lens to read this checker through. It is confirming that the entire transport layer your site rides on is configured correctly enough that browsers, crawlers, and CDNs treat you as a first-class citizen.

What this SSL checker actually inspects

When you point the tool at a hostname, it opens a TLS handshake the same way a browser would and pulls back the full certificate chain. The leaf certificate has to be issued by a publicly trusted CA, signed with a modern algorithm (SHA-256 minimum, RSA 2048-bit or ECDSA P-256), and unexpired. The Common Name and Subject Alternative Names need to cover the hostname you are testing, including any www variant.

Then it follows the chain. Browsers ship with a fixed list of root CAs, and your server has to send every intermediate certificate between your leaf and one of those roots. A surprising number of "works on my machine" cert problems are actually missing intermediates; desktop browsers cache them, but mobile clients and Googlebot do not, so a chain that loads fine on your laptop can return a cryptic error in Search Console.

Beyond the certificate, the checker reports the negotiated TLS version, cipher suite, key exchange, and whether OCSP stapling, session resumption, and ALPN (which lets HTTP/2 negotiate cleanly) are working. Each affects security posture, page load time, or both.

TLS 1.0 and 1.1 are dead, TLS 1.3 is the target

TLS 1.0 (1999) and TLS 1.1 (2006) were formally deprecated by the IETF in 2021. Browsers stopped supporting them years earlier, and PCI DSS will fail you for offering them on anything that touches a payment flow. If your checker output still shows TLS 1.0 or 1.1 enabled, that is a configuration mistake to fix today, because it actively exposes users to downgrade attacks.

TLS 1.2 is the realistic minimum. It supports modern AEAD ciphers (AES-GCM, ChaCha20-Poly1305) and forward secrecy via ECDHE key exchange. Most servers running a recent Nginx, Apache, or Caddy build will negotiate TLS 1.2 by default with sane settings.

TLS 1.3, finalized in 2018, is where you actually want to land. It cuts the handshake from two round trips to one (or zero with 0-RTT resumption), removes every legacy cipher that could be downgrade-attacked, and makes weak configurations impossible because the protocol does not allow them. The performance gain on first connections is measurable, especially on mobile networks with high latency, which feeds directly into LCP.

Common cert failures and what each one means

Hostname mismatch is the most frequent issue. The cert covers example.com but not www.example.com, or the redirect points to a subdomain not in the SAN list. Modern certs from Let's Encrypt and most paid CAs let you add multiple SANs at no extra cost.

Self-signed certs work for development and absolutely nothing else. Browsers refuse the connection, Googlebot refuses the connection, and uptime monitors scream. If a self-signed cert ends up in production by accident (often through a misconfigured load balancer that strips the real chain), the public site goes dark within minutes.

Missing intermediate certificates produce the "chain incomplete" warning; the fix is making sure your server config sends the full chain file, not just the leaf. Weak ciphers (anything with RC4, 3DES, CBC mode without modern mitigations, or RSA key exchange without forward secrecy) will trigger downgrades in the checker output and should be removed from your cipher list. Sites stuck on old configurations often inherit these from a copy-pasted Nginx snippet that is half a decade old.

Let's Encrypt versus paid certificates in 2026

For the vast majority of sites, Let's Encrypt is the right answer. The certificates are cryptographically identical to anything you would buy from DigiCert or Sectigo, issuance is automated through ACME, and the price is zero. The 90-day validity window forces automated renewal, which is a feature, not a bug; the only certs that expire in production are ones whose owners forgot they existed.

Paid certificates earn their price in two narrow cases: when you need a wildcard plus organization validation (which Let's Encrypt does not issue), and when compliance requires a specific CA on an approved vendor list. Outside those scenarios, you are paying for branding.

EV certificates, the "green bar" products that used to display your company name in the address bar, are essentially gone. Chrome stopped showing the EV indicator in 2019, and other browsers followed. Users cannot tell an EV cert from a domain-validated one because the UI is identical. If a vendor pitches EV as a trust signal, they are selling you a feature browsers stopped rendering five years ago.

Mixed content, HSTS, and the rest of the stack

Mixed content is the gotcha that catches sites mid-migration. The HTML loads over HTTPS, but an old image, script, or iframe URL still references http://. Browsers block active mixed content (scripts, stylesheets, iframes) outright and warn on passive mixed content (images, video). The checker flags this on your homepage, but a full audit means crawling your CMS for hardcoded http:// references in post bodies and theme files.

HSTS (HTTP Strict Transport Security) tells browsers to refuse HTTP entirely for your domain, even on the first visit if you submit to the preload list. A solid baseline is `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`. Pair that with a Content Security Policy that disallows http: schemes and Secure plus HttpOnly flags on every cookie, and you have closed the obvious downgrade paths.

Cert expiry monitoring belongs in your alerting stack, not a calendar reminder. With Let's Encrypt's 90-day cycle, certbot or acme.sh will renew on day 60 by default, but you still want an external probe firing 30 days before expiry. The failure mode is silent until it is catastrophic.

How a broken cert tanks rankings within days

Googlebot follows the same TLS rules as Chrome. When a cert expires or breaks, the crawler returns an error rather than your content, and Search Console will surface a spike of "Server error" in the Coverage report within hours. Pages that were fetching cleanly drop out of the index, and recovery is slower than the drop because Google rate-limits re-crawls on a domain that just looked broken.

Click-through rate from the SERP also collapses the moment Chrome shows a full-page interstitial warning. Even if rankings hold for a day or two, sessions per impression drop close to zero because almost no user clicks past the "Your connection is not private" screen. The combination of crawl errors and behavioral signals compounds quickly.

Running this checker on a recurring schedule, wired into the same alert channel that handles uptime, is the cheapest insurance you can buy against that scenario. Set it on your apex, your www variant, every subdomain that serves user-facing content, and your CDN edge if it terminates TLS separately. A clean run today plus a working renewal cron tomorrow is the whole job.