robots.txt：发布系统把配置覆盖回旧值时怎样追踪来源，先固定证据：抓取线上文件与版本记录对齐
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a4dfccf1eed7.html
📄
robots.txt：发布系统把配置覆盖回旧值时怎样追踪来源，先固定证据：抓取线上文件与版本记录对齐
先别急着改规则。把线上正在生效的 robots.txt 抓下来，与发布仓库里最后一次合并的内容逐行比对，确认差异是“旧值被写回”还是“新值从未发布”。如果是前者，追踪重点应放在发布流水线的写入环节；如果是后者，问题在提交或构建阶段，追踪方向完全不同。下面以一个你手头可访问的文件为对象，给出可执行的处理顺序。
先固定证据：抓取线上文件与版本记录对齐
取一份线上文件的原始内容，保存为带时间戳的副本，同时导出该路径最近若干次提交记录。把两者按行对齐，标出三类差异：整段缺失、指令值不同、注释与空行变化。注释和空行通常不影响抓取行为，但它们的出现位置能提示是哪套模板或哪个脚本写入了文件。
如果线上内容与某次历史提交完全一致，而当前分支内容不同，基本可判定存在回写。此时记录三样东西：回写值对应的提交哈希、该提交的合并时间、线上文件被观测到的时间。这三者构成后续定位的时间窗，比笼统地说“配置被覆盖了”有用得多。
区分两种覆盖路径：发布产物回滚与配置源被重写
回写通常来自两条不同路径，处理方式不同：
- 产物回滚：发布系统把旧版本的构建产物重新部署，robots.txt 只是被顺带带回旧状态。特征是同一批次的其他静态文件也回到旧版本。
- 配置源被重写：某个配置管理工具、模板渲染步骤或人工操作把旧规则写进了当前版本的源文件。特征是其他文件保持新版本，只有 robots.txt 内容倒退。
判断方法很直接：抽查同一发布批次里另一个近期改动过的静态文件，看它是否也退回旧值。若只有 robots.txt 倒退，优先排查配置源；若多个文件一起倒退，优先排查发布产物与回滚机制。
用写入日志把范围缩到具体环节
确定路径后，在候选环节上加最小化的观测点。假设存在一条从模板到线上文件的写入链，可在每个写入步骤后记录文件内容的哈希值，而不是记录全文，避免日志膨胀。当哈希在某一环节之后发生变化，该环节就是嫌疑点。
一个假设的例子：模板渲染后哈希为 A，打包后仍为 A，部署到目标目录后变为 B，而 B 正好等于两周前的版本。这说明覆盖发生在部署这一步，而不是模板或打包。下一步就应检查部署脚本是否带有“仅同步差异”或“从备份恢复”的逻辑，而不是继续在模板里找问题。
如果拿不到写入日志，退而求其次：在配置源里加入一条无副作用的注释标记，重新发布一次，观察该标记是否出现在线上。标记消失说明写入链中某一步用了另一份来源；标记存在但规则仍旧，说明来源正确、后续有覆盖动作。
修正前先确认影响，再决定回退还是前滚
robots.txt 的抓取限制不等于可靠的索引移除。即使旧值里包含禁止抓取某些路径的规则，也不应假定已收录页面会因此消失；同样，放开限制也不保证立即恢复抓取。站点地图不保证收录，这两件事要分开看。
决定动作前，先明确两个条件：
- 旧值比当前值更宽松，还是更严格。更严格时，抓取受限的路径需要单独评估已收录状态；更宽松时，重点看是否暴露了本不应被抓取的路径。
- 覆盖是否仍在持续发生。若写入链未修复，直接改线上文件会在下一次发布时再次被覆盖。
因此正确的顺序是：先切断或修复覆盖来源，再发布正确内容，最后观察抓取日志中相关路径的请求变化。若跳过第一步，观测到的现象会反复出现，无法判断修正是否生效。
把追踪固化为下一次可复用的检查
在流水线里保留一份线上 robots.txt 的哈希记录，每次发布后自动比对。差异出现时，输出回写值对应的提交标识和触发环节。这样下一次同类问题不需要重新从零排查。
需要说明的是，请求量或抓取量归零不能单独证明覆盖已被正确处理，它也可能来自抓取预算调整、路径本身流量低或其他配置变化。判断依据仍应是文件内容与写入链状态，而不是单一指标。不同搜索引擎对 robots.txt 的支持细节须分别核查，不要把一份文件的观测结果直接外推到所有抓取方。
