robots.txt 很小，但它站在最前面
蜘蛛进入一个站点，第一步往往不是读首页，而是先取回 robots.txt。这份文件通常只有几十行，却决定了后面所有工作的起点：哪些目录可以被访问，哪些地址连看都不用看。很多站点的问题不是「没写」，而是写了之后长期没人回头看，规则随着改版、目录调整、运营策略变化逐渐失真，最后变成一份与实际站点结构对不上的历史文档。
下面这份清单适合在改版后、目录调整后、或者例行维护时跑一遍。它不复杂，但需要耐心逐条核对。
第一步：确认文件本身能正常取回
- 访问 https://域名/robots.txt，确认返回 200，而不是 404、403 或跳转到首页。
- 确认返回的内容类型是 text/plain，而不是 text/html。有些框架会把不存在的内容统一渲染成 HTML 页面，这时蜘蛛看到的是一堆标签，规则等于没写。
- 如果站点同时存在 www 与非 www、主域与子域，确认每个可访问的域名下都有对应文件，而不是只维护了一份。
- 确认 CDN 或页面缓存没有把旧版本的 robots.txt 长期缓存住，导致规则改动迟迟不生效。
这几项看起来基础，但在实际排查中，光是「文件取不回来」和「取回来的是 HTML」就占了相当比例的问题。
第二步：逐条核对 Disallow 规则
Disallow 的写法本身不难，难的是判断某条规则到底屏蔽了什么。建议把现有规则一条条抄出来，在测试工具里对照真实 URL 验证，而不是凭文件名猜测。
容易被误伤的几类目录
- 站内搜索结果页：通常是动态参数地址，屏蔽是合理的，但要确认规则没有把承载正文的页面一起卷进去。
- 标签页与聚合页：如果它们承担了栏目入口的作用，直接屏蔽可能切断新内容的发现路径。
- 静态资源目录：屏蔽 js、css、图片目录是常见做法，但要注意部分搜索蜘蛛需要读取这些资源才能还原页面样式与结构。
- 接口与临时目录：这类地址屏蔽没问题，但要确认前缀没有写得太宽，比如用 / 开头的一条规则覆盖了整站。
一个稳妥的做法是：屏蔽规则尽量写具体，能写到目录层级就不要用宽泛的前缀；每加一条规则，都想清楚它到底影响了哪些真实存在的 URL。
第三步：不要把 robots.txt 当成隐藏开关
Disallow 表达的是「请不要抓取」，并不等于「页面不会被收录」。如果该地址在站外还有其他链接指向，它仍然可能以无描述的形式出现在结果中。真正想让某个页面从索引里消失，应该配合 noindex，或者干脆让页面返回 410。
这个区别在草稿页、测试页、促销临时页上尤其重要。运营同学有时会习惯性地往 robots.txt 里加一条屏蔽就当作「下线处理」，结果页面依然存在，只是抓取被挡住了，问题被推迟而不是被解决。
第四步：确认与 Sitemap 声明一致
robots.txt 里通常会写一行 Sitemap 地址。检查两点：地址是否还能正常打开；声明的位置是否是当前实际维护的那份。如果站点有多个 Sitemap 索引文件，最好在 robots.txt 中只保留主索引，避免多份声明互相干扰。
同时留意规则之间的逻辑冲突：如果某个目录已经在 Disallow 列表里，又出现在 Sitemap 中，那这份 Sitemap 的参考价值就会被打折扣。两者要么统一放开，要么统一排除。
第五步：改完之后一定要验证
- 用搜索引擎官方提供的 robots.txt 测试工具，输入几个代表性 URL，确认放行与拦截结果符合预期。
- 改动后观察服务器日志，看目标目录的抓取频次是否出现预期变化，而不是只看工具提示。
- 给改动留出几天观察期，再决定是否需要微调，避免一天之内反复修改让抓取行为持续波动。
把 robots.txt 纳入改版检查清单，和跳转、状态码、Sitemap 放在同一级别对待。它不需要频繁调整，但每次调整都值得留一条记录：改了什么、为什么改、验证结果如何。这样下次出问题时，至少能快速定位到是哪一次改动带来的影响。