很多站点在扩容、上新功能或流量上涨之后，会观察到一个共同的滞后现象：老页面还在被访问，新发布的 URL 却迟迟不见抓取。排查内容、内链、Sitemap 都正常，问题往往出在服务器响应时间上——它先影响抓取频次，然后才轮到 URL 发现。
抓取频次不是一个固定值
搜索引擎给每个站点的抓取节奏是动态调整的。它同时看两件事：站点能承受多少并发，以及抓下来的内容值不值得继续抓。响应时间变长，等于单位时间内能完成的请求变少；如果还伴随超时和 5xx，抓取端会主动降低并发，把配额挪给其他站点。
这个过程是渐进的。第一天可能只是抓取总量略降，第三天新 URL 的入队延迟就明显了，一周后抓取日志里几乎只剩下被频繁访问的列表页和首页。
变慢时，最先被牺牲的是新 URL
抓取端在配额紧张时做的是取舍，不是平均分配。已经积累过权重、更新频率高的老 URL 会被优先保留，因为它们的抓取收益是可预期的；而从未被抓过的新 URL，只有 Sitemap、内链和外链给出的预期值，一旦预算不够，它们就会被排到后面。
几个常见的对应现象
- 抓取日志里 200 响应减少，5xx 或超时条目增多；
- 平均响应时间从几百毫秒升到一两秒，抓取并发同步下降；
- 新页面处于“已发现未抓取”状态的数量持续累积；
- 大文件、动态接口类 URL 反复被请求，拖住整个队列。
站点侧能控制的部分
- 缩短首字节时间：数据库慢查询、未命中缓存的模板渲染、同步调用外部接口，通常是主要来源。把响应稳定在可预期区间，比事后加机器更有效。
- 静态资源与页面分开：图片、JS、CSS 交给 CDN，抓取端的请求尽量落在能快速返回 HTML 的路径上。
- 控制单页触发的资源数量：一个页面牵出上百个请求，会挤占其他 URL 的抓取额度。
- 给慢接口加缓存或降级：搜索页、筛选页这类参数组合多的 URL，最好不要每次都实时查询。
- 保持 5xx 在低位：偶发报错可以接受，持续报错会直接触发降速。
用抓取日志确认影响范围
只看监控面板不够，要落到具体 URL 上：
- 按小时统计抓取请求数、平均响应时间和状态码分布；
- 把响应时间超过阈值的 URL 单独列出，看是否集中在某个模板或某个接口；
- 对比新 URL 在抓取总量中的占比，看是否随时间明显萎缩；
- 调整后再跑一轮同样的统计，确认指标是否回到正常区间。
抓取频次下降不一定全是服务器的问题。robots.txt 变更、大面积跳转、内容质量整体下滑都可能造成类似结果。日志只说明现象，结论要靠逐项排除得来，也不必期待调整后立刻恢复——抓取节奏的调整通常有滞后。
小结
URL 发现的延迟，很多时候不是“没告诉搜索引擎”，而是“告诉了但排不上队”。把响应时间、错误率和单页请求数控制住，等于给抓取端腾出空间；剩下的交给 Sitemap 和内链把新 URL 送到队首，这才更接近可持续的做法。