友情链接检查遇到大量链接同日失效：先判断源站故障还是逐条失效
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /569ba0028ada.html
📄
友情链接检查遇到大量链接同日失效：先判断源站故障还是逐条失效
先看失效是否集中指向同一域名。如果同一源站的多个链接在同一天返回相同错误，优先怀疑源站故障；如果失效链接分散在不同域名、错误类型各不相同，才更可能是逐条失效。缺少完整数据或权限时，你仍可以做一件最小动作：按域名分组，记录每个域名下失效链接的数量、错误码和首次发现时间，再决定是等待复查还是逐条处理。
同一域名批量失效：先等一次复查，不要立刻删链
当多个链接指向同一个源站，并在同一天出现相同状态，最合理的解释是源站整体不可用、改版或临时屏蔽，而不是这些页面各自被删除。此时逐条替换的代价很高，而且可能把仍然有效的合作方误判为失效。
可执行的最小动作是：把失效链接按域名归组，对同一域名只选取一个代表链接进行复查，间隔至少一天。复查结果会直接影响下一步：
- 代表链接恢复，说明源站故障的可能性大，其余同域名链接先保留，继续观察。
- 代表链接仍失效，但该域名首页可访问，说明可能是个别页面被移除，需要逐条确认。
- 域名本身无法解析，说明源站可能已停用，此时再考虑移除或联系对方。
这里有一个常见误判：抓取工具显示超时或连接失败，并不等于链接被删除。服务器限流、临时维护、DNS 波动都会造成同样结果。因此同日批量失效不能单独作为删除依据。
分散在不同域名：按错误类型逐条判断
如果失效链接来自不同域名，且错误类型不一致，例如有的返回 404、有的返回 403、有的跳转到无关页面，那么更接近逐条失效。此时等待复查的收益很低，应按错误类型排序处理。
可以按以下顺序判断优先级：
- 404 或 410：页面大概率已被移除，优先确认对方是否还有可替代的相关页面。
- 403 或 401：可能是权限或反爬限制，不一定是链接失效，先换正常浏览器环境验证。
- 跳转到无关页面：原链接已失去指向意义，通常应移除或替换。
- 超时或连接失败：先归入待复查，不直接判定失效。
这个顺序的作用是避免把访问限制当成内容删除。一个返回 403 的链接，如果直接删除，可能损失一个仍然存在的合作页面；而先验证再处理，下一步动作会更明确。
缺少完整数据时，用域名分组代替全量核查
没有完整后台数据、没有对方联系方式、也没有历史抓取记录时，不必追求一次性查清所有链接。更实际的做法是只做域名分组，并记录三个字段：域名、失效链接数、代表链接的当前状态。
假设有 40 条链接同日失效，其中 32 条来自同一个域名，另外 8 条分散在 6 个域名。按域名分组后，你只需要优先复查那 1 个集中域名和 6 个分散域名中的代表链接，而不是逐条打开 40 个页面。这个动作的结果会决定后续工作量：集中域名恢复，则大部分问题可能自行消失；分散域名持续失效，才需要逐条替换或移除。
需要说明的是，这种方法只能缩小排查范围，不能证明源站一定故障，也不能证明分散失效一定与对方主动删除有关。它提供的是下一步动作的依据，而不是最终结论。
复查之后仍要保留判断例外
即使同一域名批量失效，也存在例外：对方可能一次性下架了整个栏目，或者更换了域名结构，导致多个页面同时 404。这种情况下，等待复查不会恢复链接，仍需要联系对方或移除。
反过来，分散失效也可能有共同原因，例如你的抓取环境当天出现网络问题，导致多个不同域名同时超时。因此，判断源站故障还是逐条失效，关键不是失效数量，而是失效是否集中在同一域名、是否呈现相同错误、以及复查后是否同步恢复。把这三条证据放在一起，再决定等待、替换还是移除，比按日期批量删除更稳妥。
