做蜘蛛池和站点运营时，常遇到一種情况：入口頁本身没問题，目标 URL 也能正常訪問，但服務器响應很慢——首字节要好几秒才返回，或者偶尔直接超时。這时大家往往只盯着“蜘蛛来没来”，却忽略了另一個更實际的問题：蜘蛛到底有没有把這一頁讀完。
抓取單個 URL 是有時間预算的
搜尋爬虫訪問一個地址时，會给自己设一個等待上限。建立连接、握手、等待首字节、下载正文，都在這個预算之内。超過阈值，爬虫通常不會一直挂着死等，而是断開连接、把這次請求记成異常，轉去做別的任務。所以“抓取失敗”不一定表現為 5xx，很多情况下日誌里只留下一次不完整的請求或一條超时记錄。
同样是慢，结果並不一样
- 连接阶段就超时：頁面根本没被讀到，里面的連結自然無從發現。
- 首字节很慢但最终返回 200：爬虫可能仍拿到完整 HTML，但這次的响應耗时會被记錄下来，影响之後對该站点的抓取节奏。
- 正文传到一半断開：拿到的是被截断的 HTML，後半部分内容根本没到本地。
- 时快时慢：最麻烦的一種，抓取成功率不稳定，排查时也很难复現。
只抓到半截 HTML，連結會被漏掉吗
會。爬虫解析連結依赖的是已经下载到的那部分 HTML。如果响應在文档前半段就断了，位于後半部分的連結很可能不在這一轮的解析范围内。這也是為什么有些入口頁明明寫了目标 URL，日誌里却始终没有對目标地址的抓取记錄——不是連結寫错了，而是那一頁根本没被讀完整。
把連結放在前面，能降低這種風險
在頁面结构上把關键連結尽量靠前，不要依赖後面的脚本渲染或异步加载，能在响應被截断时提高被發現的机會。這不是萬能方案，但比全塞在頁尾要稳一些。
入口頁慢和目标 URL 慢，要分開看
入口頁慢，影响的是“連結能不能被發現”；目标 URL 慢，影响的是“發現之後能不能被抓到”。两者的表現都是日誌稀疏，但方向完全不同。排查时先確認是哪一端的問题，否則容易在错誤的方向上反复折腾。
可以按這几步排查
- 看服務器訪問日誌里，是否存在大量耗时異常或未完成的請求记錄。
- 检查頁面是否体积過大，或在前部塞了太多阻塞脚本、同步接口調用。
- 检查後端是否存在慢查询、外部资源拖慢首字节返回。
- 確認 CDN 與回源是否正常，回源異常會明顯放大延迟。
- 從不同網絡位置多测几次，区分偶發抖動和長期常態。
優化方向
- 優先保證首字节速度，能静態化就静態化，减少動態拼装。
- 把需要被發現的連結放在 HTML 靠前的位置，减少對前端渲染的依赖。
- 给服務端設定合理的超时和降級策略，避免請求長時間挂起。
- 控制單頁連結數量和頁面体积，別让一頁承担過多内容。
- 調整後持續观察一段時間，不要指望改一次就立刻恢复。
慢响應不只是訪問体驗問题，它會實打實决定爬虫能把頁面讀到什么程度。没被抓到的内容，對搜尋而言约等于不存在。
總的来说，入口頁响應慢或频繁超时，通常不會直接導致“蜘蛛從此不来”，但很容易造成“蜘蛛没讀全”，從而漏掉頁面里的目标 URL。把首字节速度和稳定性做扎實，往往比反复提交 URL 更有效。至于最终是否被收錄，還取决于内容本身和其他多種因素，本文只讨论抓取這一环。