死链查询：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7143767ac970.html
📄
死链查询：异常恢复后怎样区分缓存过期与真正修复
先给出判断：一次死链查询返回正常，只说明这次请求路径上的那个节点给出了正常响应，不能直接推出源站已修复。要区分缓存过期与真正修复，最可靠的做法是同时改变请求路径与请求身份，观察结果是否稳定收敛，而不是反复刷新同一个入口。
先确认你看到的是哪一层的结果
死链查询的异常恢复通常经过三段：源站响应、中间缓存、抓取与索引。三段里任何一段变化都会让查询结果变好。缓存过期属于中间层，真正修复属于源站层。判断顺序应当是自下而上，而不是自外向内。
可区分的证据大致有三类：
- 响应头里带缓存命中标识或较新的
Age值，说明结果来自缓存副本，源站是否变化未知。 - 同一路径加随机查询串后仍返回正常，说明源站本身已能正常响应，缓存嫌疑下降。
- 不同网络出口或不同解析结果下表现一致，说明不是单一缓存节点造成的假象。
反过来，如果只有原入口正常、加随机参数后仍异常，基本可以判定是缓存过期而非修复。这个结论会直接决定下一步：前者要清缓存或等缓存自然过期，后者才需要回到源站排查。
保留、改写还是退出：三种取舍的适用前提
异常恢复后，对原 URL 的处理不是只有“保留”一条路。选择取决于异常原因和该 URL 的既有价值。
保留适用于源站已确认返回正常、且该 URL 有外部链接或历史访问的情况。前提是你已经用绕过缓存的方式验证过源站。动作是维持原 URL 不动，观察一段时间内抓取与索引结果是否跟上。如果源站正常但索引长期不更新，问题在抓取与索引层，此时改写或退出都不会更快。
改写适用于原 URL 结构本身有问题，比如参数导致同一内容多路径、或路径规则与现有架构冲突。前提是你能保证改写后旧地址仍有明确的跳转关系。动作是设置指向新地址的跳转并更新站内链接。结果如何影响下一步：如果跳转生效后旧地址的异常消失、新地址被抓取，说明问题出在 URL 设计；如果旧地址依旧异常，说明还有缓存或跳转链未清理。
退出适用于该 URL 确实不再需要、且没有外部链接价值的情况。前提是确认它不承担流量或跳转职责。动作是让它返回明确的不存在状态，而不是返回正常内容。这里要注意：robots.txt 的抓取限制不等于可靠的索引移除，屏蔽抓取往往让已存在的索引结果更难被更新，而不是更快消失。
规模化后为什么个别样本的经验会失效
单条 URL 上成立的判断，放到成批查询里经常出现例外，原因通常是缓存层级和抓取调度并不均匀。少数 URL 恢复正常，可能只是恰好命中了已过期的缓存节点；其余 URL 仍指向旧副本。
假设有 100 条已修复的 URL，你只抽查了 3 条，全部正常。这个样本量不足以说明整体恢复，因为缓存过期时间可能分散在不同时刻。更稳的做法是：对同一批 URL 分两次、间隔一段时间查询，并记录每次的响应头特征，而不是只看状态码。如果两次结果不一致，说明缓存仍在起作用；如果两次都正常且加随机参数也正常，修复的可信度才提高。
另一个常见例外是站点地图。把 URL 放进站点地图不保证收录，它只表达“这些地址存在”，不改变缓存和索引的既有状态。因此不能用地图像是否被读取来判断死链是否真正修复。
把判断落到一个可执行的动作上
建议按这个顺序操作，每一步的结果决定下一步：
- 对异常 URL 加随机查询串重新请求，绕过缓存。若仍异常，直接回源站排查，不必再纠结缓存。
- 若加参数后正常，记录原请求的缓存相关响应头，判断是缓存过期还是源站已修。
- 对判定为源站已修的 URL，间隔一段时间复查两次，两次一致才进入保留或改写决策。
- 对判定为缓存问题的 URL，先等缓存自然过期或按现有机制清理，再复查，不要立刻改写地址。
这套顺序的价值在于：它把“看起来恢复了”拆成可验证的层次，避免在缓存未过期时就改动 URL 结构，也避免在源站仍异常时误以为只是缓存问题。HTTPS 在这里不构成判断依据，它既不保证内容已修复，也不影响缓存是否过期这一事实。
最后需要区分的是：请求量或抓取量归零，不能单独证明修复正确。它也可能来自抓取预算调整、屏蔽规则生效或调度延后。只有把响应路径、响应身份和时间维度三者对齐，才能对“缓存过期还是真正修复”给出站得住的结论。
