很多人在排查蜘蛛池为什么没动静时，先看链接、再看日志，最后才想起 robots.txt。实际上这是最靠前的一环：抓取程序访问一个域名时，通常会先请求根目录下的 robots.txt，再决定要不要继续往下走。这一步没走通，后面的入口页、链接和内容都无从谈起。

先确认 robots.txt 的作用范围

robots.txt 只对同一个主机生效。子域名、不同协议、不同端口都各算各的：http 和 https 可能被当作两个站点，带 www 和不带 www 也常被视为两个主机。批量部署蜘蛛池时，模板往往只写了一份文件，实际却有几十个访问入口，漏配的情况很常见。

另外，这个文件必须放在根目录。放在子目录里不会被读取，也不要用 302 把它跳到别处。

几种容易挡住蜘蛛的写法

整站 Disallow

Disallow: / 是最常见的一处遗留问题。测试阶段为了防止抓取加上这一行，上线后忘了删。此时蜘蛛仍会读取 robots.txt，但不会请求入口页，日志里自然什么也看不到。

User-agent 写错

规则组里的 User-agent 值需要和爬虫声明的名字对应。主流爬虫一般只认自己的名字和通配符 *，写成别的字样就匹配不上，那组规则会被整体忽略——如果那组里恰好是允许规则，等于白写。

通配符与 $ 的支持差异

* 和 $ 并非所有抓取程序都支持。Google、Bing 等支持，一些小众或自建抓取程序会按字面处理，可能出现放过本该屏蔽的路径、或误伤正常路径两种情况。当 Allow 与 Disallow 冲突时，Google 会取更长（更具体）的那条规则，不同爬虫的处理未必一致。

返回码比文件内容更关键

• 200：正常读取，按规则执行。
• 404：视为没有规则，默认允许抓取全部。临时删除文件时要意识到这一点。
• 403：多数搜索引擎会当作禁止抓取整个站点处理，影响范围比 Disallow: / 更大。
• 500 / 503：视为服务端不可用，短时间会重试；长期如此可能降低抓取频次甚至暂停。

如果 robots.txt 是程序动态输出的，务必确认它不会因为超时、鉴权或 WAF 拦截返回 403。

别漏掉页面级与响应头指令

robots.txt 允许抓取，不代表页面本身没有额外限制。入口页的 meta robots、以及响应头里的 X-Robots-Tag，都可能在抓取或后续处理环节起作用。X-Robots-Tag 对 PDF、图片这类非 HTML 资源同样有效，排查时很容易被忽略。

Crawl-delay 与实际抓取频次

Crawl-delay 只有部分爬虫支持，Google 明确不支持该指令。写了不一定生效，写了过大的数值还可能让本就有限的抓取变得更慢。真正影响抓取频次的是站点响应速度、错误率和内容更新情况，这一点在蜘蛛池场景里尤其明显：通路响应慢，放出去的 URL 再多也消化不了。

上线前的检查清单

1. 直接访问 /robots.txt，确认返回 200 且内容符合预期；http 与 https、带与不带 www 分别检查。
2. 搜索 Disallow 中是否出现 /，是否误伤了入口页所在目录。
3. 查看入口页的 meta robots 与响应头中的 X-Robots-Tag。
4. 确认 crawl-delay 的数值没有夸张到让抓取接近停滞。
5. 用抓取工具或更换 UA 请求一次入口页，确认返回正常，再到访问日志里看是否出现蜘蛛请求。

robots.txt 只能表达允许或不允许抓取，它不决定收录，也不保证蜘蛛一定会来。把它当成通路检查的一部分，而不是优化手段。

对批量投放来说，更实际的做法是把 robots.txt 检查放进上线流程，而不是出问题后再回头找。同一套模板复制到多个域名时，一个错误配置会被放大很多倍；定期抽查几个域名，比事后逐个排查省事得多。