死链检测工具，检查前需要准备哪些信息
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7f9ca7904d44.html
📄
死链检测工具，检查前需要准备哪些信息
在打开死链检测工具之前，最需要准备的是三样东西：一份明确的待检网址清单、一份允许抓取范围的规则说明，以及一个可对照的历史链接来源。缺少这些信息，工具跑出来的结果往往是一堆无法判断优先级的报错，反而增加筛选成本。
先划定检测范围，而不是直接全站开跑
死链检测的输入决定了输出的可用性。全站抓取听起来省事，但对时间和人手有限的团队来说，真正需要先处理的是那些有外部入口、有用户点击、有转化价值的页面。
- 入口清单：首页、栏目页、主要着陆页的URL，这些页面上的链接一旦失效，影响面最大。
- 链接来源：站内导航、内容正文、页脚、站点地图、外部合作方引用的地址，来源不同，修复优先级不同。
- 排除项：后台地址、测试环境、参数化筛选页、需要登录才能访问的路径，这些不应进入公开检测范围。
假设一个只有两人的内容团队，站点约三百个页面，其中真正带来访问的是二十个栏目页和八十篇旧文章。此时合理的做法不是全站扫描，而是先导出这100个URL，再让工具顺着页面内的链接向下抓一层。这样得到的死链基本集中在用户真实会走的路径上。
准备 robots.txt 与抓取限制的说明
检测工具通常遵循 robots.txt 的抓取规则。如果 robots.txt 里屏蔽了某些目录，工具就不会去访问，那些目录里的死链也不会出现在报告里。这不代表问题不存在，只代表本次检测没有覆盖。
需要提前确认的是：
- robots.txt 中是否有
Disallow规则挡住了需要检测的路径。 - 是否存在抓取频率限制，是否需要给工具设置更低的并发数，避免给服务器造成压力。
- 是否有防火墙或访问控制会拦截检测工具的请求，导致误报为死链。
这里有一个常见错误：把 robots.txt 的抓取限制当成索引移除手段。它只约束爬虫抓取行为，不能可靠地把已收录页面从搜索结果中移除。检测时如果发现某类页面被 robots.txt 屏蔽，应单独记录，而不是直接判定为死链。
整理一份可对照的链接来源表
工具报告里的每一条失效链接，最好都能回答“它从哪里来”。准备一份来源表，至少包含：
- 链接出现的页面地址。
- 链接指向的目标地址。
- 该链接是站内还是站外。
- 该页面是否属于优先维护范围。
如果没有来源表，报告只能告诉你某个地址返回了404，却无法判断是该改链接、该做跳转，还是该直接删除。对于人手有限的团队，来源表能直接把修复工作分成“必须今天改”和“可以排期改”两类。
确认状态码的含义与判断条件
检测结果里的状态码需要结合上下文看，不能一律当成死链。
- 404：目标不存在。若该地址曾被外部引用或有过流量，通常需要处理；若只是测试残留，可直接清理。
- 410：明确表示资源已删除。与404类似，但语义更确定。
- 301/302：跳转。短链跳转正常，但跳转链过长或最终落到404，就属于需要修复的情况。
- 403/401：权限问题。可能只是检测工具被拦截，不一定是真实死链，需要人工复核。
- 超时：可能是服务器响应慢或网络波动，应重试后再判断，不要直接记为死链。
判断结果时，先看这个地址是否还有入口价值，再看它返回的状态是否稳定。同一个地址多次检测结果不一致，说明问题可能出在服务端稳定性，而不是链接本身。
按影响面排序，先处理入口页上的失效链接
时间和人手有限时，排序依据可以简单设为：入口页优先于深层页，有外部引用的优先于纯站内引用，正文链接优先于页脚和边栏。一个可执行的步骤是：
- 导出检测报告，按“来源页面”分组。
- 标出首页、栏目页、主要着陆页上的失效链接。
- 对这批链接逐一确认是改地址、加跳转还是删除。
- 处理完后再跑一次检测，确认修复生效。
这套顺序不保证覆盖所有问题，但能在有限时间内先消除对用户路径影响最大的部分。站点地图不保证收录，HTTPS 也不保证页面没有失效链接，检测和修复仍需按实际抓取结果来判断。
下一步可以直接从现有导航和栏目页导出URL清单，先跑一轮小范围检测，再根据报告里的来源分组决定修复顺序。
