一张过期的 SSL 证书,如何让你的店铺在 48 小时内从 Google 消失
证书在周三凌晨 03:14 过期。周五早上自然流量崩盘。这不是运气差,而是可量化的失职。
波尔图一家办公设备店在周三到周五之间损失了 78% 的自然流量。网站已经几周没人动过。问题只占一行日志:SSL 证书在周三凌晨 03:14 过期了。
那天早上 Googlebot 再次爬取时,撞上 ERR_CERT_DATE_INVALID。它什么都没索引。更糟的是,它把这个域名标记为对用户不安全——哪怕用户点的还是缓存里的搜索结果。48 小时内,Chrome 已经在首页之前先弹出那块红色警告屏。
为什么 Google 反应这么激烈
HTTPS 从 2014 年起就是排名信号。从 2018 年起,Chrome 把 HTTP 直接标为「不安全」。一张过期的证书比 HTTP 更糟——那是坏掉的 HTTPS。浏览器把它解读为冒充网站的企图,哪怕真相只是 acme.sh 没续期成功。
Googlebot 把 TLS 握手失败当成抓取错误。它重试、失败、再重试、再失败。几个小时后开始反向索引。页面不会立刻从索引里消失,但排名一路掉下来,因为信任信号已经归零。
现实里发生了什么
- 周三 03:14——Let's Encrypt 证书过期。过去 30 天里续期 cron 已经失败过三次。没人看那封邮件。
- 周三 08:00——第一批手机用户看到红色警告。跳出率直线上升。
- 周三 11:30——Googlebot 来爬,握手失败,批量记录为 soft 404。
- 周四早上——Search Console 发出「覆盖率」告警。没人打开 Search Console。
- 周五 09:00——销售停摆。客户打电话给开发者。开发者四分钟内查出问题。
续期本身花了 90 秒。排名恢复花了 23 天。这段时间里,竞争对手抢下了核心关键词的头部位置,而且再也没完全松手。
为什么 cron 失败了
服务器在一月换过 IP。DNS 指向是对的,但 Let's Encrypt 的 HTTP-01 挑战撞上了一道新防火墙,后者屏蔽了来自 ISRG 网段的请求。每一次续期尝试都把错误写进一份没人读的日志。
这是常态。证书过期,不是因为续期难。是因为自动续期悄无声息地失败,而没人在正确的日志上挂告警。
今天就该做的事
- 监控证书本身,而不是 cron。用 UptimeRobot 或 StatusCake 这类外部服务,设成过期前 14 天报警。
- 告警走 Telegram 或短信,别走邮件。Let's Encrypt 的提醒邮件进的是一个没人看的邮箱。
- 每周看一次 Search Console。Googlebot 在失败,白纸黑字写在那里。
- 每季度手动测一次续期。如果 cron 在生产能跑、在 staging 不能跑,说明配置已经漂移。
- 写好紧急续期手册。当网站在周五 18 点宕机时,你不想现学 acme.sh。
过期证书是损失六个月 SEO 最便宜的方式。预防花零欧元,补救要花三个月薪水。— 波尔图客户事故后内部审计
真正的代价
这家店当月营业额比季度均值少了 31000 欧元。重做服务器的开发者收了 180 欧元解决问题。预防的成本本来是零——多一个健康检查的 cron 任务,加一个发到 Telegram 的 webhook。
如果你在中国做电商,却没有独立监控自己服务器上的那张证书,你离失去整个季度只差一次续期失败。这不是危言耸听,这是算术。
规则很简单。别相信负责续期的 cron。要相信那个外部监控——它会去核实 cron 真的续了。