做站点运营的人常遇到一種情况：内容更新了，連結也铺出去了，日誌里却始终看不到搜尋蜘蛛的抓取记錄。排查到最後往往發現，蜘蛛不是没来，而是被 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 做一次可達性抽查，用模拟抓取的方式確認返回的是内容而不是挑战頁。
抓取問题的排查顺序其實很固定：先確認蜘蛛有没有来，再確認来的时候拿到了什么，最後才去改配置。把邊缘日誌、狀態碼、来源驗證這三样放在一起看，大部分“蜘蛛不抓”的問题都能定位到一個具体环节，而不是笼统地归因于内容质量。