robots.txt 是站点和搜索引擎之间最基础的一份约定文件，一般只有几十行，改起来几乎零成本，但也因此最容易被随手改坏。它不决定页面能否被收录，只影响蜘蛛能不能抓，所以写错之后往往不会立刻报错，而是等抓取量慢慢下滑才被察觉。
先明确它管什么、不管什么
robots.txt 控制的是抓取范围，不控制索引结果，也不能替代权限校验。用它挡后台、挡测试目录只是权宜之计，只要有人贴出链接，内容仍然可能出现在结果里。真正敏感的内容应该靠登录态、权限系统或 noindex 处理。
逐项自查清单
位置与可访问性
- 文件必须放在域名根目录，子目录下的 robots.txt 不会被读取。
- 直接访问应返回 200 与纯文本类型，不要出现多级跳转、验证码页或登录页。
- 检查 CDN、WAF 是否对 robots.txt 做了限流或拦截，返回 403、503 时对方可能按不可用处理。
- 确认 www 与非 www、http 与 https 各版本都能读到同一份内容，或至少各有可用的一份。
语法与分组
- User-agent 分组之间用空行分隔，同一分组的规则要写在一起，否则后面的规则会失效。
- 规则名统一使用常见写法，避免大小写混排带来的解析差异。
- Allow 与 Disallow 同时命中时，一般以更具体（路径更长）的规则为准，写规则时按这个思路检查。
- 某条规则留空，例如只写 Disallow: ，代表不限制，不要用它来表达“禁止全部”。
通配符与结束符
* 匹配任意字符，$ 表示路径结束，这两者配合不当最容易误伤。比如 Disallow: /*.pdf 会挡住全站 PDF，Disallow: /tag/ 会连同 /tags/ 之类前缀相同的路径一起命中。写完最好用几个真实 URL 逐一过一遍。
Sitemap 声明
在文件末尾写明站点地图地址是常见做法，注意地址要与实际可访问的版本一致，避免 http、www、旧域名混用。若站点有多个子域或分站，可以分行列出多份。
抓取频率
Crawl-delay 的支持情况因搜索引擎而异，不宜作为限流主力。真正想控制压力，更应该从缓存策略、响应时间和服务器容量入手。
几种常见误配
- 测试环境的规则被同步到正式站，例如整站禁止，上线后无人复查。
- 屏蔽目录时漏了细节，本想挡 /search，结果连 /search-guide 这类正常栏目一起挡住。
- 用 robots.txt 处理重复内容，以为不抓就不会重复，其实更合适的手段是 canonical。
- 多份文件互相覆盖，改版时留下了旧站点的 robots.txt，新目录规则缺失。
改动后的验证流程
- 在本地或预发环境先写好规则，用真实 URL 逐一核对命中情况。
- 上线后直接访问根目录文件，确认内容与预期一致，没有读到缓存旧版本。
- 用日志观察几天，看被屏蔽目录的抓取请求是否下降、目标目录是否正常上升。
- 把本轮改动的规则、原因和日期记在运维文档里，方便下次回溯。
不建议频繁微调 robots.txt。每次改动都会改变蜘蛛的抓取路径，短期内抓取数据波动属于正常现象，观察周期最好放宽到一周以上。
多环境与改版的注意事项
如果站点有测试、预发、正式三套环境，建议让正式环境的 robots.txt 单独维护，不参与代码合并，避免被覆盖。站点改版更换目录结构时，除了更新规则文件，还要同步检查内链、站点地图和各处硬编码的路径，避免规则指向已经不存在的目录。
整体上，robots.txt 的自查不需要多高深的技巧，重点在于：确认它没有挡住该抓的目录，也没有被当成安全工具使用，并且每次改动都有记录可查。把这些做到位，它就是一个安静的基础设施，而不是一个随时可能踩到的坑。