安全修复对搜索引擎索引的隐性影响

　　一个月前运维突然说安全组策略要升级，我原以为就是改几个端口规则，结果这帮人把HTTP头全给重写了——现在所有页面返回的X-Frame-Options都变成DENY了，连测试环境的静态资源都带上了CSP。最绝的是他们没通知SEO团队，等运营发现流量掉三成的时候，百度蜘蛛已经抓了三天403了。当时我正在改一个低端机兼容问题，手机突然震动，一看是SEO总监在群里@所有人：“谁动了头信息？站长平台现在显示我们被标记为恶意跳转了！”

文章配图，仅供参考

　　最坑的是修复过程。SEO团队要求我们“立刻恢复旧头信息”，但安全组说新策略能防90%的XSS攻击。两边在钉钉群里吵了俩小时，最后折中方案是在Nginx里加条件判断：只对百度蜘蛛的User-Agent放行旧头信息。结果改完第二天，谷歌搜索控制台开始报“不安全的HTTP头组合”——原来百度和谷歌的蜘蛛User-Agent有重叠字段，现在部分请求会同时收到新旧两套头信息，直接触发浏览器安全策略拦截。

　　那天我盯着Chrome开发者工具看了半小时，发现个更离谱的事：安全组加的Referrer-Policy: strict-origin-when-cross-origin，导致所有外部链接的referrer信息全丢了。运营说他们合作方的数据统计全乱了，对方CTO直接打电话过来问：“你们是不是买了黑产流量？”我转头看运维小哥，他正用马克笔在白板上画头信息传递链，笔尖突然断了，墨水溅到他新买的AJ上——那双鞋他上周刚在得物花了三千八买的。

　　但说真的，这事儿最后能解决，靠的居然是“优胜劣汰”。百度蜘蛛在连续抓了五天403后，自动降低了我们网站的爬取频率，结果那些低质量页面（比如三年前活动页）的索引全掉了，反而让核心页面的排名上升了。SEO总监现在逢人就说：“早知道该早点让安全组把垃圾页面全屏蔽了。”——他上周还在群里骂安全组“不懂业务”。

　　不过最让我后怕的是，安全组在升级策略时，居然没测试移动端。有天我拿自己手机（三年前的华为P20）试了下，发现部分页面因为CSP限制，连内联CSS都加载不了，直接白屏。而运营总监的手机是iPhone 14 Pro Max，她根本没发现这个问题——直到有用户投诉说“你们页面在旧手机上打不开”，她才在群里说：“是不是前端又搞了什么新框架？”

　　现在回头看，这事儿最魔幻的地方在于：安全修复本来是为了防攻击，结果因为没考虑搜索引擎和老设备的兼容性，反而造成了更大的业务损失。就像我们之前为了防XSS把所有用户输入都转义了，结果导致富文本编辑器里的表情包全变成乱码——最后还是产品经理拍板说：“先让用户能发消息，攻击的事以后再说。”

　　我现在桌上还贴着那张被运维小哥画满的头信息传递链白板照片，墨水渍刚好盖住了“User-Agent判断”那部分。昨天SEO团队又来找我说要“优化CSP策略”，我直接把照片发给他们：“先问问安全组同不同意。”——他们现在见着我都绕着走。

　　下一步我打算写个自动化脚本，每次安全组改策略时，自动抓取站长平台的索引数据。但运维说AWS的CloudTrail日志太复杂，可能需要重构整个监控系统——算了，还是等他们下次把事情搞砸再说吧。反正最后背锅的又不是我。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!