很多人把“發現 URL”和“抓取 URL”当成同一件事。實际流程是两段：搜尋蜘蛛先請求並解析入口頁的 HTML，把里面的連結记下来，再排進抓取队列逐個訪問。响應慢主要卡在第二段，但只要慢到一定程度，第一段也會受影响——蜘蛛可能没等到完整的 HTML 就断開连接，後面的連結自然不會出現在它的待抓列表里。
响應慢，具体慢在哪一环
- 连接建立慢：DNS 解析、TCP 握手、TLS 协商耗时偏高；
- 首字节時間（TTFB）高：服務端要等接口、查库、拉遠程資料才吐出 HTML；
- 传輸慢：頁面体积大、没開压缩、图片和脚本挤占带宽；
- 頁面结构問题：連結要等 JS 执行後才出現在 DOM 里；
- 服務端不稳定：频繁超时、502/503/504，或者重定向鏈太長。
蜘蛛有超时設定，超過阈值就會中断本次請求。此时已下载的那部分 HTML 可能被解析，也可能直接丢弃。無论哪種情况，截断位置之後的連結都等于没被看到，入口頁作為“連結出口”的作用就打了折扣。
發現解决的是“知道有這條 URL”，抓取解决的是“真正去訪問它”。入口頁的第一职责是把連結稳定地送出去，這一步做不好，後面所有环节都無從谈起。
慢到什么程度才會明顯影响發現
- TTFB 在几百毫秒内：基本無感，属于正常波動；
- TTFB 到几秒：蜘蛛仍可能抓到，但同域名抓取频次會下降，連結進入队列的時間被拉長；
- 经常超时或返回 5xx：蜘蛛會主動降低回訪频率，入口頁上新增的目标 URL 被發現的机會随之减少；
- 長期打不開：整個目錄在蜘蛛眼里的優先級都會被調低，恢复後也需要時間回暖。
還有一個容易被忽略的点：蜘蛛對同一個域名有並發和配額限制。入口頁慢，會長時間占住连接，等于挤占了同站点其它頁面的抓取机會，影响並不只局限在入口頁本身。
用日誌做一次自查
- 統計入口頁的响應時間分布，看 P90、P99 是否已经超過一秒；
- 筛出蜘蛛訪問记錄中的超时、5xx、被中断的請求比例；
- 對比蜘蛛回訪入口頁的频次曲线，看是否在某個時間点明顯下滑；
- 確認目标 URL 是否压根没出現在訪問日誌里——如果连一次請求都没有，問题多半出在連結没被解析出来，而不是抓取太慢。
入口頁提速的可操作項
- 尽量静態化，减少同步調用外部接口和复杂查询；
- 開啟 gzip 或 brotli，压缩 HTML 体积；
- 把目标連結直接寫在 HTML 源碼里，不要依赖 JS 渲染或异步加载；
- 控制單頁連結數量，避免把大量連結堆在同一頁；
- 确保正常返回 200，减少重定向层級，避免 5xx；
- 有條件时用缓存或 CDN，让蜘蛛每次拿到的响應都稳定一致。
几個常见誤区
有人以為入口頁响應變快，蜘蛛就會立刻發現目标 URL，這不成立——速度只影响被發現和被訪問的概率，不决定時間点。也有人只盯着服務器指标，忽略了頁面本身的结构問题：如果連結藏在 JS 里，服務器再快，蜘蛛也可能看不到。另外，用 robots.txt 把入口頁整体禁掉，虽然能省服務器资源，但也等于直接放弃了連結被發現的通道，這属于另一類問题，需要單獨權衡。
把入口頁当成一個稳定的連結出口来维護：响應稳定、返回碼正常、連結在 HTML 里可见，剩下的交给蜘蛛自己的节奏。任何声称能保證發現時間或收錄结果的说法都不靠谱。