现场是这样的。站点每周一早上看报表，收录量都比周五少两千条左右，周三又慢慢涨回来。运营以为周末内容更新少导致掉收录，连着补了四周的周末更新，曲线还是原样。
中间走过弯路，把「周末流量低 蜘蛛抓取量下降 收录在周一才体现出滞后」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。报表按自然周切片 与蜘蛛按滚动窗口抓取的节奏不同步；周一的统计任务在数据同步前执行 拿到的是未完成的快照；索引数据本身有几天延迟 报表却按当天日期归属。
拉取连续 30 天的收录曲线看周期性
curl -s 'https://www.example.com/api/index-stats?days=30' | jq '.data[] | [.date,.count]'再往下确认统计任务的执行时间与数据延迟
crontab -l | grep -n stats接着改成按 7 天滚动平均展示
SELECT date, AVG(cnt) OVER (ORDER BY date ROWS 6 PRECEDING) FROM index_daily;末了对照抓取日志确认周末抓取量
grep -c Googlebot access.log.$(date +%Y%m%d)恢复的判定其实很直接。换成滚动平均后曲线平滑了，周一的凹陷不再出现，团队也不再为这个假信号加班补内容。
这里还有个坑。收录数据的采集、汇总、展示三层各有延迟，把周期性波动当成异常去救，往往越救越乱。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。