链接有效性检测开始分析前怎样明确问题：先定失效判定与责任边界
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8a9c387c38ee.html
📄
链接有效性检测开始分析前怎样明确问题：先定失效判定与责任边界
开始链接有效性检测前，先把“什么算无效”写成一句话，并指定谁负责判断、谁负责修复。多人协作时，返工往往不是因为工具不准，而是因为每个人对失效的定义不同：有人把404当失效，有人把跳转到首页也算失效，还有人只关心外链是否可达。先统一判定标准，再动手跑检测，后续的清单和交付物才有意义。
把模糊描述改成可判断的问题
“链接有问题”无法直接检测，需要拆成可观察的现象。可以按下面几项逐条确认，每项都写成“是/否”或具体范围：
- 检测对象：是站内链接、站外外链，还是页面里的下载文件、图片、脚本地址？范围不同，工具和判定完全不同。
- 失效表现：返回404、403、超时、证书错误、跳转到无关页面，还是内容已替换但地址仍可访问？
- 判定阈值：超时算几秒？连续几次失败才算失效？重定向几次以内可接受？
- 处理边界：发现失效后是直接改链接、删链接，还是只记录待人工确认？
把这些写进协作说明，检测结果才能被不同人复现。假设一个页面链接到合作方站点，对方临时返回503，这属于“可能原因”，不能直接判定为永久失效；如果连续多天返回404，才更接近“已经定位的失效”。区分这两类，能避免误删仍可恢复的链接。
先观察再判断：用最小样本验证标准
不要一上来就全站扫描。先挑10到20条链接做样本，覆盖站内导航、正文外链、图片和下载文件。对每条记录四项信息：原始地址、返回状态、最终落地地址、检测时间。观察样本时重点看两类偏差：
- 状态码与页面内容不一致。例如返回200，但落地页是网站首页或错误提示页，这种“软失效”不会被状态码直接暴露。
- 同一地址在不同网络环境下结果不同。公司内网能打开、外网打不开，说明问题可能出在访问权限或地域限制，而不是链接本身写错。
样本跑完后，把实际结果与第一步写下的判定标准对照。如果标准无法解释样本中的多数情况，就先改标准，不要急着扩大检测范围。
处理与复查：把结论变成可交付记录
确认标准可用后，再批量检测并生成记录。每条失效链接至少保留：所在页面、链接地址、检测时间、状态、初步判断、处理人。处理时按原因分类，而不是按工具报告顺序逐条改：
- 地址写错：直接更正，并复查同页面是否有相同错误。
- 目标页面已迁移：确认新地址后替换，必要时保留重定向。
- 目标站点暂时不可达：标记为待复查，设定复查时间，不立即删除。
- 目标内容已不存在：决定删除链接或替换为替代来源，并记录决定人。
复查环节要独立于处理环节。由另一名协作者随机抽取已处理链接，重新检测一次，确认状态与记录一致。复查不通过时，回到判定标准讨论，而不是只修单条链接。这样交付的是一份可解释的检测记录，而不是一堆状态码截图。
多人协作中减少返工的两个检查项
第一，检测前确认工具口径。不同检测方式对重定向、超时和反爬的判定不同，第三方估算与站内统计口径也不一致，不能混用。第二，交付时附上判定标准和样本结果，让接手的人能复现你的结论。下一步可以直接用上面的样本方法跑一轮小范围检测，把判定标准写成团队共用的一页说明，再决定是否扩大范围。
