爬虫日志分析：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ee8542852226.html
📄
爬虫日志分析：异常恢复后怎样区分缓存过期与真正修复
先给结论：异常恢复后，日志里“重新出现正常抓取”通常不能直接当作修复证据，它更可能是缓存过期、CDN节点刷新或调度周期轮转。真正区分两者，要看同一批URL在恢复窗口内是否出现可解释的抓取路径变化，而不只是状态码从5xx回到200。若状态码恢复但抓取频次、抓取深度、抓取主体都与异常前一致，倾向缓存过期；若抓取路径、参数、频次或后续索引行为出现结构性变化，才更接近真正修复。
先看恢复的时间形态：整齐回弹还是逐步爬升
缓存过期往往表现为“整齐回弹”。假设某批旧内容因源站故障在日志中连续出现5xx，修复后如果所有URL几乎在同一分钟恢复200，且抓取间隔、抓取顺序与故障前完全一致，这更像缓存层统一过期或CDN节点批量刷新，而不是爬虫重新发现了修复信号。
真正修复通常带有渐进特征：先恢复高频入口页，再逐步回到深层页；先恢复被频繁链接的URL，再恢复孤立URL。你可以按小时切分日志，观察恢复曲线是否呈阶梯状。如果恢复曲线是垂直的，且没有任何抓取优先级变化，优先怀疑缓存。
这里要说明一个适用条件：如果站点本身抓取频次极低，渐进特征可能被采样掩盖，此时不能仅凭时间形态下结论，需要结合下文的请求特征一起判断。
对比恢复前后的请求特征，而不只是状态码
状态码从5xx回到200只是必要条件，不是充分条件。真正修复会在请求特征上留下痕迹。可以对比恢复前后同一URL的以下字段：
- User-Agent是否从异常期的单一抓取主体恢复为多个抓取主体；
- 请求路径是否重新包含被异常期丢弃的参数或分页；
- 抓取深度是否从仅抓首页回到包含列表页和详情页；
- 同一URL的抓取间隔是否从固定周期变为带随机抖动的正常调度。
如果这些字段在恢复前后完全一致，只是状态码变了，缓存过期的解释更强。如果其中至少两项出现变化，才值得考虑真正修复。
动作上，建议把恢复窗口内的日志按URL分组，导出上述字段的对比表。这个动作的结果会直接影响下一步：若字段无变化，下一步应检查缓存层而不是继续改源站；若字段有变化，下一步才去验证索引侧是否跟进。
用保留、改写或退出的取舍来验证修复深度
旧内容、旧系统或旧合作关系退出时，修复往往不是“全部恢复”，而是“保留一部分、改写一部分、退出一部分”。这个取舍会直接反映在日志里，也是区分缓存与真修复的关键。
假设一个旧栏目计划退出，只保留其中仍然有价值的几篇内容，其余做410或301。真正修复后，日志中应该出现：保留URL继续被抓取，退出URL的抓取频次下降，改写URL出现新的抓取路径。如果恢复后所有URL不分保留、改写、退出，一律回到异常前的抓取模式，这更像缓存把旧状态整体吐了回来，而不是修复策略生效。
反过来，如果保留URL被抓取、退出URL不再被抓取、改写URL出现新参数，这种分化说明抓取系统已经感知到站点结构变化，缓存解释就不够用了。此时可以进入下一步：核对索引侧是否也出现同样的分化。
排除其他合理解释，再决定是否收工
请求量或抓取量归零、恢复或某状态码消失，都不能单独证明处理正确。恢复后日志正常，还可能是以下原因：
- 抓取预算被其他栏目占用，旧内容只是暂时被冷落；
- 调度周期恰好轮转到该批URL，与修复动作无关；
- CDN或反向代理缓存了旧的200响应，源站实际仍在异常；
- robots.txt的抓取限制变化改变了抓取范围，但这不等于索引移除。
要排除这些，可以做一个注明假设的短验证：假设缓存是主因，那么直接回源请求同一URL应看到与日志不同的状态；假设真正修复是主因，那么回源请求应与日志状态一致，且抓取路径已变化。这个验证不承诺任何收录或排名结果，只用于判断下一步该查缓存层还是查源站。
最后提醒：站点地图不保证收录，HTTPS不保证安全或排名，robots.txt限制也不等于可靠的索引移除。区分缓存过期与真正修复，最终要落到抓取路径是否发生可解释的变化，而不是单一状态码或单一统计量的回弹。
