死链接检测：错误只在特定时段出现时怎样捕捉短暂证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0833ecaa0f84.html
📄
死链接检测：错误只在特定时段出现时怎样捕捉短暂证据
当死链接检测在一天中的某个时段集中报错，而在其他时段恢复，最不该做的是立刻删掉旧入口或改掉跳转规则。先把它当作间歇性故障处理：用定时探测把“什么时候坏、坏多久、影响哪些URL”变成可复查的记录，再决定是修复链路还是让旧内容退出。
先分清两种解释：源站间歇不可用，还是检测链路本身抖动
同一批URL在凌晨返回404、白天正常，通常有两种成立条件完全不同的解释。
- 源站侧间歇异常：旧系统在定时任务、备份窗口或证书续期时短暂拒绝请求，返回404、410或5xx。特征是同一时段、同一批URL反复出现，恢复后状态码回到200。
- 探测侧或路径抖动：DNS解析、CDN回源、代理超时或探测节点网络波动造成误判。特征是错误分散在不同URL、状态码杂乱，且换一个探测位置结果不同。
这两种解释对应的动作相反：前者要改源站或退出旧系统，后者只需要调整探测方式。判断错方向，会把仍然有价值的旧内容误删。
用定时探测把“短暂”变成可比较的时间序列
手动点几次链接无法捕捉只在特定时段出现的错误。实际动作是：对可疑URL清单设置固定间隔的探测，例如每5到15分钟一次，至少覆盖一个完整周期（一天或一周），并记录时间戳、状态码、响应时间、最终跳转地址和探测来源。
这个动作的结果决定下一步：
- 如果错误集中在固定时间窗且URL高度重合，优先怀疑源站定时任务、维护窗口或旧系统限流，下一步是查该时段的服务器日志和任务计划。
- 如果错误时间随机、URL分散，优先怀疑探测链路，下一步是增加第二个探测位置做对照。
- 如果错误只出现在跟随跳转之后，说明问题在重定向链而不是原始URL，下一步是单独记录每一跳的状态。
假设某旧栏目在每天02:00到02:20之间返回404，其余时间正常。仅凭一次白天的手动检查会得出“链接正常”的结论；只有定时记录才能暴露这个窗口。这是说明比较方法的假设例子，不是真实项目结果。
区分证据时，别把“某次请求失败”当成“链接已死”
短暂错误和真正死链接的区别，在于可重复性和一致性。可用来区分的证据包括：
- 重复性：同一URL在多个周期内同一时段失败，支持源站侧解释；只失败一次则证据不足。
- 状态码一致性：稳定返回404或410，偏向内容确已移除；在404、502、超时之间跳变，偏向链路或负载问题。
- 探测位置差异：不同网络位置结果不同，指向DNS、CDN或区域路由；结果一致则更可能是源站。
- 响应时间与错误的相关性：错误总伴随超时或极慢响应，提示资源瓶颈而非内容删除。
需要提醒的是，请求量或抓取量在某个时段归零，并不能单独证明链接已被正确处理。它也可能来自探测任务本身失败、日志延迟、缓存命中或该时段本来就没有访问。把这些现象当作线索，而不是结论。
决定旧内容退出前，先保留仍然有价值的部分
当旧系统或旧合作关系确实要退出，处理顺序应是：先确认哪些URL仍在被外部引用或有实际访问价值，再决定保留、重定向还是返回410。
- 仍被引用的内容：优先保留原URL或做一对一重定向，避免把短暂错误升级为永久失效。
- 确定无价值的内容：可以返回410，但要在定时记录确认它长期稳定失败之后再做，而不是在某个错误窗口内批量处理。
- robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录；如果目标是让旧内容退出索引，需要按各搜索引擎的支持情况分别核查，而不是只靠一个文件。
执行一次重定向或410之后，继续用同样的定时探测观察至少一个完整周期。如果错误窗口消失，说明处理命中了源站侧原因；如果错误仍在同一时段出现，说明问题不在内容层，应回到服务器任务和链路排查。这个结果直接决定下一步是收尾还是继续定位。
把短暂证据固定下来，才能避免反复误判
捕捉特定时段错误的关键不是更频繁地手动检查，而是让每次探测都留下可比对的时间戳和状态记录。只要证据能区分“源站间歇不可用”和“探测链路抖动”，后续的保留、重定向或退出决策才有依据，也不会因为一次偶发报错就牺牲仍然有价值的旧内容。
