现场是这样的。一次线上故障用 git revert 回滚了发布分支，仓库里跟踪的 robots.txt 跟着回到三个月前的测试版，Disallow 里还留着 / 和 /staging/。两天后抓取量掉到 8%，才发现文件被覆盖。
中间走过弯路，把「发布流程不对 robots 做校验，改完直接推上去」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。robots.txt 纳入版本管理且生产与测试共用同一份；回滚脚本按整个目录 checkout，没有排除配置文件；CDN 缓存了旧 robots，源站改回来还要等 TTL。
动手时先比对仓库与线上的差异
curl -s https://www.example.com/robots.txt | diff - robots.txt回滚时排除 robots 与 sitemap
git checkout HEAD~1 -- . ':(exclude)robots.txt'然后加一条发布前校验
grep -q 'Disallow: /$' robots.txt && exit 1等前面都确认过，再清掉 CDN 上的 robots 缓存
curl -X PURGE https://www.example.com/robots.txt别只看报错消失，验证要多做一步。发布后 robots 与主干一致，抓取量在 48 小时内回到回滚前水平，流水线里的校验能拦住同类改动。
补一句。配置文件跟业务代码绑在一起发布，早晚会被回滚带走，分开管理比事后补救省事。这类问题最好一次改到位，反复小改反而容易把原因搅混。