给站点装上证书、把访问地址切到 https，通常只是运维层面的一个动作。但切换完成之后，页面上只要还残留一个 http 开头的图片、脚本或样式，浏览器就可能在地址栏收起锁形图标，或者直接把这段资源拦下来。这类问题不会让整站打不开，所以很容易长期潜伏，直到某天有人截图反馈才被发现。
为什么值得单独查一遍
访客侧的体验是直观的：地址栏的提示一旦从安全变成不安全，表单填写、支付跳转这类动作的信任度会立刻下降。有些浏览器还会对混合内容做主动拦截，表现为图片空白、样式错乱、脚本不执行，而页面本身依然返回 200，从监控上看不出任何异常。
抓取侧同样值得留意。蜘蛛访问的是 https 地址，页面里却指着一批 http 资源，等于每抓一个页面都要多走一轮协议跳转；如果这些资源的域名已经停用或证书过期，抓取过程还会碰到一连串失败请求，白白消耗时间和连接数。
混合内容常见的几个来源
- 历史正文里的绝对地址：早期编辑在文章中直接粘贴了 http 开头的图片、附件或站外链接。
- 模板与主题里的硬编码：头部文件写死了 http 的字体库、统计脚本、CDN 前缀。
- 第三方组件：评论系统、客服悬浮窗、广告位、地图嵌入代码、分享按钮。
- 内容迁移遗留：从旧站导入的文章，正文内链和图片路径仍然是旧协议、旧域名。
- 缓存中的旧版本：CDN 或反向代理还缓存着切换前的 HTML，访客拿到的仍是老页面。
- 下一层资源：CSS 里用 url() 引用的背景图、JS 里拼接出来的接口地址，这些不会出现在页面源码的显眼位置。
怎么查：从人工抽查到批量扫描
- 打开浏览器开发者工具，切到网络面板，按协议或域名排序，把 http 开头的请求挑出来；控制台里通常也会有混合内容的告警。
- 用无痕窗口分别访问几类代表性页面：首页、栏目列表页、内容详情页、站内搜索结果页、带表单的页面。缓存会掩盖问题，无痕加禁用缓存更可靠。
- 把页面源码抓下来做文本检索，搜索 http:// 和 // 开头的写法，重点看模板文件和公共头部、底部。
- 顺着 CSS 和 JS 再查一层，很多资源是在样式表或脚本里被间接引用的，只查 HTML 会漏掉。
- 单独用移动端或窄屏设备看一遍，部分站点会按终端下发不同的模板，问题可能只出现在其中一套。
- 检查响应头里的 Content-Security-Policy，如果设置了 upgrade-insecure-requests，实际表现会和源码看起来的不一致，排查时别被误导。
修复时的几个注意点
- 能改相对路径就改相对路径，能改协议相对写法就改协议相对写法，减少以后再次切换域名时的工作量。
- 批量替换前先备份，并且注意 http:// 也可能出现在正文的示例文本、代码块里，全局替换会把不该动的内容一并改掉。
- 有些老服务确实不支持 https，这时要考虑换源或把资源放到自己服务器上，而不是简单地改个前缀了事。
- 改完之后再走一遍重定向检查，确认没有因为协议切换产生新的跳转环或者多余的中间跳。
- 如果用了 CDN，记得刷新对应目录的缓存，否则修好的页面可能还在边缘节点上睡着旧版本。
一份简单的自查清单
- 首页与主要栏目页的地址栏提示是否正常，没有“不安全”或警告图标。
- 页面源码中是否还存在指向 http 的图片、脚本、样式引用。
- CSS 与 JS 内部引用的下一层资源是否也已切换。
- 第三方组件、统计代码、客服脚本的地址是否为 https。
- 站内旧文章正文中的图片与内链是否已批量处理。
- HTTP 到 HTTPS 的跳转是否为单次跳转且无循环。
- sitemap、robots 中声明的地址与当前访问协议是否一致。
协议切换不是一次性任务，而是一条需要定期回看的检查项。新发布的文章、新接入的第三方服务、新换的模板，都可能把 http 资源重新带进来。把它纳入日常巡站流程，比事后补救省力得多。