很多人在看抓取日誌时，只關注狀態碼是 200 還是 404，却忽略了一種中間狀態：請求已经進来了，但响應還没發完就断了。搜尋蜘蛛對單個 URL 的抓取是有時間限制的，入口頁一旦响應太慢，這次抓取就可能被记成失敗或只完成一半，里面的連結自然也未必會被繼續解析。
搜尋蜘蛛的等待是有限的
搜尋引擎不會無限制地等一個頁面返回。抓取器通常设有连接超时和讀取超时，超過阈值就主動断開连接，把這次抓取记為異常。不同引擎、不同抓取優先級下的阈值並不相同，官方也不會公開具体秒數，所以不要按某個固定數字去卡，而應该關注自己的响應時間是否稳定、是否有長尾的慢請求。
入口頁變慢的常见原因
- 源站動態逻辑重：入口頁每次抓取都要查库、調接口或做模板渲染，没有缓存兜底。
- 带宽與並發被占满：入口頁和主站共用出口，正常用戶流量高峰时抓取請求排在後面。
- CDN 回源慢：邊缘节点等待源站响應，回源鏈路抖動會直接体現為抓取超时。
- WAF 或安全组件挑战：對首次請求下發 JS 校驗或跳轉驗證頁，抓取器不會执行這些脚本。
- DNS 與 TLS 阶段耗时：多线路解析到不可用节点，或證书鏈不完整，连接建立阶段就已消耗大量時間。
從日誌判断“超时”而不是“被拒”
- 請求记錄存在，但响應字节數為 0 或明顯小于正常頁面。
- 狀態碼出現 499、504 一類由服務端或網關侧中断产生的记錄。
- robots.txt、sitemap 這類小文件抓取正常，只有大体积或動態入口頁異常。
- 同一路径的抓取間隔被拉長，且每次记錄都不完整，像是反复尝试又反复失敗。
被拒通常是明确的 403、429，而超时更像是“抓了但没抓完”。两者在處理思路上完全不同：前者要查規則和限流，後者要查性能和鏈路。
一套可落地的排查顺序
- 先放一個纯静態、体积很小的測試入口頁，观察是否稳定被抓取。如果它也超时，問题多半在網絡或網關层。
- 逐步加回模板、查询和接口，找出让响應時間抬升的那一段。
- 從不同地区、不同运营商去解析和訪問入口頁，對比首字节時間，排除單点线路問题。
- 查看 CDN 和 WAF 日誌，確認触發挑战、回源失敗或回源超时的占比。
- 最後回到服務端，看慢查询日誌、连接數、並發限制和工作進程是否被打满。
優化方向
- 入口頁尽量静態化或加短时缓存，避免每次抓取都走完整動態逻辑。
- 控制單頁响應体积，把非必要的图片、字体等资源移出關键路径，先輸出 HTML。
- 检查是否對抓取来源單獨做了限速或驗證，誤伤會表現為持續超时。
- 修复後观察抓取是否恢复。若恢复，說明此前是速度問题而不是内容問题。
不要指望靠“熬過搜尋引擎的耐心”来解决問题。慢响應會被记錄，抓取预算也是有限的，長期超时會让入口頁在抓取队列里被降權處理。
抓取速度不是孤立的性能指标，它决定的是同一個抓取窗口内能走完多少 URL。與其纠结某一次抓取為什么失敗，不如把入口頁的响應時間稳定在可控范围内，再看日誌里的抓取條數和覆盖路径有没有變化。