robots.txt 是站点与搜索蜘蛛之间的第一道约定。它本身不复杂，但正因为它简单，很多站点上线之后就很少再回头看。等到发现收录异常、栏目迟迟不被抓取时，往往已经过去几周。把 robots.txt 当成需要定期复核的配置文件，比出问题后再排查要省事得多。
为什么 robots.txt 值得单独自查
抓取预算有限，蜘蛛进入一个站点后的第一步通常就是读取 robots.txt。如果这里写错了，后面的 sitemap、内链布局、内容更新节奏都很难发挥作用。常见的错误并不隐蔽，只是平时没人对着线上文件逐行读一遍：
- Disallow 写成整站屏蔽：一行 Disallow: / 可能来自测试环境的复制粘贴，上线时忘了删。
- 分组写错：User-agent 行与规则之间被空行或注释打断，导致规则归属到别的分组。
- 路径匹配理解偏差：前缀匹配、结尾通配符和中间通配符的写法不同，屏蔽范围差别很大。
- 大小写与编码问题：URL 路径大小写敏感，规则里写错一个字母就可能漏掉或误伤。
自查时重点看哪几项
1. 整体是否存在整站屏蔽
先确认没有任何一条规则把根路径全部挡住。测试环境的默认配置、框架自带的模板，都可能悄悄带进这一条。抓取测试工具能给出结果，但更可靠的做法是自己读取线上返回的内容，而不是看本地文件。
2. 关键目录是否被误伤
列表页、标签页、站内搜索页通常需要限制，但文章目录、栏目目录、静态资源目录不该被一起挡掉。检查每一条 Disallow 是否精确指向想限制的路径，而不是它的上级目录。一个常见的失误是限制 /tag/ 路径，却忘了站内搜索入口也用同一个前缀。
3. 是否与页面级指令冲突
robots.txt 只管抓取，不管索引；页面里的 noindex 才管索引。如果某类页面在 robots.txt 里被禁止抓取，同时又靠 meta robots 要求不索引，蜘蛛看不到 noindex，页面仍可能以 URL 形式出现在结果里。两者应当配合，而不是互相抵消。
4. sitemap 地址是否可用
robots.txt 里的 Sitemap 行是发现入口之一，写错路径等于少了一条通道。确认地址可访问、返回内容正常，并且指向当前主域，不要混用不同协议或带 www 与不带 www 的版本。
一轮完整的核查流程
- 访问线上 robots.txt，确认返回状态正常且内容是纯文本。
- 逐行核对 User-agent 与规则分组，删掉过期条目。
- 用抓取测试工具模拟蜘蛛访问首页、栏目页和一篇内容页。
- 检查关键页面是否被允许抓取，被限制的页面是否符合预期。
- 确认 Sitemap 地址有效，并与实际提交的地址一致。
- 改动后观察服务器日志，看蜘蛛对原先被挡路径的请求是否恢复。
改完之后的观察
robots.txt 的生效不是即时的。蜘蛛会缓存这份文件一段时间，尤其是原先屏蔽较久、抓取频次已经降低的站点。改动后不必立刻下结论，给一到两周观察期，结合日志里蜘蛛对关键路径的访问次数和状态码分布来判断。
如果只是放宽限制，通常较快能看到请求增加；如果是新增加限制，已经抓取过的页面不会自动消失。这时候需要配合页面级指令或内容调整，而不是指望一份文件解决全部问题。
把 robots.txt 当配置文件管理：改动留记录，上线前复核一遍，别让它成为没人负责的角落文件。