发外链：大量链接同日失效时如何区分源站故障与逐条失效
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /14e2fd5bda7a.html
📄
发外链：大量链接同日失效时如何区分源站故障与逐条失效
先看失效时间戳和源站状态：如果同一域名下的多条外链在几分钟到几小时内集中失效，且该域名首页也打不开，优先判断为源站故障；如果失效链接分散在不同域名、不同发布时间，且各自源站仍可访问，则更可能是逐条失效。判定顺序会直接改变后续动作——源站故障应等待恢复并保留记录，逐条失效才需要逐条替换或放弃。
先做一次时间戳聚类，而不是逐条打开链接
把失效链接导出成一张表，至少保留四列：外链所在页面、目标URL、首次发现失效的时间、上次确认有效的时间。不要急着逐条访问，先按“首次发现失效时间”排序，观察是否出现明显的聚集。
如果十几条链接的失效时间落在同一个小时甚至同一分钟，这通常不是巧合。逐条失效往往是自然衰减：对方改版、删栏目、换域名、加登录墙，发生时间分散。源站故障则相反，一次宕机、一次证书过期、一次DNS解析异常，会让同一域名下的所有引用同时不可达。
这里要提醒一点：抓取工具报告某批链接“失效”，不等于它们真的失效。工具可能因为超时、限流、临时封禁而误报。所以时间戳聚类之后，必须做下一步的源站可达性验证。
验证源站本身是否可达，区分三种状态
对失效链接涉及的每个域名，单独访问其首页或一个已知正常的页面，记录返回状态。可以分成三类：
- 源站整体不可达：首页也超时或返回5xx。这指向源站故障，包括服务器宕机、DNS问题、证书过期、防火墙误拦。
- 源站可达，但目标页面404或410：说明源站活着，只是那个具体页面被删或改址。这属于逐条失效。
- 源站可达，目标页面跳转到登录页或验证页：可能是对方加了访问限制，不一定是链接被删。
如果同一域名下多条链接都落入第一类，基本可以按源站故障处理。如果同一域名下有的链接正常、有的失效，则要看失效页面是否集中在某个栏目或某次改版之后，这更接近逐条失效。
一个可执行的动作是：对判定为源站故障的域名，设置一个短周期复查提醒，比如隔一天再看一次，而不是当天就删链接或换链接。复查后如果首页恢复、原目标页面也恢复，说明之前只是暂时不可达，不需要替换。复查后如果首页恢复但目标页面仍然404，才转入逐条处理。
用同一域名的多条链接做交叉验证
单条链接失效很难判断原因，但同一域名下有多条外链时，交叉验证会清楚很多。假设你曾经在同一个来源站的三个不同页面各留了一条链接，现在三条同时失效。这时分别访问这三个来源页面：
- 三个页面都打不开，且该站首页也打不开——源站故障。
- 三个页面都能打开，但三条目标链接都指向404——对方可能批量清理了外链或改了URL结构。
- 三个页面中只有一个能打开，另外两个打不开——混合情况，需要拆开处理。
这个方法的假设是：你手里确实有同一域名的多条链接记录。如果没有，就只能依赖时间戳和源站可达性两项证据，判断会弱一些，此时更稳妥的做法是先标记为“待复查”，不要立刻删除。
交叉验证的结果会直接影响下一步：源站故障对应的链接应保留在监测列表里，等待恢复；逐条失效对应的链接才进入替换队列，评估是否值得换新页面、换新来源，或者直接放弃。
把判断结果转成两种不同的处理路径
路径一：源站故障。动作是保留记录、暂停替换、设置复查。结果是如果源站恢复，链接可能自动恢复有效，你省下重新沟通和替换的成本。如果复查多次仍不可达，再按逐条失效处理。
路径二：逐条失效。动作是逐条确认目标页面是否还有替代URL、来源页面是否还保留你的链接、对方是否愿意更新。结果是能更新的更新，不能更新的评估是否用新页面替换，或者接受这条链接已经结束。
两条路径的关键区别在于时间：源站故障通常有恢复窗口，逐条失效往往不可逆。把这两类混在一起处理，最常见的错误是源站一宕机就急着删链接、换链接，等对方恢复后反而丢失了原本有效的外链位置。
最后检查一件事：你的监测记录是否保留了“上次确认有效的时间”。如果没有这一列，时间戳聚类就缺少基准，很多判断只能靠印象。补上这一列，是下一次遇到批量失效时最省事的准备。
