很多站点做蜘蛛池时，注意力都放在“怎么让搜索蜘蛛发现目标 URL”，却忽略了另一面：入口页可能根本没让搜索蜘蛛进来。抓取日志一片空白，有人以为是自己入口页质量太差，实际上是被自己的 robots.txt、防火墙或频率限制拦在了门外。
一、先分清是“被拦住”还是“没来过”
这两种情况的处理方向完全不同。日志里完全没有搜索蜘蛛的请求，可能是它压根没发现入口页，也可能是请求在到达应用之前就被挡掉了。比较稳妥的做法是同时看三个地方：Web 服务器的访问日志、CDN 或 WAF 的拦截日志，以及服务器出口的网络层记录。如果 WAF 日志里有大量来自搜索引擎 IP 段的 403、405 或 406，那基本可以判断是拦截问题，而不是内容问题。
反过来，如果连 WAF 日志里都没有对应记录，说明请求连边缘节点都没到，就要往域名解析、入口页是否被搜索蜘蛛发现这些方向去查。
二、robots.txt 是最常见的“自我阻断”
robots.txt 一行写错，整站都可能被拒绝抓取，而很多人只在改版时顺手写了一次，之后再没看过。
几种典型写法
- Disallow: / 写在入口页所在目录或整站上，等于告诉搜索蜘蛛全都别来。
- 把测试环境的 robots.txt 直接同步到线上，而测试环境里往往写了全站禁止。
- 只对部分蜘蛛写规则，结果把真正想放行的那个也排除了。
- 返回 404 一般会被视为允许抓取，但持续返回 500 会让部分蜘蛛降低抓取意愿。
robots.txt 是约定不是命令。遵守它的蜘蛛会离开，不遵守的照样抓；所以指望用它挡垃圾流量，往往先误伤的是正常抓取。
三、防火墙和 WAF：只看 UA 的规则最危险
不少防护规则的做法是“UA 里没有常见浏览器标识就拦”，或者“空 UA 直接拉黑”。而搜索蜘蛛的 UA 往往不含浏览器特征串，正好命中规则。更麻烦的是，有些蜘蛛首次访问时 UA 会比较简单，后续才带上完整标识。
相对稳妥一些的判断方式是反向解析 IP 归属：确认来源 IP 的 PTR 记录属于对应搜索引擎，再做正向解析核对。只看 UA，几乎等于把判断权交给任何会改 UA 的人。
还要注意这几类规则
- 直接拉黑整个数据中心 IP 段，而部分抓取节点就在云机房里。
- 地区限制：入口页只对某些国家或地区开放，抓取节点不在范围内就被挡。
- 强制 HTTPS 跳转或强制 Cookie、JS 验证，蜘蛛拿不到跳转后的内容。
四、频率限制把搜索蜘蛛当成攻击流量
入口页的目标本来就是让蜘蛛多看几个 URL，所以它的请求频率天然比普通访客高。如果按“单 IP 每分钟请求数”做硬限速，很容易在蜘蛛刚进入抓取状态时就把它限掉。
可以留意的几点：
- 限速阈值按 IP 段 而不是单 IP 设置，搜索抓取往往来自同一段内的多个 IP。
- 被限速时返回 429 比直接返回 403 更友好，至少明确告知是频率问题。
- 在服务器压力允许的前提下，对已校验过的搜索引擎 IP 段适当放宽限速。
- 入口页大多是小文件、静态页，做好缓存即可，不必动用过于复杂的动态防护。
五、一套简单的自查顺序
- 直接访问入口页，确认能正常返回 200，且内容不是验证页或跳转页。
- 查看 robots.txt 是否可正常访问、是否有针对入口页的 Disallow。
- 翻 WAF、CDN 日志，按状态码筛 403、405、429，看拦截是否集中在搜索引擎 IP 段。
- 临时对已校验的 IP 段放宽规则，观察访问日志里是否出现蜘蛛请求。
- 把日志中的 UA 与真实 IP 反查结果交叉验证，确认来访的确实是搜索蜘蛛。
六、别把“屏蔽”当成常规手段
用拦截来解决抓取问题，本质上是先把入口堵上，再抱怨没人来。入口页该做的是保持稳定可访问、结构清晰、更新有节奏，而不是靠一堆隐蔽规则去筛选来访者。如果确实需要防刷，建议把规则做细：按行为特征判断，而不是按 UA 或整段 IP 一刀切。
最后提醒一句：拦截策略和抓取策略最好由同一拨人一起讨论，否则很容易出现“运营改了链接、运维加了规则”这种互相抵消的情况，排查起来也更费时间。