在站点运营的日常里，robots.txt 往往是被改得最随意、也最容易被忘记的文件之一。它不像页面内容那样天天看，但只要某次临时维护时随手写了一句屏蔽规则，事后又没有清理，就可能在很长一段时间里影响蜘蛛对整站的抓取。这份自查清单围绕“规则有没有写对、有没有真的生效”展开，不涉及任何效果承诺。
先确认文件本身能被正常访问
robots.txt 有明确的路径要求：必须放在域名根目录下，也就是 /robots.txt，而不是某个子目录或二级路径。检查时重点看三件事：返回状态码是不是 200；内容类型是不是纯文本；有没有被重定向到别处。如果服务器对它返回 404，多数搜索引擎会按“没有限制”处理，但你可能会误以为自己一直控制着规则；如果它被 301 到站内其他地址，部分蜘蛛会跟随，部分不会，结果就变得不可预期。
Disallow 是最容易误伤的指令
Disallow 采用的是前缀匹配。也就是说，你写下的路径只要是被请求地址的开头部分，就会被挡住，这个特性经常被低估。
- Disallow: / 表示全站禁止抓取。维护期间加上它、事后忘记删除，是影响面最大的写法之一。
- Disallow: /tmp 不只挡住 /tmp 目录，也会挡住 /tmp-report、/template 这类同前缀路径。
- 只想挡住某个具体页面时，写成目录形式会让范围扩大，务必逐条确认实际影响到的地址。
- 已经删除的规则最好一并清理，避免规则列表越堆越长，维护时看不清谁在起作用。
通配符与结尾符要写准位置
星号匹配任意字符，美元符号表示地址结尾。例如用星号加参数名可以挡住带参数的打印页，用结尾符可以精确挡住某类后缀文件。位置写错时，要么范围被放大，把正常栏目一起挡掉，要么范围过窄，等于没写。写完建议拿实际地址在测试工具里逐条比对。
Allow 与 Disallow 同时命中时怎么处理
当一条地址同时符合 Allow 和 Disallow 时，多数引擎遵循“匹配长度更长的那条优先，长度相同时 Allow 优先”的规则。这套逻辑在需要放开某个子目录时很有用，但不同引擎的实现细节并不完全一致。稳妥的做法是：规则尽量写得直白，避免依赖过于绕的优先级判断，并在变更后用官方测试工具确认结果符合预期。
Sitemap 与 Crawl-delay 的注意事项
- Sitemap 指令要写完整的绝对地址，一行一条，可以指向 XML 站点地图，也可以指向站点地图索引文件。
- 地址写错、写成本地路径或指向已下线的文件，等于白写一条，建议定期点开确认可访问。
- Crawl-delay 的支持度有限，不同引擎对待方式不同，不适合当作限速的主要手段，服务器压力问题更适合从缓存、并发和资源体积上解决。
不要顺手把静态资源一起挡掉
有些站点为了省抓取预算，会把样式表、脚本、图片目录整片屏蔽。这在纯文本抓取年代问题不大，但现在渲染页面时需要这些资源才能还原真实版式。如果确实要限制，建议分清哪些资源影响页面呈现、哪些只是统计或临时文件，分别处理，而不是一刀切。
规则改动的上线流程
- 在本地或测试环境写好新版本，逐条对照实际目录结构确认路径拼写。
- 用搜索引擎官方提供的 robots.txt 测试工具跑一遍，输入几个关键地址看判定结果。
- 上线后观察服务器日志，确认被挡目录的请求确实减少、应放开的目录仍有正常抓取。
- 保留历史版本或改动记录，出问题时能快速回退到上一版。
用日志确认规则真的生效
规则改动后最直接的反馈来自访问日志。可以关注两点：一是原本被屏蔽的目录是否还在收到请求，如果仍在，可能是缓存、CDN 层或规则未生效；二是正常栏目的抓取是否出现异常下降，如果出现，要回头检查是不是某条新规则误伤。把日志和规则文件对照着看，比凭印象判断可靠得多。
robots.txt 的作用是表达抓取意愿，不是控制收录结果的手段。规则写得越克制、越具体，后续排查成本就越低。
建议把 robots.txt 纳入站点的定期巡检项，和站点地图、状态码分布一起看。每次改动前先问一句：这条规则会影响哪些地址，改动后从哪里能验证。养成这个习惯，能避免很多事后才发现的问题。