很多站点在扩容、上新功能或流量上涨之後，會观察到一個共同的滞後現象：老頁面還在被訪問，新發布的 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 送到队首，這才更接近可持續的做法。