入口頁里寫出了目标連結，不等于搜尋蜘蛛一定讀得到。中間還隔着一次 HTTP 請求是否顺利完成：如果請求在搜尋蜘蛛的超时阈值内没有拿到完整响應，它很可能直接放弃這次抓取，頁面里寫了多少條目标 URL 都無從谈起。
超时發生时，搜尋蜘蛛實际经歷了什么
一次抓取大致经過几個步骤：解析域名、建立连接（含 TLS 握手）、發送請求、等待响應头、下载响應体、解析 HTML 並提取連結。任何一個环节超时，後面的步骤都不會执行。
- 连接阶段超时：DNS 解析慢、服務器不回 SYN、TLS 握手拖太久，抓取器會直接断開。
- 响應头超时：服務端迟迟不返回首字节，抓取器等不到就開始放弃。
- 下载中途超时或中断：响應体過大、传輸速度過低，HTML 没下完就被切断，能解析到的連結可能只有前半部分。
無论哪種情况，结果都一样：這次抓取没有产出連結，目标 URL 也就没有被發現。
偶尔超时和長期慢响應，影响完全不同
單次超时通常會被记錄為抓取错誤，搜尋蜘蛛之後可能重新安排抓取，但重试的間隔並不公開、也不固定。真正麻烦的是長期稳定地慢：
- 抓取失敗率上升，入口頁數量越多，這個比例带来的绝對值越大；
- 抓取预算會向响應更稳定的站点倾斜，本站被訪問的频率可能下降；
- 入口頁中位置靠後的連結，更容易因為传輸被截断而漏讀。
也就是说，超时對蜘蛛池的影响不是“少抓了一個頁面”，而是整体發現效率被拉低。
怎么判断入口頁是不是慢在了超时线上
可以先用命令行看首字节時間：curl -o /dev/null -s -w "%{time_starttransfer}\n" 入口頁地址，连續跑几次取中位數，別只看單次结果。再看服務器日誌中搜尋蜘蛛 UA 的响應耗时分布，而不是只看平均值。
常见的拖慢原因包括：
- 入口頁每次請求都查資料库或調接口實时拼接連結；
- 没有開啟压缩，HTML 体积偏大；
- CDN 回源慢或缓存命中率低，請求大量打回源站；
- 同一台机器上站点過多，连接排队；
- TLS 配置老舊，握手往返次數偏多。
把入口頁做得快而稳的几個動作
- 静態化：入口頁生成静態 HTML 落盘或交给 CDN，連結列表定期更新，不要每次動態组装。
- 控制体积：入口頁只放連結和少量說明，把目标 URL 尽量放在 HTML 前部，降低被截断时漏讀的概率。
- 限制單頁連結數量：一頁塞几千條連結既拖慢頁面，也分散抓取预算，分批、分頁更實际。
- 监控 TTFB：把入口頁响應時間纳入日常监控，一旦持續升高就優先排查，而不是等發現量掉了才回头看。
抓取超时不是“這次没抓到”這么简單，它會让搜尋蜘蛛對整站形成“慢”的印象，而蜘蛛池恰恰依赖大量入口頁被反复訪問。
需要說明的是，把入口頁調快只能提高被正常抓取、進而解析出連結的概率，並不能保證目标 URL 一定會被抓取或收錄。搜尋蜘蛛是否跟進、多久跟進，還受連結所在位置、站点整体质量等因素影响，任何工具都無法承诺结果。