robots协议：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7bf83a591721.html
📄
robots协议：异常恢复后怎样区分缓存过期与真正修复
先给结论：只看“抓取量回来了”或“报错消失了”无法区分两者。真正修复意味着服务器对同一路径的响应内容已经改变，而缓存过期只意味着中间层或客户端不再返回旧副本。判断的关键是找到一条不经过缓存的独立验证路径，再对比同一请求在修复前后的响应体差异。
先分清两个可观测对象：响应体与抓取行为
异常恢复后常见的误判是：昨天日志里某个目录大量返回 5xx，今天恢复正常，就认为问题解决了。但这里至少有两种解释：一是源站真的不再返回错误；二是缓存层把旧的成功响应重新放出来，或者抓取方降低了请求频率，导致样本里不再出现错误。
因此要先明确你观察的是哪一个对象。响应体属于源站事实，抓取行为属于调度结果。两者可以同时变化，也可以只变一个。真正修复至少要满足：源站对同一路径、同一方法、同一 UA 的响应内容稳定地不再出现旧错误；而缓存过期只满足“当前拿到的副本不是旧的”，不保证源站已经改变。
保留、改写还是退出：三种处理的前提
面对一次异常恢复，你通常有三种动作，适用前提不同，不能混用。
- 保留原规则：适用于异常只出现在个别样本、且这些样本本身属于已知的临时错误。前提是你有独立证据证明源站响应已恢复，而不是缓存恰好刷新。若无法排除缓存，保留只是把问题推迟到下一次缓存失效。
- 改写规则：适用于异常与某条规则的处理逻辑直接相关，例如某目录的 Disallow 与抓取频率冲突。前提是你能说清改写后哪一类请求会改变结果，并且改动范围可控。改写不是“先关掉再说”，否则你无法归因。
- 退出该路径：适用于异常反复出现、且该路径对当前目标不重要。前提是你接受这部分内容短期内不再被主动抓取，并愿意用其他方式验证它是否仍可访问。退出是一种取舍，不是修复。
三种动作里，只有“改写规则并留下前后对比”能同时产生修复证据和后续判断依据。保留和退出都可能让问题暂时不可见，但不等于解决。
用一条独立请求把缓存与修复分开
具体动作：在异常恢复后，不要立刻看聚合报表，而是对同一个 URL 发起两次可区分的请求。
- 第一次带一个能绕过共享缓存的查询参数，例如
?probe=1，并记录响应状态、响应头和正文片段。 - 第二次不带该参数，走常规路径，记录同样的字段。
- 对比两次结果是否一致。若带参数的结果仍是旧错误，说明源站未修复，常规路径的“正常”来自缓存；若两者一致且都不再出现旧错误，才进入下一步。
这个动作的结果直接决定下一步：不一致时，继续排查源站或中间层，不要改 robots 规则；一致时，才值得考虑是否调整规则并观察抓取行为变化。注意查询参数可能被某些缓存策略忽略，所以这一步是缩小范围，不是最终定论。
假设例子：一次目录级异常的两种解释
假设某站点在凌晨对 /private/ 目录返回了持续数小时的 503，白天恢复正常。日志显示该目录抓取量回升。此时有两种成立解释：源站在白天确实恢复了正常响应；或者缓存层在夜间保留了旧的成功副本，白天重新命中。
要区分它们，可以取该目录下三个不同 URL，分别用绕过缓存的请求和常规请求各取一次，比较响应正文的哈希。若三个 URL 的两种请求结果都一致，源站修复的可能性高；若只有常规请求一致、绕过缓存仍返回旧错误，则更可能是缓存过期。这个例子中的数字只用于说明比较方法，不代表任何真实站点的表现。
把结论落到可复查的证据上
无论最终判断是缓存过期还是真正修复，都要留下一组可复查的证据：请求时间、完整 URL、请求方法、UA、响应状态、关键响应头、正文片段或哈希。没有这组证据，下一次异常恢复时你仍然只能靠感觉判断。
另外要记住边界：robots.txt 的抓取限制不等于可靠的索引移除；站点地图不保证收录；不同搜索引擎对同一规则的支持情况须分别核查。这些事实不影响上面的判断方法，但会影响你后续把“抓取恢复”误当成“索引恢复”的风险。真正修复是针对源站响应的，抓取和索引是另外两层结果，不能互相替代。
