网站被百度收录：发布系统把配置覆盖回旧值时怎样追踪来源
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fcf711037d45.html
📄
网站被百度收录：发布系统把配置覆盖回旧值时怎样追踪来源
先给有条件的结论：如果发布后配置短暂正确、随后又变回旧值，且回滚时间与某次部署、定时任务或配置中心推送高度重合，那么来源通常在那条“会写配置”的链路上，而不是百度抓取本身。反例是：若旧值从未被新值真正写入过磁盘或缓存，你看到的“被覆盖”只是读取层一直读旧副本，此时追发布系统会找错方向。
先确认是“被写回”还是“从未写进去”
这两种情况的证据完全不同。判断方法是绕过发布系统，直接读最终生效位置：
- 直接请求线上 robots.txt 或目标页面的 meta，记录响应头时间与内容哈希。
- 登录机器读取磁盘上的实际文件，比对同一时刻的哈希。
- 如果存在 CDN 或反向代理，单独请求源站，排除边缘缓存。
假设一次发布把 Disallow: /old-path/ 改成允许抓取，但十分钟后又变回禁止。若源站文件哈希一直是新值，只有边缘节点返回旧值，那问题在缓存刷新，不在发布系统写回。若源站文件也变回旧值，才进入下一步。
把“写入者”缩小到具体进程和时间点
确认文件确实被改回后，需要找到是谁写的。可行动作是给配置文件加文件修改时间监控，并在发布流水线里记录每次写配置的提交号、执行人和时间。把回滚时间与这些记录对齐，通常能排除大部分候选。
常见来源有三类，区分证据如下：
- 发布流水线自身：旧版本镜像或旧分支被重新部署。证据是部署记录里出现一次更早的构建号。
- 配置中心或定时任务：某个任务周期性把默认值推回。证据是回滚时间呈固定间隔，而非跟随人工操作。
- 多实例竞争：部分机器仍在跑旧进程，健康检查把流量切回旧实例。证据是不同机器上的文件哈希不一致。
只有第一类与“发布系统覆盖”直接相关；后两类即使发布系统正常，也会表现出同样的旧值结果。
用一个可核对的短例子说明取舍
假设某站点把 robots.txt 从禁止整站改为只禁止后台路径，发布后五分钟生效，二十分钟后恢复禁止整站。此时有两种处理顺序：
- 若监控显示文件修改时间正好在二十分钟处，且提交者是一个每日执行的同步脚本，优先停掉该脚本再重新发布，观察旧值是否还出现。
- 若文件修改时间没有变化，只是线上响应变旧，优先查缓存刷新与多实例一致性，不要改发布流程。
选错顺序的代价是：改发布流程不会影响定时脚本，旧值仍会回来，而你会误以为修复无效。
追踪来源时的两个失效条件
第一，如果配置读取有多层缓存且没有统一失效机制，文件已更新但读取层仍返回旧值，此时所有“写回”证据都不可靠。第二，如果机器人抓取限制与索引状态被混为一谈，你会把抓取异常误判为配置回滚。robots.txt 的限制不等于可靠的索引移除，抓取量变化也不能单独证明配置处理正确，它还可能来自抓取预算调整或页面本身的可访问性变化。
因此追踪前要先固定一个可复核的判定点：以源站实际文件内容为准，而不是以百度返回的抓取结果为准。
下一步动作与结果如何影响后续
完成定位后，做一次受控验证：停掉疑似写入源，重新发布正确配置，连续记录至少三个检查点的文件哈希与响应内容。如果旧值不再出现，说明来源已锁定，接下来应把该写入源纳入发布校验，例如在流水线末尾比对最终文件哈希，不一致则阻断发布。如果旧值仍出现，说明还有未发现的写入者，应扩大监控范围到配置中心和所有定时任务，而不是继续调整百度侧的提交动作。站点地图不保证收录，HTTPS 也不保证排名，这些都不应作为判断配置是否回滚的依据。
