讨论 URL 发现时，大家习惯盯着链接、Sitemap 和 robots.txt，但真正决定“新地址多久被爬到”的，往往还有一层更基础的东西：服务器能不能在蜘蛛愿意等待的时间内，把页面稳定地吐出来。响应慢一点、偶尔断一次连接，看起来只是性能问题，在抓取流程里却会直接变成“这次不抓了，下次再说”。
抓取是一个排队过程，响应时间就是排队成本
搜索蜘蛛给每个站点分配的抓取资源是有限的，这个额度通常按时间单位计算，而不是按页面数量。服务器响应变慢，同样的额度能抓到的 URL 数量就会下降：旧页面已经把时间占满，新发现的地址只能继续排在队列里。也就是说，响应时间不是单纯的性能指标，它直接决定了单位时间内有多少 URL 能被走完一遍。
理解这一点后，很多现象就说得通了：站点内容没变、外链也没变，但新发布的页面迟迟不出现，往往不是“蜘蛛不来”，而是来的时候把时间花在了等待响应上。
三类常见的服务器端问题
首字节时间过长
页面 HTML 的生成依赖数据库查询、接口聚合或模板渲染，这些环节一慢，首字节时间就会被拉长。对蜘蛛来说，等待期间连接是占用的，等于把抓取额度空耗在等待上。最容易出问题的是列表页、搜索结果页和带筛选参数的地址，它们通常查询最重。
连接被重置或直接超时
防火墙限速、连接数打满、后端进程重启，都可能让蜘蛛在下载中途被断开。这类失败不会留下一个干净的状态码，只会表现为“抓取未完成”。同一批 URL 反复出现这种结果，会让这批地址在队列里的优先级进一步降低。
5xx 与限流响应
服务器过载时返回 500、502、503，会让蜘蛛判断这一批地址暂时不可抓。区别在于：返回 503 并带上 Retry-After，是明确告诉对方“稍后再来”，属于可控信号；而连接挂起十几秒后无响应，则更像故障，恢复后重新爬取的节奏往往更保守。
怎么判断问题是否出在服务器端
- 看日志中的响应时间分布，不只看平均值，重点看 P95、P99 这类长尾数值。
- 统计同一时间窗口内返回 200 的比例，以及被中断请求的占比。
- 确认超时是否集中在某一类页面，比如带参数的列表页或图片较多的详情页。
- 对照蜘蛛访问频率与响应时间曲线，观察延迟升高之后，访问频率是否随之下降。
如果响应时间在蜘蛛来访时段明显抬升，而人工访问时正常，说明问题多半出在并发处理能力或缓存覆盖上，而不是页面本身的内容质量。
稳定性上值得做的几件事
- 让需要被抓取的 HTML 不依赖接口聚合，接口慢时降级返回基础内容，而不是整体挂起。
- 给重复查询加缓存层，尤其是列表页和聚合页的首页。
- 高峰期优先保证 HTML 响应，把统计、推荐这类非必要逻辑放到异步执行。
- 确实需要限流时，返回明确的 503 与重试时间，而不是让请求一直挂着。
- 监控维度里加上“抓取成功返回率”，而不只是站点是否可访问。
URL 发现的速度，最终是链接结构、抓取额度和服务器响应三者共同作用的结果。前两项决定蜘蛛想去哪儿，第三项决定它能不能顺利走完。
所以当新页面迟迟进不来时，除了检查内链和 Sitemap，也值得回头看看服务器日志里的响应时间：那里面往往藏着最容易被忽略的一段拖延。