蜘蛛没来，还是没被放进来

不少站点排查抓取问题时，第一反应是翻服务器日志，看有没有蜘蛛的访问记录。如果没有，就默认蜘蛛没来过，接着去改内链、改 Sitemap、加外链。但更常见的情况是：请求确实发出过，只是被站点前面的 CDN、WAF 或自建限流层挡掉了，源站日志里干干净净，什么也看不到。

这类问题会直接影响 URL 发现效率——已经存在的链接可能长期不进待抓队列，新 URL 的曝光速度也会明显变慢。麻烦的地方在于，它在源站一侧几乎无法自我暴露，需要主动去验证。

三类高频误伤

1. 按 User-Agent 做关键词拦截

有些防护规则会拦掉 UA 里带 bot、spider、crawler 的请求，或者只放行少数几个自己写进去的 UA。蜘蛛的 UA 较长且带版本信息，很容易被当成自动化工具误伤。反过来，只靠 UA 放行也不够安全，因为 UA 可以伪造，但这属于另一个问题，先解决误伤。

2. 频率限制与验证挑战

限流规则通常按 IP 或 UA 统计单位时间内的请求数。蜘蛛抓取时会在短时间内集中请求同一批 URL，很容易触发阈值，随后收到 429、403，或者被塞进一个 JS 验证页面。它拿不到真实 HTML，抓取路径就在这里断了。JS 挑战尤其麻烦，因为返回的往往是 200，从状态码上很难看出问题。

3. IP 段与地区封禁

为了挡掉恶意流量，部分站点会整段封禁某些云服务商或海外 IP 段。蜘蛛的出口 IP 恰好落在这些网段里时，就会连门都进不来。这类封禁常写在 CDN 或防火墙的最外层，源站再怎么调整也绕不过去。

怎么确认是不是被挡了

先做交叉验证，不要只看单一来源：

• 看 CDN 或 WAF 侧的回源日志与拦截统计，而不是只看源站访问日志。拦截记录里通常能看到被拒的 UA 和状态码。
• 把搜索平台提供的抓取统计与源站日志对照。如果平台显示大量超时、连接失败，而源站没有对应记录，基本可以定位到中间层。
• 核对蜘蛛 IP 真实性时，用反向 DNS 解析到官方域名，再正向解析回原 IP。不要只依赖一份静态 IP 清单，清单更新不及时会误判。

可以直接落地的几条原则

1. 把已验证的蜘蛛来源做成白名单，放在限流和验证规则之前，优先级高于通用风控。
2. 对 HTML 与静态资源分开限流。图片、CSS 这类请求量大的资源不设过严阈值，否则页面渲染和抓取都会被拖住。
3. 限流触发时优先返回 429 并给出合理的重试提示，避免用 200 的验证页伪装成功。
4. 定期复查封禁列表，尤其是地区级和网段级规则，改版或迁移后要重新确认一遍。
5. 把抓取相关的拦截事件纳入日常监控，出现突增时先排查配置变动，而不是急着改内容。

几句提醒

防护和抓取并不是对立面。多数误伤来自默认规则和长期未复查的例外项，而不是有意的封禁。把放行条件写清楚，比事后反复猜为什么没抓有效得多。

另外要接受一个前提：把蜘蛛放进来，只代表它有机会看到你的页面，不代表一定会抓、一定会收录。抓取只是流程里的一环，能做的部分是减少无谓的阻断，让 URL 被发现、被访问的路径保持通畅。