友情链接检测，报告应该展示哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7fc0992c5b13.html
📄
友情链接检测，报告应该展示哪些证据
一份能支撑决策的友情链接检测报告，核心不是给出“好或坏”的结论，而是展示可复核的证据链：链接是否存在、是否可被正常抓取、对方页面是否仍在链、链接属性是否被改动，以及这些事实的采集时间与来源。缺少原始证据的结论无法比较两种处理方案，也无法在后续复查时判断问题是否真的解决。
准备阶段：先确定检测范围与记录口径
检测前要明确三件事：检测哪些页面、以什么身份抓取、记录哪些字段。建议至少记录以下内容：
- 己方被链接页面的完整URL与页面标题。
- 对方链接所在页面的完整URL，而不是只记域名首页。
- 链接锚文本、链接指向的最终URL（注意跳转后的落点）。
- 链接所在位置的上下文，例如正文、侧栏、页脚。
- 链接的HTML属性，例如是否带
rel="nofollow"、rel="sponsored"、rel="ugc"。 - 检测时间、检测工具或抓取方式、HTTP状态码。
口径不统一会让两种处理方案无法比较。例如同样是“链接消失”，可能是对方删除了链接，也可能是对方页面改版后链接被移入需要登录才可见的区域，还可能是己方抓取时被临时拦截。报告要能区分这些情况，而不是只写一句“链接失效”。
实施阶段：报告必须包含的六类证据
第一类是存在性证据。展示对方页面URL、抓取时间、HTTP状态码，以及在该页面HTML中检索到的己方链接代码片段。只截图页面可见文字不够，因为链接可能由脚本渲染，也可能在源码中但不可见。
第二类是可达性证据。记录从对方页面到己方目标页面的完整跳转链，包括每一跳的状态码。如果对方链接经过302跳转、短链或中间页，要标出最终落点。最终落点与预期目标不一致时，应作为独立问题列出。
第三类是属性证据。展示链接标签的原始HTML，重点看 rel 属性与 target 属性。属性变化会直接影响链接的处理方式，因此报告应保留修改前后的对照，而不是只写“属性异常”。
第四类是页面状态证据。对方链接所在页面本身是否可访问、是否被 robots 规则限制、是否返回软404或登录墙。这些信息决定链接是否还有实际意义。若页面已无法公开访问，链接存在与否的结论要单独说明。
第五类是时间线证据。同一组链接在不同时间点的检测结果应并列展示，形成变化记录。没有时间线的报告只能说明某一时刻的状态，无法判断是长期问题还是临时波动。
第六类是抽样与覆盖说明。如果检测了大量链接，报告要写清是全量检测还是抽样检测、抽样规则是什么。抽样结论不能直接当成全量结论使用。
验证阶段：两种处理方案的比较依据
面对异常链接，常见两种处理方案：一是先联系对方修复，二是直接从己方链接列表中移除或替换。比较时看四个条件：
- 对方页面是否仍有公开访问价值。若页面已无法访问或长期不更新，修复的优先级较低。
- 异常是单次抓取波动还是持续存在。连续多次检测结果一致，才适合作为处理依据。
- 链接属性是否被单方面改为
nofollow等。若对方明确调整了属性，修复沟通的成功率通常低于直接替换。 - 己方是否还有同等或更合适的替换对象。替换成本低于沟通成本时，移除方案更易执行。
报告在这一步要给出判断结果，而不只是罗列数据。例如：某链接连续三次检测均返回404，且对方页面无公开内容，则建议移除；某链接仅一次检测失败，第二次恢复正常，则建议保留并继续观察。适用条件要写清楚，避免把个别情况推广成通用规则。
维护阶段：让报告可复查、可交接
检测报告要能被下一次检测直接复用。建议固定字段名称与记录格式，保存原始抓取结果或页面快照的哈希值，避免后续无法确认当时看到的内容。每次复查时，先核对上次报告中的异常项，再补充新增链接。这样报告才是一份连续记录，而不是一次性截图集合。
最关键的一步是保留原始证据而不是只保留结论。结论会随判断标准变化，原始URL、时间、状态码和HTML片段不会。需要开始整理时，先为每条链接建立一行记录，包含对方页面URL、己方目标URL、检测时间、状态码、链接属性，再在此基础上写判断。
