What an Expired Certificate Actually Does to Your Conversion Rate
A restaurant with a public health notice taped to its door is still, technically, a restaurant. The food might be fine. The chef might be excellent. The seasonal menu might be the best in the city. But you, walking past, will not go in. You will keep walking. You will not stop to read the small print. You will not investigate. The notice is a binary signal - "something is wrong here" - and your brain treats it accordingly.
A modern browser warning on an expired certificate has the same effect.
The site is, technically, still there. The product page still loads if you click through three warning screens. The shopping cart still works if you accept the security risk. But almost nobody clicks through. Almost nobody accepts the risk. They close the tab, search again, and click the next result.
What an expired certificate does to your conversion rate is not subtle. It is not "a slight dip we can recover from with a quick fix." It is the equivalent of taping a public notice to your front door for the duration of the outage - plus a long aftermath of users who saw the warning and quietly stopped trusting you.
Here's what happens, the actual math, and the long-tail damage most teams don't measure.
What the warning looks like to a user
Modern browsers don't show subtle warnings for certificate problems. They show full-screen interrupts.
Chrome shows a red shield, the heading "Your connection is not private", and a wall of explanatory text. Below it, three options: "Hide advanced" (closes the explanation), "Back to safety" (large, the default), and a small "Proceed to [domain]" link buried in the advanced section. The wording, the colour, and the visual hierarchy all push the user toward leaving.
Firefox shows similar, with the heading "Warning: Potential Security Risk Ahead" and similar choice architecture.
Safari and Edge follow the same pattern.
On mobile, the warnings are full-screen with even less ability to dismiss them. Some mobile browsers don't even surface a "proceed anyway" option for cert errors.
This is by design. Browsers have been quietly making cert warnings scarier for a decade, because the alternative - users clicking through warnings habitually - was worse. The unintended side effect: when you have a cert problem, the same scary UI that protects users from real attacks treats your site like a phishing page.
The conversion math
Most teams underestimate the conversion impact of cert errors because they think of it as "downtime, which we measure in minutes." The actual math is more like "downtime, plus a retention penalty that lasts weeks."
Bounce rate during the outage. The bounce rate on cert error pages is closer to 90% than to the 30–50% you might be used to. Most users see the warning and leave immediately. This is consistent across studies of warning interactions over the past decade.
Recovery rate after the outage. Some users come back. New users - those who arrived for the first time during the outage - are the least likely to. They have no brand attachment to overcome the warning. They saw a security warning on their first visit and concluded the site wasn't trustworthy.
Returning users. Even returning users who liked your product see the warning and don't necessarily come back immediately. They might wait. They might forget. A subset will quietly stop using you.
For a marketing site, the cost is mostly opportunity - visitors who didn't sign up. For e-commerce, the cost is direct revenue - abandoned carts plus failed-to-arrive purchases. For SaaS, the cost is mostly trust - paying customers who saw a security warning on your login page and now have a small permanent doubt about your security posture.
For most organisations of any meaningful size, a single multi-hour cert outage is a five-to-six-figure event by the time you add it all up. Most of it doesn't show up in the post-mortem because the post-mortem only counts what happened during the outage, not after.
The brand trust angle
The harder cost to measure is the trust one.
A new customer who sees "this connection is not private" on your homepage doesn't think "oh, they have a cert problem." They think "this site is not safe." That impression survives the fix. The next time they're considering your product against a competitor, the small voice in the back of their head will say "weren't they the ones with the security warning?"
This is not paranoia. It is well-documented in marketing research that trust-undermining experiences have asymmetric impact - a single negative trust signal weighs heavily against many positive interactions. Cert warnings are exactly this kind of signal.
The implication: a cert outage isn't just an outage. It's a brand event. Treating it as a pure availability incident misses most of the cost.
The SEO penalty
Google notices when sites serve errors. Even if your site is back up within hours, the SEO impact can run for weeks.
Specifically: - Crawl frequency drops. Googlebot reduces how often it crawls a site that returned errors. - Indexed pages get demoted. Pages that returned cert errors during the last crawl can lose ranking until the next successful crawl. - User-signal patterns affect ranking. If users bounce hard from your site (which they will during a cert warning), Google's algorithms notice. Bounce signals accumulate.
The exact mechanics aren't public, but the pattern is consistent - a short cert outage can leave a multi-week footprint in search rankings. The recovery happens naturally, but you've lost the equivalent of weeks of acquisition while the algorithms re-learn that your site is healthy.
The "we'll just put up a status page" trap
A specific failure mode worth naming: teams assume that during a cert outage, their status page can communicate the issue and reassure users.
The status page is often on a different domain. The status page is not what users see when they hit the cert warning. The status page is for people who already know your company and care enough to navigate to it. New users - the ones bouncing hard - never see it.
A status page is necessary. It is not a substitute for not having the outage. The bounce happens before the user does anything but close the tab.
What to do
The fix isn't more sophisticated marketing copy on the status page. It's not having the outage.
- External monitoring that catches cert problems before customers see them. Not internal monitoring that trusts the renewal pipeline. Renewal margins that aren't measured in days. Multi-week overlap between old and new certs. Team-level ownership so that the renewal alert doesn't go to one person who's on holiday. A runbook so that even when something goes wrong, the time-to-resolution is short.
The cert problem isn't a marketing problem. The cert problem manifests as a marketing problem.
One small ask
A cert outage is a brand event, not just an availability event. The conversion damage outlives the technical fix. The cheapest insurance against this is monitoring that catches problems before users do. TLS Radar's free tier covers three domains and checks for the failure modes that translate directly into bounce rates - expiry, chain, cipher, hostname. Worth an afternoon to see whether your current setup would actually catch the next one before customers do.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.