自动友情链接：大量链接同日失效时如何区分源站故障与逐条失效
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4bf9b270f12a.html
📄
自动友情链接：大量链接同日失效时如何区分源站故障与逐条失效
先看失效链接是否指向同一个源站，再看失效时间是否落在同一分钟级窗口，最后核对源站首页与其它页面是否同时不可达。三条都成立，优先按源站故障处理；只有部分链接失效、时间分散，才按逐条失效排查。这个判断决定了你接下来是等源站恢复，还是逐条替换。
先取一份可核对的失效清单
不要凭记忆判断“同一天失效”。从你手里的链接记录表或页面源码出发，导出每个失效链接的四个字段：链接指向的完整地址、首次发现失效的时间、失效前的最后可用时间、该链接所在页面。时间字段至少精确到小时，能到分钟更好。
导出后按域名分组。如果失效链接集中在同一个域名下，源站故障的可能性明显上升；如果分散在多个互不相关的域名，逐条失效更合理。注意，同一域名下有多条链接同时失效，也可能只是对方一次性清理了旧页面，不能直接等同于服务器宕机。
三个证据把源站故障和逐条失效分开
假设你手中有 20 条失效链接，其中 14 条指向同一个源站。可以按下面三个条件逐项核对：
- 可达性范围：源站首页、栏目页、被链页面是否同时返回错误或超时。若整个源站都不可达，源站故障成立；若只有被链的具体页面 404，而首页正常，更接近逐条失效。
- 时间聚集度：14 条链接的失效发现时间是否集中在同一小时甚至同一分钟内。高度聚集指向源站层面的中断；分散在数小时或数天，则更像对方逐页调整。
- 影响面一致性：同一源站下，是否只有你这一条链接失效，还是其它站点的链接也受影响。前者可能是对方单独删除了你的链接，后者才更像源站整体问题。
三个条件不必全部满足才下结论，但至少要有一个条件明确指向源站层面，否则按逐条失效处理更稳妥。
一个假设例子：14 条同日失效怎么判
假设你在周一上午发现 14 条链接失效，全部指向 example-source.test，失效发现时间集中在 09:12 到 09:18 之间。此时先访问该源站首页：如果首页同样无法打开，按源站故障处理，暂时保留这些链接记录，等待源站恢复后再复核，不要立即替换。如果首页正常，只有被链的具体页面返回 404，则按逐条失效处理，进入下一步替换或移除。
这个例子的关键不是数字本身，而是“先看范围、再看时间”的顺序。顺序反了，容易把对方一次页面改版误判为服务器故障，白白等待。
按判断结果执行不同动作
判断为源站故障时，实际动作是：在链接记录中把这批链接标记为“待复核”，设定一个复核时间点，例如 24 小时或 48 小时后。到点后重新访问源站首页和被链页面。若恢复，链接通常无需改动；若仍未恢复，再转入逐条失效流程。这个动作的结果直接决定下一步：恢复则继续观察，未恢复则替换。
判断为逐条失效时，实际动作是：逐条打开被链页面，确认是 404、410 还是跳转到无关内容。404 和 410 通常意味着对方已移除该页面，应替换为同站点的有效页面或移除该链接；跳转到无关内容则说明对方改版，需要重新评估是否保留。处理完一条就更新记录中的状态字段，避免下次重复排查。
复核时不要只看链接数量归零
链接数量归零或某次抓取全部失败，不能单独证明源站故障。它也可能是你的抓取工具被对方限流、本地网络中断、或记录表本身未及时更新。反过来，链接数量没有变化，也不代表源站正常，可能只是抓取尚未覆盖到失效页面。因此，复核时要同时看源站首页可达性、被链页面状态码和失效时间分布，三者互相印证后再下结论。
把这份判断流程固定到你的链接记录表里：新增“失效类型”一列，取值只有“源站故障”“逐条失效”“待定”三种。每次批量失效先填“待定”，按范围和时间核对后再改为前两种。这样下一次遇到同日失效，你不必重新推导，直接按列判断即可。
