死链检测方法检查前需要准备哪些信息：先定范围与判定口径
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4f1721cda316.html
📄
死链检测方法检查前需要准备哪些信息：先定范围与判定口径
用死链检测方法查站内链接之前，需要先准备四类信息：待检测的URL范围、判定为死链的状态口径、可用的抓取与日志数据、以及后续处理方案的选择条件。准备得越具体，检测结果越能直接用于修复或移除，而不是得到一堆无法判断的报错。
先明确要检测哪些URL
检测范围决定了工具配置和工作量。至少要区分以下来源，并分别记录数量：
- XML站点地图中列出的页面URL；站点地图不保证收录，它只代表你希望被发现的地址，因此不能把站点地图当作完整清单。
- 站内导航、栏目页、文章正文中出现的内部链接目标。
- 外部来源指向本站的URL，例如合作方页面、历史投放落地页、旧版页面地址。
- 已经下线的页面、改版前的旧路径、带参数的动态地址。
把这些URL整理成一份可导入的列表，每行一个完整地址，包含协议与主机名。若数量很大，先按目录或栏目分组，便于分批检测和分批修复。
确定死链的判定口径
“死链”不是单一状态码，检查前要约定哪些结果算问题。常见判定如下：
- 返回404或410：目标资源不存在，通常按死链处理。
- 返回301或302：属于跳转，不算死链，但要检查跳转链是否过长、是否跳到无关页面。
- 返回403或401：可能是权限限制，不一定是死链；需要区分是服务器主动拒绝还是资源确实不存在。
- 返回5xx：属于服务端错误，可能是暂时故障，也可能是持续不可用；应重复检测确认，而不是一次报错就删链接。
- 连接超时或DNS解析失败：可能是网络、防火墙或域名配置问题，需要单独归类。
把判定规则写下来，例如“连续两次检测均返回404或410，且非robots.txt主动限制，记为待处理死链”。这样不同批次、不同人执行时结果才可比较。
准备抓取、日志与索引数据
仅靠站内爬取可能漏掉外部入口和用户实际访问的路径，建议同时准备：
- 服务器访问日志：用来找出实际被请求但返回错误状态的URL，尤其是没有被站内链接指向的地址。
- 搜索引擎抓取相关数据：在对应搜索引擎的站长平台中查看抓取错误与索引状态，不同搜索引擎支持情况须分别核查，不能互相替代。
- 当前可访问的页面清单：作为对照，避免把正常页面误判为死链。
如果站点使用robots.txt限制抓取，要注意：robots.txt的抓取限制不等于可靠的索引移除。被robots.txt屏蔽的URL可能仍出现在索引中，检测时也不能简单把它当作死链。
假设例子：两种处理方案的比较条件
假设某站点改版后，旧栏目 /old-guide/ 下的页面全部返回404，站内还有若干文章链向这些旧地址。现在有两种处理方案：
- 方案A：把旧地址301跳转到最相关的新页面。
- 方案B：直接保留404，并移除站内指向旧地址的链接。
选择条件可以这样判断：如果旧地址仍有外部链接或用户访问，且新页面与原内容主题一致，方案A更合适；如果旧内容已彻底取消、没有对应替代页面，方案B更合适。执行前先确认跳转目标返回200，且不是跳转到首页或无关栏目。常见错误是把所有旧地址统一跳到首页，这会让用户和搜索引擎无法判断对应关系；另一个错误是只删站内链接，却忽略外部仍然指向404地址。
检测步骤可以按这个顺序执行：先导出待检测URL列表，再用爬虫或日志筛出非200状态，接着按上面的口径分类，最后对每一类决定跳转、修复还是移除。每一步都保留原始地址和检测时间，便于复查。
检查项与下一步
开始检测前，逐项核对：URL清单是否去重并包含协议；判定规则是否写明状态码与重复检测次数；日志与站长平台数据是否已分别导出；robots.txt是否误挡了需要检测的路径；跳转目标是否已确认可访问。准备完成后，先在一个小目录上试跑，确认分类结果符合预期，再扩大到全站。下一步是选定一种处理方案，对第一批确认的死链执行修复或跳转，并在完成后重新检测同一批URL，确认状态已改变。
