robots.txt 是站点里成本最低、也最容易写错的一个文件。它往往只有几行，却直接决定蜘蛛能不能碰到你的页面。很多人把它当成临时开关，随手 Disallow 一下，过几天忘了删，结果整站或某个重要栏目长期抓不到，等到检查收录时才回头找原因。
先把它的定位说清楚
robots.txt 管的是“抓取”，不是“索引”。两个概念混在一起，规则就容易写反。
想让页面彻底不出现在结果里，应该用 noindex 并允许抓取；反过来，被 Disallow 的页面蜘蛛读不到 noindex，那条指令等于白写。用 robots.txt 去“删除”内容，通常只会得到一条没有摘要的结果。
逐条自查清单
- 位置与状态码：文件只能放在域名根目录下的 /robots.txt，正常返回 200。返回 404 一般会被当作“全站可抓”，返回 5xx 则可能被理解为“暂时全站不可抓”，两种情况都会带来意外。
- 通配符与结尾符：* 匹配任意字符，$ 表示路径结尾。写 /search 会连带挡掉 /search-help，写成 /search$ 才只挡这一条路径。
- 路径大小写：规则匹配通常区分大小写，别默认小写路径就能覆盖全部变体。
- 分组结构：User-agent 与其下的规则是一组，组内不要随意插空行，避免把规则拆到别的组里去。
- Sitemap 指令：把地图地址写进文件，方便蜘蛛顺着发现 URL，与站内链接形成互相补充。
- 分环境处理：测试站、预发站优先用登录鉴权或 noindex 来处理，不要指望 robots.txt 挡住整站；一旦被外部链接引用，问题照样会漏出去。
三类常见误伤
把 CSS 和 JS 一起挡掉
渲染页面需要拿到样式和脚本资源，这些目录一旦被屏蔽，蜘蛛看到的页面结构可能变形，对正文的判断也会受影响。
用目录级规则做批量清理
Disallow: /tag/ 这类目录屏蔽写起来很快，但目录里常常混着有流量的聚合页。建议先看日志里这些 URL 的抓取频次和落地表现，再决定是整块屏蔽还是逐条处理。
规则长期不清理
临时上线的活动目录半年后早已下线，屏蔽规则还留着；新栏目恰好复用了同一个路径前缀，于是上线当天就抓不到。改版、下线栏目时顺手过一遍 robots.txt，成本很低。
改完怎么验证
- 用浏览器或命令行直接访问 /robots.txt，确认内容与状态码符合预期；
- 用搜索平台的 robots 测试工具对具体 URL 做一次判断，看结果是允许还是被规则挡住；
- 对照服务端日志，观察被挡目录下是否还有抓取请求，若仍有请求，说明规则写法或缓存有问题；
- 记录每次修改的时间和原因，避免下次没人说得清哪条规则是谁加的。
小结
robots.txt 的语法并不复杂，难点在于它容易被当成一次性操作。更稳妥的做法是把它当作配置文件来维护：写清楚、测一遍、定期复查。蜘蛛的抓取预算有限，规则写对，该抓的页面才不会被误伤。