📍 WDQWDWQD987AAAAA:216.73.216.212
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cc906b49cc6b.html
📄

死链接检测-怎样取得可复查的状态证据

要取得可复查的状态证据，核心是让每一次死链接检测都留下“时间、请求地址、响应状态、跳转链、判定依据”五类记录，并保证别人按同一份记录能复现同一结论。只截图“404页面”不算证据，因为无法确认请求的是哪个URL、是否经过跳转、当时返回的是404还是软404。可行做法是：用脚本或爬虫批量请求站内链接，把每个URL的最终状态码、重定向次数和最终落地地址写入CSV，再人工抽查争议项。

先明确什么算“死”，再谈证据

死链接检测的判定标准不同，证据形态也不同。常见三类需要分开记录：

• 硬404/410：服务器直接返回404或410状态码，证据就是响应头中的状态行。
• 软404：HTTP状态码为200，但页面内容是“找不到”提示。这类不能只看状态码，需要比对页面标题、正文特征或模板标记。
• 跳转失效：原URL返回301/302，但最终落地页又返回404，或跳转链超过合理长度。证据要包含完整跳转链，而不只是起点和终点。

把标准写进检测脚本或检查表，复查者才能判断某条记录为何被标为死链接。

可复查证据的最小字段

无论用哪种工具，导出的记录至少应包含以下字段，缺一项都会削弱可复查性：

1. checked_at：检测时间，精确到分钟，便于区分不同批次。
2. source_url：发现该链接的页面地址。
3. target_url：被检测的链接地址，保留原始大小写和查询参数。
4. status_code：首次响应状态码。
5. redirect_chain：按顺序记录每一次跳转的地址与状态码。
6. final_url与final_status：最终落地地址及其状态码。
7. verdict：判定结果，如“死链接”“疑似软404”“正常”。
8. evidence_note：判定理由，例如“最终状态410”“标题含‘页面不存在’”。

如果使用命令行工具，可把响应头原始内容一并存档。原始响应头比二次整理的表格更难被质疑，复查者可以直接看到HTTP/1.1 404 Not Found这类状态行。

一个可执行的最小流程

假设站点有约200个内部链接需要检查，时间和人手有限，可以按下面步骤执行：

1. 导出待检URL清单，去重后按栏目分组，优先检查导航、页脚和正文中引用次数多的链接。
2. 用脚本对每个URL发起请求，关闭自动跳转，逐跳记录状态码和Location头；对返回200的页面再抓取标题和正文前若干字符。
3. 把结果写入CSV，字段按上一节列出。对状态码为404、410或跳转链异常的记录单独标记。
4. 人工复核标记项：打开最终落地页，确认是否真的无内容；对软404，检查标题和正文特征是否与正常页面明显不同。
5. 把CSV、原始响应头存档和复核备注放在同一目录，文件名包含检测日期，例如deadlink-2025-06-01.csv。

复查者拿到这份目录后，可以重新请求同一批URL，对比状态码是否变化。如果状态码从404变为200，说明链接已被修复或内容已恢复；如果仍为404，则原判定成立。

安排最先处理的工作

时间和人手有限时，不要平均用力。按“影响面×可验证性”排序：

• 最先处理：导航、页脚、高流量文章中的死链接。这些位置被抓取和点击的概率高，且来源页面容易定位。
• 其次处理：跳转链最终失效的链接。它们表面可能仍返回301，但用户和爬虫最终到达404，证据链完整时修复方向明确。
• 最后处理：低流量页面中引用次数少的链接。可以批量记录，等有资源时再统一修复。

判断依据是：来源页面越重要、死链接被引用的次数越多，修复后能减少的无效请求就越多。这个排序不依赖任何排名承诺，只依赖可统计的引用次数和页面位置。

复查时容易出现的分歧与处理

同一现象可能有多种解释，记录时要避免断言唯一原因。例如某URL返回404，可能是页面已删除，也可能是服务器临时故障、权限配置变化或请求头被拦截。复查时应：

• 在不同时间重复请求，观察状态码是否稳定。
• 用不带Cookie和自定义请求头的普通请求再测一次，排除客户端因素。
• 检查robots.txt是否禁止抓取该路径。需要说明的是，robots.txt的抓取限制不等于可靠的索引移除，它只约束爬虫行为，不能作为“链接已死”的证据。
• 核对站点地图中的URL是否仍存在。站点地图不保证收录，但可以作为内容是否仍被维护的参考。

把这些可能原因写进备注，而不是只写“404，已死”，复查者才能区分“可能原因”和“已经定位的原因”。

下一步：选一个栏目，按上述字段导出一份检测记录，先对导航和页脚链接完成一轮检测与复核，把CSV和原始响应头存档，再根据引用次数决定修复顺序。