很多人盯着收錄數找原因，最後發現問题不在頁面本身，而在服務器给蜘蛛的那几百毫秒里。抓取是一個有预算、有超时、有並發上限的動作，頁面响應慢，蜘蛛能带走的頁面就少，能進入索引的頁面自然也會少。

蜘蛛抓一個頁面的時間帳

蜘蛛訪問一個 URL，大致要经歷：建立连接、等待首字节（TTFB）、下载响應体、再决定要不要抓頁面里的其他资源。其中對抓取效率影响最大的通常是连接和 TTFB 這两項。TTFB 從 200ms 涨到 1.5s，單次抓取占用的時間可能多出好几倍，而蜘蛛在同一個站点上的並發數和總时長都是有限的。

结果就是：同样的抓取配額，能覆盖的 URL 數量變少。表現往往是重要頁面更新後迟迟不重抓，新頁面要排很久的队才被第一次發現。

多慢算慢：几個可以參考的刻度

• TTFB 稳定在 500ms 以内：通常不會成為抓取瓶颈。
• TTFB 長期在 1s 以上：抓取量容易被压住，頁面量大的站点更明顯。
• 單頁完整响應经常超過 5 到 10 秒：容易踩到蜘蛛的超时阈值，這次抓取基本白跑。
• 大量請求超时或返回 5xx：除了浪費額度，還可能让蜘蛛主動降低對這個站点的抓取频率。

這些只是经驗刻度，不是标准答案。真正的判断依據，應该是你自己日誌里的响應時間分布和抓取频次變化。

超时和 5xx 會被怎么记帳

超时不等于 404。404 是明确的“這個地址没有内容”，蜘蛛一般會把這條记錄划掉；超时和 5xx 是“這次没拿到，下次再看”，蜘蛛會保留這個 URL 並稍後重试。区別在于，重试同样要消耗抓取額度。

不同狀態碼的差別

• 503 加 Retry-After：用于計划内维護，明确告诉蜘蛛什么时候再来，相對友好。
• 500 / 502 / 504：通常是故障信号。持續大量出現时，蜘蛛會判断站点不稳定並放缓抓取。
• 429：明确的限流响應，蜘蛛一般會退让，但返回 429 的頁面本身也没有真正被抓到。

如果站点确實承受不住抓取压力，用 robots.txt 的 crawl-delay，或在服務端按 UA 限速，都比让請求一個個超时要可控得多。

先排查什么

• 資料库慢查询：列表頁、詳情頁、搜尋结果頁的查询耗时分開統計，不要只看平均值。
• 外部依赖：接口調用、CDN 回源、第三方脚本阻塞了首字节輸出。
• 缓存命中率：缓存穿透或频繁失效，會让每個請求都回到源头重新計算。
• 抓取高峰是否撞上业務高峰，日誌里的耗时是否同步變長。
• 是否有頁面在抓取时触發大量關联查询，比如一次拉取几百條推荐内容。

從日誌里怎么確認

把蜘蛛訪問日誌按狀態碼分组，統計一段時間的分布：2xx、3xx、4xx、5xx 各占多少，平均响應時間和 P95 响應時間分別是多少，然後對比同期抓取频次的變化。如果 5xx 或超时比例上升的同时抓取频次下降，基本可以確認是稳定性拖累了抓取。

抓取量下降不一定就是服務器慢，也可能是站内 URL 膨胀、參數泛滥或内鏈结构變化。但服務器指标是最容易量化的一個，值得先排除掉。

別把收錄數当成唯一指标

响應速度改善後，抓取频次往往先回升，收錄數随後才有變化，中間還隔着頁面质量判断和重复内容篩選。把服務器指标、抓取日誌、索引覆盖率放在一起看，比盯着一個數字反复猜要靠谱得多。