这类问题我又碰上了一次。内容团队攒了两周的稿子，周一一次性发布六十篇。三天后日志里只有三篇被抓过，sitemap 里其它地址一直停在已发现，抓取预算并没有下降，只是排队排到了后面。
第一反应是「站点更新的历史频率很低 突然放量被当成异常信号」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。同一时间大量新地址出现 抓取队列按时间排 后面的要等很久；新页面没有内链入口 只能靠 sitemap 被发现 优先级更低；首页和列表页一次性堆了六十条 新内容互相稀释。
动手时先看新地址在日志里的首次抓取时间
grep -E '2026-11-1[0-2]' access.log | grep -c '/post/然后把发布改成每天固定几篇
for i in $(seq 1 6); do echo "publish $i"; sleep 600; done给新文章补上栏目和首页入口
curl -s https://www.example.com/ | grep -c '/post/2026'等前面都确认过，再用主动提交把重点文章推到队首
curl -s 'http://data.zz.baidu.com/urls?site=https://www.example.com&token=TOKEN' -d "$URLS"恢复的判定其实很直接。改成每天发布六篇并补上入口后，新文章的首次抓取时间从三天缩短到六小时以内，当周发布的二十篇全部进索引。
提醒一点。抓取队列对突然放量并不友好，稳定的小批量发布比一次性刷六十篇更容易被及时处理。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。