排查蜘蛛池效果时，很多人只看入口頁返回的 HTTP 狀態碼是不是 200，却忽略了一個更基础的變量：响應時間。搜尋蜘蛛在一次抓取里愿意等待的時間是有限的，入口頁長期很慢，抓取节奏、抓取量、日誌里出現的频次都會跟着變，而這些變化很容易被誤判成“蜘蛛池没效果”。
搜尋蜘蛛能等多久
各家搜尋引擎的超时阈值没有完全公開，但實际观察下来大致是几秒量級：如果服務器在這個窗口内没有把首字节吐出来，爬虫很可能直接断開，把這次訪問记成超时而不是成功。典型表現為：
- 日誌里出現狀態碼 0、499，或者干脆没有记錄到完成行；
- 同一個 URL 反复被抓，但每次都很快結束；
- 抓取間隔被拉長，原本每天都来的，變成几天一次。
要注意，超时和返回 5xx 不是一回事。5xx 一般會被当作服務器错誤，搜尋蜘蛛可能降低整個站点的抓取频率；超时更多影响單個 URL 的抓取成功率，但如果入口頁大面积超时，结果差別不大。
响應慢會连带影响什么
抓取预算不是無限资源，搜尋引擎會在“抓多少、抓多深、隔多久再来”之間做取舍。入口頁慢，通常會带来连鎖反應：
- 單次抓取拿到的 URL 變少：爬虫把時間耗在等待上，一轮抓取能走的路就少了；
- 目标 URL 的發現被推迟：入口頁都没抓完，里面的連結自然排到後面；
- 重试更频繁：失敗一次可能触發重试，反而占用更多配額；
- 日誌看起来“蜘蛛變少了”：不是不来，而是每次来了都待不久。
先分清是入口頁慢還是目标頁慢
很多人一到這一步就急着改服務器，其實應该先做区分。可以用 curl 分段計时，或者看日誌里的請求耗时字段，把 TTFB（首字节時間）和整体下载時間拆開：
- TTFB 高、下载很快：問题多在服務端處理，比如資料库查询、動態渲染、後端接口；
- TTFB 正常、下载慢：多半是頁面体积太大，或者外鏈资源太多；
- 两者都正常但爬虫還是断：可能是網絡鏈路、CDN 回源或 WAF 拦截導致的。
可以做的几件具体事
- 把入口頁尽量做成静態或半静態，减少每次請求都要查询資料库的動作。
- 检查是否有阻塞渲染的外部资源，比如統計脚本、字体、第三方接口，能异步就异步。
- 控制單頁連結數量，連結太多會让爬虫處理每個响應的時間被摊薄。
- 確認服務器没有對爬虫單獨限速，或者限速阈值设得太低。
- 改完之後不要立刻下结论，至少观察一到两周日誌里的抓取频次和成功比例。
提醒：不要靠频繁換 IP、伪造 UA 或者堆大量入口頁去“催”抓取。這些做法既不能提高响應速度，也容易让整個站点被判定為異常。
日誌里重点看這几項
- 請求耗时分布：是中位數整体偏慢，還是少數請求拖尾；
- 超时或失敗請求，占该入口頁總抓取次數的比例；
- 同一入口頁两次抓取之間的間隔變化；
- 目标 URL 首次被訪問的時間，和入口頁被抓時間相差多少。
入口頁响應速度不會直接决定收錄结果，但它决定了搜尋蜘蛛愿不愿意多来、能走多深。把响應時間压到合理区間，是蜘蛛池能不能稳定运轉的前提之一。