死链检查：正常与异常结果怎样区分？先看状态码再定处理动作
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /92c09a3027e0.html
📄
死链检查：正常与异常结果怎样区分？先看状态码再定处理动作
死链检查的正常与异常，核心看两件事：请求是否真的失败，以及失败是否稳定复现。一个链接返回 404、410、5xx 或连接超时，属于需要处理的异常；返回 200、301、302 且最终落到有效页面，通常算正常。但 200 不一定代表内容正确，301 也不一定代表目标页合适，所以还要核对最终地址和页面内容。多人协作时，把“检测结果”和“处理结论”分成两列记录，能明显减少返工。
用一个假设例子走完区分流程
假设你负责一个内容站，抓取工具报告了三条记录：A 返回 200，B 返回 301，C 返回 404。先不要急着把三条都标成“异常”。
- 对 A 打开最终页面，确认标题、正文和链接锚文本说的是同一件事。若内容一致，判为正常；若页面变成无关首页或错误提示，判为异常。
- 对 B 记录 301 的最终地址。若最终地址可访问且内容对应，判为正常跳转；若跳转链超过一跳、最终地址仍是错误页，或跳向无关栏目，判为异常。
- 对 C 先复测一次，排除偶发网络问题。仍返回 404 或 410，判为确定死链；返回 5xx 则先判为服务端异常，交给技术侧排查，不要直接删链接。
这个流程的关键是：状态码只给初步分类，最终地址和页面内容才给处理结论。只抄状态码就交付，是多人协作里最常见的返工来源。
正常结果的判断标准
正常结果不只是一句“能打开”。可以按下面几项核对：
- 请求返回 200，且最终 URL 与待检查 URL 一致，或经过合理跳转后落到对应内容。
- 页面主体内容与链接所在位置的上下文相关，不是空页、登录墙或统一错误页。
- 同一链接在不同时间、不同网络环境下复测结果一致，没有时好时坏。
- 若是 301 或 302，跳转目标明确，且没有形成循环跳转或过长跳转链。
满足这些条件，才适合在交付表里写“正常，无需处理”。如果只是“浏览器能打开”，但最终地址已经变了，仍要单独标注，避免后续更新内链时漏掉。
异常结果的分类与对应动作
异常结果至少分成四类，处理动作不同：
- 404 / 410：确定死链。检查是否有替代页面，有则改为指向替代页；没有则移除链接或保留说明。
- 5xx：服务端或网关异常，可能是临时故障。先复测，再交给技术侧；不要凭一次结果删链接。
- 连接超时、DNS 失败：可能是网络、域名解析或目标站下线。换网络复测，并记录复测时间。
- 跳转到无关页：状态码可能是 200 或 301，但内容不匹配，仍按异常处理，改为正确目标或移除。
需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。检查工具报告“被阻止”时，先确认是抓取限制还是链接本身失效，再决定动作。
多人协作时的交付检查项
要让结果清楚、减少返工，交付表建议包含这些字段：待检查 URL、首次状态码、复测状态码、最终 URL、页面内容是否匹配、判定结果、处理动作、复测人、复测时间。判定结果只允许填“正常”“确定死链”“服务端异常”“跳转异常”“待复测”几种，避免各人用词不同。
常见错误有三种：把 301 一律当异常；把一次 5xx 当成确定死链；只记录状态码不记录最终地址。前两种会造成误删，第三种会让接手的人重新查一遍。若涉及具体品牌或机构页面，还要单独核对页面归属和联系方式是否仍有效，不能只看状态码。
下一步怎么做
先拿一批已抓取结果，按上面的字段补全“最终 URL”和“复测状态码”，再把判定结果统一成固定选项。完成一轮后，把仍为“待复测”的记录单独列出，安排第二次复测，而不是直接并入处理清单。
