聊 URL 发现时，大多数讨论集中在链接、站点地图和内链结构上。这些确实决定了地址能不能进入队列，但发现只是第一步。链接被记下来之后，还要真正发请求、等响应、读内容、解析出新的链接，这一整条链路能不能走完，很大程度上取决于服务器回答得有多快。
发现和抓取是两件事
发现解决的是“这个地址存在”，抓取解决的是“这个地址的内容我拿到了”。前者靠链接和入口，后者靠一次完整的 HTTP 往返。响应时间越长，单位时间内能完成的抓取次数就越少，队列里排在后面的地址等待的时间也越长。
可以把它想成一条传送带：入口页负责往上传地址，服务器负责把内容送回来。传送带本身不慢，但每次送件都要等很久，整体吞吐就下来了。新发布的页面、层级较深的页面，往往是这种延迟最先波及的对象。
响应变慢时会发生什么
- 单次抓取耗时被拉长，同样一段时间能覆盖的 URL 数量变少，部分地址的抓取被推到更晚。
- 超时概率上升。请求中断后内容读不到，页面上原本可以继续传递的新链接也就解析不出来，相当于发现链条在这里断了一截。
- 连接排队造成的延迟会叠加。应用层如果被慢查询、同步外部调用堵住，多个请求会一起变慢，而不只是某一个页面。
- 反复超时或报错之后，抓取速率可能被下调。这种下调通常不会立刻恢复，需要一段时间的稳定表现。
5xx、429 与超时不是一回事
5xx 表示服务端出了故障，通常是临时性的，处理方式是尽快修复，而不是继续推送新的 URL。429 是明确的限速信号，说明请求来得太密，需要降低频率。连接超时和读取超时介于两者之间，有时是网络问题，有时是服务器自己处理不过来。
这三种情况在看日志时应该分开统计，因为对应的处理动作完全不同。把超时当成限速去降频，可能放过了真正的性能问题；把 5xx 当成偶发网络抖动，则可能让故障持续更久。
能长期稳定返回 200 的站点，比偶尔飞快、偶尔报错的站点更容易保持抓取节奏。
哪些页面的响应速度最该保住
- 首页和主要栏目页。它们是整个站点最主要的发现入口。
- 站点地图文件与各类列表页。这些页面本身不承担内容价值，但决定了下游地址能否被发现。
- 新发布的详情页。新地址刚进入队列，前期抓取意愿较高，此时超时会浪费机会。
- 分页和聚合入口。它们串起一批地址，慢一次可能影响一整段。
这些页面慢下来，影响的不只是它们自己的抓取，而是它们背后那一串地址的发现进度。
可以落地的几件事
- 给入口页加缓存，避免每次请求都做同样的数据库查询和模板拼接。
- 把同步的外部接口调用改成异步或本地缓存，别让第三方服务的抖动传到自己的响应时间上。
- 大促、批量导入、整站改模板这类高负载操作，尽量避开同一时间窗口。
- 在服务器日志里按状态码和响应时间分组，定期看超时比例和 5xx 占比，而不是只看访问总量。
- 出现持续 5xx 时先修故障，暂时不提交新的 URL 或站点地图，等稳定后再推。
稳定本身就是一种优势
抓取节奏下降得往往很快，恢复却要慢一些。与其追求某一天抓取量冲高，不如让响应时间在一段时间内保持平稳。稳定的响应意味着队列能被持续消化，新地址不会长期积压。
把 URL 发现理解成一条从链接到内容的通路，服务器响应时间决定了这条路走得顺不顺。管住入口页的响应时间和错误率，就是给 URL 发现留出了空间。