robots.txt 是站点与搜索引擎蜘蛛之间的第一道沟通文件。它不复杂，但正因为简单，很多站点在上线、改版、迁移时随手改一行，就可能让蜘蛛停止抓取整站或某个栏目。等到发现新内容迟迟不被发现，才回头检查，往往已经过去几周。
这篇文章不谈玄学，只围绕一个目标：把 robots.txt 的常见误配找出来，并给出可重复执行的检查流程。需要先明确一点，robots.txt 是抓取指令，不是访问控制。它不能保护隐私，也不能阻止恶意抓取，敏感目录应该用登录权限或服务器规则来隔离。
为什么 robots.txt 容易出错
它有几个特点：文件小、改动快、影响面大、生效不直观。很多 CMS 或框架会默认生成一份 robots.txt，运营人员可能从未完整看过；测试站和生产站共用模板时，也容易把测试环境的禁止规则带到线上。
更麻烦的是，不同搜索引擎对通配符、Allow 规则、Crawl-delay 的支持程度并不完全一致。你以为只挡住了一个参数页，实际可能连栏目列表一起挡了。
常见误配清单
- Disallow: /：最严重的一行。它表示禁止抓取整站。常见于测试站复制到生产，或临时关闭抓取后忘记删除。
- 路径写错大小写：robots.txt 中的路径通常区分大小写。你写 /News/，实际目录是 /news/，规则可能不生效或误伤。
- 通配符误伤：Disallow: /*? 想挡参数页，却可能把带查询参数的正常分页、筛选页一并挡掉。
- 挡住 CSS、JS、图片：如果禁止抓取静态资源，蜘蛛渲染页面时可能看不到完整内容，影响对页面质量的判断。
- Allow 与 Disallow 冲突：多数搜索引擎采用最长匹配优先，而不是简单按顺序。规则越多，越难靠肉眼判断。
- Sitemap 地址写错：协议、域名、路径任一错误，都会让声明失效。Sitemap 应使用完整绝对地址。
- Crawl-delay 设置过大：部分蜘蛛不支持该指令；即使支持，过大的延迟也会减少单位时间内的抓取量。
- 多份 robots.txt 并存：例如根目录一份、子目录一份，容易互相矛盾。蜘蛛通常只读取根目录的那一份。
可执行的自查步骤
- 直接访问文件：在浏览器打开 https://你的域名/robots.txt，确认返回 200，内容是最新版本。注意不要被 CDN 或缓存返回旧文件。
- 检查 User-agent 分组：确认针对 * 和主要搜索引擎蜘蛛的规则是否符合预期。不要留下空分组或拼错的 User-agent。
- 逐条读 Disallow 与 Allow：对每条规则，问一句“这条会挡住我想让蜘蛛抓的 URL 吗”。尤其注意根路径、栏目路径和参数通配符。
- 用官方测试工具模拟：主流搜索引擎都提供 robots.txt 测试工具。输入具体 URL，看结果是允许还是禁止。不要只凭肉眼判断。
- 核对 Sitemap 声明：确认地址可访问、内容有效，并且与站点地图文件实际位置一致。
- 结合服务器日志验证：改动后观察蜘蛛对目标目录的访问量。如果关键目录的抓取请求明显减少，需要复查规则。
- 纳入上线检查清单：每次改版、迁移、新增子站时，把 robots.txt 列为必查项，避免模板差异导致误封。
和 URL 发现、蜘蛛池的关系
蜘蛛池、外链引导、Sitemap 提交等做的是“让蜘蛛知道 URL 存在”，而 robots.txt 决定“蜘蛛能不能抓”。如果 robots.txt 把目标目录挡住，前面做的 URL 发现工作就会卡在门口：蜘蛛可能知道地址，但不会抓取内容，新页面自然难以进入后续流程。
因此，在做 URL 发现和抓取引导之前，先确认 robots.txt 没有误封，是更省力的顺序。否则你可能会把问题误判为“蜘蛛不来”，实际是“来了但被挡”。
把 robots.txt 当成一份需要定期审查的配置文件，而不是一次性写完就忘的装饰文件。
总结
robots.txt 的自查不需要高深技术，但需要耐心和固定流程。重点检查全站禁止、路径大小写、通配符误伤、静态资源被挡、Sitemap 声明和多份文件冲突。每次改动后，用官方工具模拟关键 URL，再结合日志观察抓取变化。这样可以在问题扩大前发现并修正，让蜘蛛的来访真正落到有价值的页面上。