讨论 URL 發現时，大家习惯盯着連結、Sitemap 和 robots.txt，但真正决定“新地址多久被爬到”的，往往還有一层更基础的東西：服務器能不能在蜘蛛愿意等待的時間内，把頁面稳定地吐出来。响應慢一点、偶尔断一次连接，看起来只是性能問题，在抓取流程里却會直接變成“這次不抓了，下次再说”。
抓取是一個排队過程，响應時間就是排队成本
搜尋蜘蛛给每個站点分配的抓取资源是有限的，這個額度通常按時間單位計算，而不是按頁面數量。服務器响應變慢，同样的額度能抓到的 URL 數量就會下降：舊頁面已经把時間占满，新發現的地址只能繼續排在队列里。也就是说，响應時間不是單纯的性能指标，它直接决定了單位時間内有多少 URL 能被走完一遍。
理解這一点後，很多現象就说得通了：站点内容没變、外鏈也没變，但新發布的頁面迟迟不出現，往往不是“蜘蛛不来”，而是来的时候把時間花在了等待响應上。
三類常见的服務器端問题
首字节時間過長
頁面 HTML 的生成依赖資料库查询、接口聚合或模板渲染，這些环节一慢，首字节時間就會被拉長。對蜘蛛来说，等待期間连接是占用的，等于把抓取額度空耗在等待上。最容易出問题的是列表頁、搜尋结果頁和带篩選參數的地址，它們通常查询最重。
连接被重置或直接超时
防火墙限速、连接數打满、後端進程重啟，都可能让蜘蛛在下载中途被断開。這類失敗不會留下一個干净的狀態碼，只會表現為“抓取未完成”。同一批 URL 反复出現這種结果，會让這批地址在队列里的優先級進一步降低。
5xx 與限流响應
服務器過载时返回 500、502、503，會让蜘蛛判断這一批地址暂时不可抓。区別在于：返回 503 並带上 Retry-After，是明确告诉對方“稍後再来”，属于可控信号；而连接挂起十几秒後無响應，則更像故障，恢复後重新爬取的节奏往往更保守。
怎么判断問题是否出在服務器端
- 看日誌中的响應時間分布，不只看平均值，重点看 P95、P99 這類長尾數值。
- 統計同一時間窗口内返回 200 的比例，以及被中断請求的占比。
- 確認超时是否集中在某一類頁面，比如带參數的列表頁或图片較多的詳情頁。
- 對照蜘蛛訪問频率與响應時間曲线，观察延迟升高之後，訪問频率是否随之下降。
如果响應時間在蜘蛛来訪时段明顯抬升，而人工訪問时正常，說明問题多半出在並發處理能力或缓存覆盖上，而不是頁面本身的内容质量。
稳定性上值得做的几件事
- 让需要被抓取的 HTML 不依赖接口聚合，接口慢时降級返回基础内容，而不是整体挂起。
- 给重复查询加缓存层，尤其是列表頁和聚合頁的首頁。
- 高峰期優先保證 HTML 响應，把統計、推荐這類非必要逻辑放到异步执行。
- 确實需要限流时，返回明确的 503 與重试時間，而不是让請求一直挂着。
- 监控维度里加上“抓取成功返回率”，而不只是站点是否可訪問。
URL 發現的速度，最终是連結结构、抓取額度和服務器响應三者共同作用的结果。前两項决定蜘蛛想去哪儿，第三項决定它能不能顺利走完。
所以当新頁面迟迟進不来时，除了检查内鏈和 Sitemap，也值得回头看看服務器日誌里的响應時間：那里面往往藏着最容易被忽略的一段拖延。