聊 URL 發現时，大多數讨论集中在連結、站点地图和内鏈结构上。這些确實决定了地址能不能進入队列，但發現只是第一步。連結被记下来之後，還要真正發請求、等响應、讀内容、解析出新的連結，這一整條鏈路能不能走完，很大程度上取决于服務器回答得有多快。
發現和抓取是两件事
發現解决的是“這個地址存在”，抓取解决的是“這個地址的内容我拿到了”。前者靠連結和入口，後者靠一次完整的 HTTP 往返。响應時間越長，單位時間内能完成的抓取次數就越少，队列里排在後面的地址等待的時間也越長。
可以把它想成一條传送带：入口頁负责往上传地址，服務器负责把内容送回来。传送带本身不慢，但每次送件都要等很久，整体吞吐就下来了。新發布的頁面、层級較深的頁面，往往是這種延迟最先波及的對象。
响應變慢时會發生什么
- 單次抓取耗时被拉長，同样一段時間能覆盖的 URL 數量變少，部分地址的抓取被推到更晚。
- 超时概率上升。請求中断後内容讀不到，頁面上原本可以繼續传递的新連結也就解析不出来，相当于發現鏈條在這里断了一截。
- 连接排队造成的延迟會叠加。應用层如果被慢查询、同步外部調用堵住，多個請求會一起變慢，而不只是某一個頁面。
- 反复超时或报错之後，抓取速率可能被下調。這種下調通常不會立刻恢复，需要一段時間的稳定表現。
5xx、429 與超时不是一回事
5xx 表示服務端出了故障，通常是临时性的，處理方式是尽快修复，而不是繼續推送新的 URL。429 是明确的限速信号，說明請求来得太密，需要降低频率。连接超时和讀取超时介于两者之間，有时是網絡問题，有时是服務器自己處理不過来。
這三種情况在看日誌时應该分開統計，因為對應的處理動作完全不同。把超时当成限速去降频，可能放過了真正的性能問题；把 5xx 当成偶發網絡抖動，則可能让故障持續更久。
能長期稳定返回 200 的站点，比偶尔飞快、偶尔报错的站点更容易保持抓取节奏。
哪些頁面的响應速度最该保住
- 首頁和主要栏目頁。它們是整個站点最主要的發現入口。
- 站点地图文件與各類列表頁。這些頁面本身不承担内容價值，但决定了下游地址能否被發現。
- 新發布的詳情頁。新地址刚進入队列，前期抓取意愿較高，此时超时會浪費机會。
- 分頁和聚合入口。它們串起一批地址，慢一次可能影响一整段。
這些頁面慢下来，影响的不只是它們自己的抓取，而是它們背後那一串地址的發現進度。
可以落地的几件事
- 给入口頁加缓存，避免每次請求都做同样的資料库查询和模板拼接。
- 把同步的外部接口調用改成异步或本地缓存，別让第三方服務的抖動传到自己的响應時間上。
- 大促、批量導入、整站改模板這類高负载操作，尽量避開同一時間窗口。
- 在服務器日誌里按狀態碼和响應時間分组，定期看超时比例和 5xx 占比，而不是只看訪問總量。
- 出現持續 5xx 时先修故障，暂时不提交新的 URL 或站点地图，等稳定後再推。
稳定本身就是一種優势
抓取节奏下降得往往很快，恢复却要慢一些。與其追求某一天抓取量冲高，不如让响應時間在一段時間内保持平稳。稳定的响應意味着队列能被持續消化，新地址不會長期积压。
把 URL 發現理解成一條從連結到内容的通路，服務器响應時間决定了這條路走得顺不顺。管住入口頁的响應時間和错誤率，就是给 URL 發現留出了空間。