robots.txt 是站点根目录下一个纯文本文件，改动一行就可能影响整站的抓取范围，但它往往不在日常检查清单里。它不像页面模板那样每次发布都会被看到，出问题时也不一定有肉眼可见的表现，所以更适合用固定的检查项定期过一遍。
为什么它值得单独自查
搜索引擎蜘蛛在抓取一个站点前，通常会先读取 robots.txt。这份文件决定了哪些路径可以被访问、哪些不可以。一旦规则写错，受影响的不是某一个页面，而是整片目录。从站内看，页面一切正常，访客照常访问，只有抓取和发现环节悄悄变窄。
常见的问题类型
- 误把屏蔽整站的规则带上线。常见于测试环境为了不被抓取而写下的规则，部署时忘记删除。
- 屏蔽了样式和脚本目录。蜘蛛需要渲染页面来判断内容，屏蔽 CSS 与 JS 会让它看到的页面和访客看到的不一致。
- 路径写法不严谨。大小写、结尾斜杠、通配符位置不同，匹配范围可能完全不一样，容易连带屏蔽不相关的目录。
- Sitemap 指令写错。域名拼写错误、用了相对路径、指向 404 或重定向地址，都会让这份声明失去作用。
- 规则过期没人清理。栏目早已下线，屏蔽规则还留在文件里，而新页面刚好落在同一路径下。
一次完整的自查流程
- 直接访问站点根目录下的 robots.txt，确认返回状态码是 200，内容是当前最新版本，而不是旧文件或缓存页面。
- 逐行读一遍 Disallow 与 Allow，确认没有整站屏蔽，也没有意外覆盖正常栏目的规则。
- 检查 Sitemap 行，必须是带协议和域名的完整地址，并且能在浏览器里直接打开。
- 确认被屏蔽的目录中，没有页面模板依赖的静态资源。
- 挑几个有代表性的地址，用搜索控制台提供的 robots.txt 测试功能验证是否被允许，注意不同用户代理的结果可能不同。
- 对比测试环境和线上环境，确认发布流程里没有把测试规则带出去。
- 把 robots.txt 的修改纳入上线检查表，每一次改动都留一条记录和回退方案。
它不该承担的事
第一，不适合用来隐藏内容。屏蔽抓取不等于从索引中移除，已经收录的地址仍可能出现在结果中，只是描述信息可能缺失。真要控制索引，应该用页面级的 noindex 或地址规范化处理。
第二，不负责权重分配。不希望被收录、不希望被传递信号的页面，应该靠链接结构和页面标记解决，而不是靠一条 Disallow。
第三，不能当安全措施。敏感目录、后台入口、备份文件，靠的是权限控制和访问限制，而不是一份公开可读的文本文件。
关于抓取缓存
蜘蛛会缓存 robots.txt 一段时间，改动后不会立刻生效。如果是因为误屏蔽引发的大范围问题，除了修正文件，还可以通过搜索控制台提交重新抓取，让新规则尽快被读取。
robots.txt 的作用是引导抓取，而不是关门。规则越少越简单，越不容易出事故。
小结
把它当成一份需要版本管理的配置文件：上线前读一遍，改动后记一笔，出问题时能快速回退。这样即使规则写错，也能在影响扩大之前被发现。