robots.txt 是少数「改一行就可能让整站抓取停摆」的文件。它本身不产生内容，也不保证收录，但一旦写错，蜘蛛会直接放弃抓取，后面所有关于收录的动作都没有意义。真正麻烦的是，出错时往往不会有明显报错，只有抓取量悄悄下滑、收录慢慢减少。
下面这条顺序适用于大多数情况：先确认问题、再止损、然后重新递出入口、最后才是等收录恢复。
一、先确认影响范围，别急着大改
发现收录下滑后，第一步不是改文件，而是确认 robots.txt 到底屏蔽了什么。
- 用搜索引擎官方的 robots 测试工具读取线上文件，而不是看本地草稿。
- 检查是否出现了 Disallow: / 这类整站屏蔽，尤其是临时调试后忘记删除。
- 检查是否屏蔽了 CSS、JS、图片等渲染资源。页面本身可抓，但渲染资源被挡，蜘蛛拿到的可能是一个空壳。
- 检查 Sitemap 行指向的地址是否也被 Disallow 覆盖，屏蔽 sitemap 会让入口提交失效。
- 确认线上返回的是 200 且内容正确，而不是 404、403 或跳转到验证页。
如果只是屏蔽了某个目录，影响是局部的；如果是整站或渲染资源，问题会被放大。
二、止损：让文件回到可抓取状态
确认之后尽快恢复，动作要一次到位，避免反复修改。
- 修正 robots.txt 并发布，确认线上已经生效。
- 检查 CDN、反向代理、对象存储的缓存，旧版本被缓存会让修改变成「看起来改了」。
- 确认 robots.txt 没有被 WAF、防盗链或人机验证拦截，这类拦截对蜘蛛来说等同于无法读取。
- 用不同 UA 各请求一次，确认返回内容一致。
三、重新递出入口，恢复抓取信号
文件恢复只是让门重新打开，蜘蛛不会立刻回来。接下来要主动把重要 URL 再递一次。
- 重新提交 sitemap，并确认里面只有可索引、返回 200 的规范 URL。
- 对更新频繁的页面使用 IndexNow 或对应的提交接口，但不要高频重复提交同一批地址。
- 检查站内导航、面包屑、列表页和正文内链是否仍指向这些 URL，内部链接是长期有效的发现路径。
- 观察服务器日志中蜘蛛的请求量、状态码和抓取路径，确认它重新开始走正常入口。
这里不需要额外堆一堆提交渠道，重点是让入口清晰、可达、稳定。
四、等收录恢复：分清抓取恢复和索引恢复
抓取频次通常在几天内就会有反应，索引变化慢得多，可能是几周级别。这段时间可以观察：
- 日志里蜘蛛请求数是否回到改错之前的水平。
- 索引报告中「已抓取未索引」「已发现未抓取」的数量变化。
- 页面是否仍被判定为重复或内容单薄，这类问题不会因为 robots 修好就自动消失。
robots.txt 修好只解决了「能不能抓」，能不能收录仍然取决于页面本身的质量、重复度与站点整体信任度。
五、长期预防：把风险挡在改动之前
- 测试环境用访问密码或独立域名隔离，不要靠 robots.txt 屏蔽。
- 任何 robots.txt 改动都走一次评审，并记录修改时间、内容和负责人。
- 发布后立刻用线上地址验证一次，不要只看本地文件。
- 需要临时屏蔽时，尽量只屏蔽目录，不屏蔽整站，并设置明确的恢复时间。
把 robots.txt 当成配置资产而不是随手改的文本文件，收录波动会少很多。真出问题时，按「确认范围—止损—递入口—观察恢复」的顺序走，比反复修改、到处提交要有效得多。