robots.txt 是站点上最容易写错、又最难立刻发现的文件之一。它不参与页面渲染，出问题时页面照样能打开，用户毫无感觉，但蜘蛛可能已经按你的规则停止抓取某个目录，甚至整站。尤其是接手他人站点、或者刚做完目录调整之后，建议把这个文件排进例行自查。
一、确认文件位置与可访问性
robots.txt 只对根域生效，必须放在站点根目录，例如 https://example.com/robots.txt。放在子目录里（如 /blog/robots.txt）不会被当作规则文件读取。用浏览器或命令行直接访问一次，确认返回 200，内容类型是纯文本，而不是被框架路由接管后返回首页 HTML，也不是被安全策略拦截成 403。
如果站点有多个域名、多个环境（正式、预发、测试），要逐一确认：预发环境通常整体禁止抓取，正式环境才放开。把这条当成固定检查项，可以避免测试规则随手发布到线上。
二、常见的误写与风险
- 整站误封：Disallow: / 没有被注释掉，也没有做环境判断，直接留在了线上。
- 路径写得太宽：想挡 /search，结果写成 Disallow: /s，顺带把 /service、/shop 等目录一起挡住了。
- 挡住静态资源：屏蔽 CSS、JS、图片目录，蜘蛛拿不到渲染所需资源，对页面内容的判断会受影响。
- 规则分散冲突：同一个 User-agent 分成多段，或在多个位置各写一份，维护时只改了其中一处。
- 把 robots.txt 当权限工具：它只能表达“不希望被抓取”，不能阻止访问，敏感内容应靠登录与鉴权处理。
三、逐项自查清单
- 访问根目录 robots.txt，确认状态码与内容正确，没有落到 CDN 上的旧版本。
- 检查是否存在 Disallow: / 或等价的全站禁止规则，已注释的除外。
- 逐条读 Disallow 路径，确认没有意外覆盖正常栏目目录。
- 确认 CSS、JS、字体、图片等资源目录未被整体屏蔽。
- 同一 User-agent 的规则是否集中在同一段，是否存在重复段落。
- Sitemap 指令指向的地址可访问，且与当前 sitemap 版本一致。
- User-agent 名称拼写与大小写正确，写错的名字不会命中任何蜘蛛。
- 如果设置了 Crawl-delay，确认数值合理，过大会明显拖慢抓取节奏。
四、改动流程与验证
robots.txt 的改动影响面大，建议走和代码一样的流程：改动前记录当前版本，改动后先在预发或小范围环境验证，再发布上线。发布后观察几天访问日志，看目标蜘蛛的抓取频次与路径是否朝预期方向变化；如果某个栏目抓取量骤降，先回滚再排查原因。
robots.txt 是建议，不是闸门。它影响蜘蛛“愿不愿意”抓，而不是“能不能”抓。真正需要保护的内容，请用登录、权限与服务器层规则处理。
五、与其他配置保持一致
robots.txt、sitemap、canonical、站内链接共同决定了蜘蛛看到的站点范围。如果 sitemap 里提交了某个目录，而 robots.txt 又把它挡住，两边就互相矛盾；同理，栏目下线后除了加规则，也要把 sitemap 中的地址同步清理。定期把这几份配置放在一起对照一遍，比单独检查某一个文件更容易发现不一致。