證书問题是“平时無感、出事全站受影响”
不少站点在建站时配過一次 HTTPS，之後就把這件事從待办清單里划掉了。但證书有明确的有效期，域名覆盖范围也可能随着站点改版、子域拆分而發生變化。證书出問题通常不是渐進式的，而是某一天突然所有訪客看到浏览器警告，搜尋蜘蛛的抓取也會同步失敗。
這類事故的麻烦之處在于：它既影响用戶体驗，也影响抓取。訪客走了，蜘蛛也可能在握手失敗後减少来訪。所以與其等出事再處理，不如把它当成一個固定的运维检查項。
一、到期時間與續期方式
- 记錄每一張證书的到期日，留出至少两周缓冲，不要等到最後三天再動手。
- 確認續期是自動還是人工。自動續期也要確認执行结果，別只看到定时任務存在就放心。
- 把到期提醒發给至少两個人或一個公共渠道，避免负责人休假、离职时出現断档。
- 續期成功後，從外部訪問一次站点，確認新證书确實已经生效，而不是只更新了本地文件。
二、域名覆盖范围是否完整
列出站点實际在用的所有入口：主域名、带 www 的版本、移動端子域、静態资源域名、接口域名、活動专用子域。逐一驗證證书是否包含這些域名。泛域名證书只覆盖同一級子域，二級子域往往需要單獨確認。站点做過结构調整後，這一步尤其容易被忽略。
三、證书鏈是否完整
服務器只配置了站点證书、漏掉中間證书，是很多“部分设备能打開、部分设备报错”的根源。檢測时要從外部發起，而不是只在服務器本地用命令行測試。完整的鏈路應该让不同浏览器、不同系統都能顺利握手。
四、頁面里的混合内容
HTTPS 頁面中如果還引用 http 的图片、脚本、字体或样式，浏览器會拦截或给出降級提示。常见来源包括：老文章里粘贴的外鏈图片、舊模板残留的 CDN 地址、第三方小工具代碼。可以按协议批量掃描頁面源碼，把 http 资源逐條替換或改為相對协议引用。
五、跳轉與协议统一
確認 http 到 https、裸域到 www 的跳轉只有一层，並且跳轉目标本身可訪問。如果目标地址又跳一次，既浪費抓取，也容易在證书異常时形成循环。跳轉規則最好集中在服務器或 CDN 配置里，不要一處一處在頁面代碼中零散設定。
六、CDN 與多节点證书同步
使用 CDN 时，證书可能同时存在于源站和邊缘节点。續期之後要確認两邊都已更新，否則會出現源站正常、用戶訪問报错的情况。回源协议同样值得检查，不要让源站成為整條鏈路上的薄弱点。
七、外部监控與告警
從外部對首頁和几個關键栏目做定时探测，检查證书剩余天數、握手是否成功、返回狀態是否正常。告警要發到有人看的地方，比如值班群或工單系統，而不是只寫進日誌文件。监测频率不必太高，每天一次通常就够用。
證书真的失效了，按這個顺序處理
- 先確認影响范围：是全部域名還是某個子域，是全部訪客還是部分網絡环境。
- 優先恢复可訪問性：尽快完成續期並部署，不要在此时做其他變更。
- 從外部重新驗證：检查證书鏈、跳轉規則、頁面内资源是否還有 http 残留。
- 复盘提醒机制：把這次的触發時間往前挪，补上更早的提醒节点。
證书适合用固定检查項加自動提醒来管理，而不适合靠记忆。把检查動作寫進运维清單，比事後补救省力得多。
小结
把證书当成一個需要持續维護的對象，而不是一次性的配置動作。到期日、覆盖域名、證书鏈、混合内容、跳轉規則、CDN 节点、外部探测，這几項在每次續期後各看一遍，基本能把大部分意外挡在前面。對站点运营来说，這類基础項做得稳，後續的内容和结构優化才有意义。