网站死链检测检查前需要准备哪些信息：两种处理方案怎么选
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /624f31ab86b0.html
📄
网站死链检测检查前需要准备哪些信息：两种处理方案怎么选
做网站死链检测前，先准备四类信息：检测范围（域名、目录或URL清单）、期望输出的链接状态与来源页、可接受的误报与漏报标准、以及处理后由谁改、何时改。缺少这些信息，检测结果往往只能得到一堆无法直接处理的链接列表。
先明确检测范围，决定用爬取还是清单核对
范围不同，准备方式也不同。若目标是整站排查，需要准备起始URL、允许抓取的目录、需要排除的后台或参数页，以及站点是否依赖登录。若只检查已知链接，例如迁移后的一批旧地址，可以直接准备URL清单，逐条请求并记录状态码与最终跳转地址。
判断条件：站点结构清晰、页面可公开访问时，整站爬取更省事；页面需要登录、参数组合极多或只关心少量旧链接时，清单核对更可控。两种方案没有绝对优劣，关键看覆盖范围和执行代价。
准备链接状态与来源页信息，避免只拿到死链地址
一条死链如果只记录目标地址，修复时还要反查它出现在哪些页面。因此检测前应约定输出字段：目标URL、HTTP状态码、最终跳转URL、来源页URL、锚文本、发现时间。来源页决定了修改位置，锚文本则帮助判断这条链接是否值得保留。
检查项可以按下面清单准备：
- 目标URL是否返回404、410、5xx或超时。
- 是否经过301、302跳转，最终落地页是否与预期一致。
- 来源页是否可编辑，还是由模板、导航或外部站点生成。
- 链接是站内互链、站点地图中的地址，还是外部反向链接。
如果来源页在CMS模板中统一输出，改一个模板可能影响大量页面；如果来源页是编辑内容，则要逐条处理。这个区别直接决定后续工作量。
两种处理方案：直接修复还是重定向，先比较代价
检测出死链后，常见处理是修复原链接或设置重定向。修复适合来源页仍可编辑、目标内容已迁移到新地址且能确定对应关系的情况；重定向适合旧地址仍有外部访问、来源页无法逐一修改，或同一旧地址被多个页面引用的情况。
比较依据可以看三点：
- 访问需求：旧地址是否还有用户或外部链接进入。没有访问价值的失效页，可以直接返回404或410，不必强行重定向。
- 对应关系：新地址是否与旧内容主题一致。把不相关页面重定向到首页，可能让访问者困惑，也不利于判断。
- 维护成本：重定向规则集中管理，适合批量旧地址；逐条修复链接更直接，适合来源页少、内容仍可编辑的情况。
假设一个旧产品页已经下线，且没有同类替代页，把它重定向到首页并不是理想选择；此时保留404并清理站内入口更合适。反过来，如果旧地址仍出现在外部链接中，且已有对应新产品页，设置301到该产品页更合理。
检测前还要确认工具边界与robots.txt、站点地图的关系
准备信息时，不要把robots.txt的抓取限制当成索引移除手段，也不要以为站点地图能保证收录。检测工具能否抓到某个目录，取决于它是否遵守robots.txt以及页面是否需要登录。若检测范围包含被robots.txt禁止抓取的路径，结果可能不完整，需要单独用清单核对。
另外，HTTPS并不保证页面没有漏洞，也不直接保证排名。它只说明传输层加密，与死链检测的目标无关。检测时真正要记录的是链接可达性和状态码，而不是把安全、收录、排名混进同一份清单。
如果使用命令行核对，可以写成类似 curl -I https://example.com/old-page 的请求，观察返回的状态码和Location头。这里的 example.com 只是示例地址，实际检测时替换为待查URL。若返回301或302，继续请求最终地址，确认落地页是否有效。
选择步骤：先定范围，再定处理规则，最后分配执行人
可以按以下顺序推进：
- 列出检测范围：整站、目录或URL清单，并写明排除项。
- 确定输出字段：状态码、来源页、最终跳转地址、锚文本。
- 设定处理规则：哪些状态码必须修，哪些可以重定向，哪些保留404。
- 确认执行人与时间：模板问题交给开发，内容链接交给编辑，外部链接单独记录。
- 检测后抽样复核：随机打开若干来源页，确认链接确实存在且状态可复现。
适用条件：范围小、来源页少时，可以直接修复；范围大、旧地址多且仍有访问需求时，优先集中管理重定向。判断结果是否可用，不看死链数量多少，而看每条记录是否能对应到具体来源页和明确处理动作。
下一步，先选一个目录或一批旧URL做小范围试跑，确认输出字段和处理规则能覆盖实际修改需求，再扩大到整站。
