做站点运营的人常遇到一种情况：内容更新了，链接也铺出去了，日志里却始终看不到搜索蜘蛛的抓取记录。排查到最后往往发现，蜘蛛不是没来，而是被 CDN、WAF 或者频控规则挡在了外面，拿到的是一张验证页或者一个 403。
先分清是“没来”还是“来了被挡”
这两种情况的处理方向完全不同，动手之前先确认。
- 日志里能看到搜索蜘蛛的 UA，但请求状态集中在 403、429、503，说明来了被挡，问题在边缘配置。
- 连请求记录都没有，说明蜘蛛还没发现这个地址，问题在入口链接、提交渠道或者抓取路径。
- 注意看 CDN 边缘节点的日志。很多防护动作发生在边缘，源站日志里可能只剩 CDN 回源的那几条，看起来像蜘蛛没来。
UA 是最不可靠的身份凭证
把 UA 当作白名单唯一的判断依据，会有两个方向的麻烦。
一是太松：UA 可以随便伪造，不少采集程序直接照抄搜索引擎的 UA 字符串，等于给所有来客都开了门。
二是太紧：有些防护规则看到某个 UA 请求频率偏高就拦，正常抓取也被误伤。
更稳妥的做法是组合判断：先比对官方公布的 IP 段，再对来源 IP 做反向 DNS 验证，确认解析结果和来源域名一致，两个条件都满足再放行。这套验证方式主流搜索引擎都有官方说明，配置时照着文档来。
几种常见的误伤配置
- 全站人机验证或 JS 挑战。蜘蛛不执行点击和滑块，拿到的就是挑战页，等于内容对外不可见。
- 频控阈值按普通访客设定。蜘蛛在抓取高峰期的并发会明显高于普通用户，阈值太低就会被 429。
- 按地域封禁。搜索引擎的抓取节点分布很广，封禁区域很可能正好覆盖到它们。
- 要求携带 Cookie 或登录态才返回正文。蜘蛛通常不带会话，返回的就是空壳或者是跳转页。
- 自定义规则里把带参数的 URL 一并拦下。分页、筛选这类地址被拦，等于把抓取路径切断了。
放行的正确顺序
- 先保留一份原始日志，确认被拦的是哪些路径、返回了哪些状态码，不要凭感觉改规则。
- 对照官方 IP 段文档配置白名单，并记录下核对日期。
- 对验证通过的来源跳过挑战页和频控，而不是把整套规则关掉。
- 给抓取请求单独一条速率通道，不要和普通用户共用同一套限速策略。
- 规则调整后回看日志，确认抓取请求数量确实回升，而不是只看配置界面显示成功。
状态码怎么给才对
被限速时返回 429 并带上 Retry-After，比直接甩一个 403 或者干脆断开连接要友好得多，蜘蛛能据此调整节奏。临时故障用 503 加 Retry-After，不要用 200 返回一个错误页，那会变成软 404，反而让蜘蛛以为这条路走通了。另外尽量不要让 5xx 持续太久，长时间不稳定的站点，抓取频率会被主动压低。
白名单要跟着官方文档定期更新，配一次就不管，等于把旧名单当成了永久通行证。
蜘蛛池和多站点运营时要注意的点
- 入口页不要也放在验证后面。蜘蛛连门都进不去，后面的路径铺得再细也没意义。
- 多域名共用一套 CDN 配置时，白名单要覆盖全部域名，别只测了主站。
- 站点数量增加后回头检查限速阈值是否还合适，站点多了并发自然变高。
- 定期对入口 URL 做一次可达性抽查，用模拟抓取的方式确认返回的是内容而不是挑战页。
抓取问题的排查顺序其实很固定：先确认蜘蛛有没有来，再确认来的时候拿到了什么，最后才去改配置。把边缘日志、状态码、来源验证这三样放在一起看，大部分“蜘蛛不抓”的问题都能定位到一个具体环节，而不是笼统地归因于内容质量。