死链检查方法 - 用分层判断减少协作返工
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c7966c559fdb.html
📄
死链检查方法 - 用分层判断减少协作返工
判断死链问题属于哪一层，核心是看“谁在什么条件下发现了什么”。如果只在浏览器里看到404，问题可能在外链、站内链接、页面文件、服务器配置或抓取规则中的任意一层。分层的目的不是分类好看，而是让处理人、修复动作和复查方式都能被明确交付。
第一层观察：先确认现象来自哪里
收到“有死链”的反馈时，先记录四个信息：发现入口、请求地址、HTTP状态码、是否带参数。发现入口决定后续判断方向：
- 从外部搜索结果点进来失败，偏向外链或历史URL层。
- 从站内导航或文章正文点击失败，偏向站内链接层。
- 直接输入地址失败，偏向页面文件或服务器配置层。
- 工具批量报告失败，需先排除抓取规则、超时和权限干扰。
如果同一个URL在浏览器返回404，在抓取工具里返回403，这不是同一个问题。403可能来自robots.txt限制、防火墙或访问频率控制，不能直接当成死链处理。这里要区分“可能原因”和“已经定位的原因”：看到403只能说明请求被拒，不能断言一定是robots规则导致。
第二层判断：把请求链路拆成四段
一条链接从点击到返回结果，至少经过四段：来源页面、目标地址、服务器响应、抓取与索引规则。分层判断可以按下面顺序执行：
- 查来源：在来源页面找到链接文本，确认它指向的完整URL，包括协议、域名、路径和参数。
- 查目标：直接请求该URL，记录状态码和最终跳转地址。若发生多次跳转，逐跳记录。
- 查服务器：确认目标文件是否存在、重写规则是否命中、大小写是否一致。
- 查规则：检查
robots.txt是否禁止抓取该路径，以及站点地图是否仍包含已失效地址。
判断结果可以这样用：来源页面链接写错，属于站内链接层，交给内容编辑改；目标文件被删除且无替代页，属于页面文件层，交给开发或运维决定恢复、重定向或保留404；服务器返回500，属于服务端层，先修服务再谈链接；抓取工具报告异常但浏览器正常，属于抓取规则或工具配置层，先复核再派单。
第三层处理：按层分配动作和交付物
多人协作时，最容易返工的情况是把所有404都交给同一个人。更稳妥的做法是按层分配：
- 站内链接层：交付修改后的页面地址、原链接文本、新目标URL。适用条件是目标页仍存在，只是链接写错。
- 页面文件层：交付目标URL、当前状态码、替代页或重定向目标。适用条件是旧页面已下线且有对应新页。
- 服务端层：交付请求时间、状态码、服务器日志片段。适用条件是同一路径间歇性失败或返回5xx。
- 抓取规则层：交付规则文件路径、被限制的URL、复核后的可访问结果。适用条件是浏览器可访问但工具被拒。
假设一个例子：某文章页里的“下载说明”链接返回404。直接请求目标URL也返回404，服务器上对应文件已被删除，但站内另有一篇同主题说明页。这个例子属于页面文件层，不是站内链接层。处理动作应是把旧地址301到新说明页，或把来源链接改为新地址，而不是只改来源页文字。若只改来源页而不处理旧地址，外部仍可能继续请求旧地址并失败。
第四层复查：确认修复没有制造新问题
修复后不要只看来源页面能否点击。复查至少包含三项：
- 原失效URL现在返回什么状态码，是否符合预期。
- 重定向链是否只有一跳，是否指向可访问的最终页。
- 站点地图和站内搜索是否还包含旧地址，避免继续暴露失效入口。
需要分清边界：robots.txt的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS不保证安全无漏洞或排名。复查时只核对与本次死链直接相关的项，不把收录、排名或安全承诺混进交付结论。
下一步可以直接做一张分层记录表，字段包括：发现入口、原URL、状态码、判断层级、处理人、修复动作、复查结果。每次死链反馈先填前四项，再决定派给谁，这样能减少“改完仍失败”的返工。
