死链查询，检查前需要准备哪些信息
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b52af79d3579.html
📄
死链查询，检查前需要准备哪些信息
开始死链查询前，至少要先准备好站点范围、URL来源、HTTP状态码记录、robots.txt与站点地图现状，以及可复现的访问证据。缺少其中任何一项，后续都可能把“页面暂时打不开”误判成“死链”，或者把本来正常的跳转当成故障。
先确定查询范围：查哪些域名和目录
要查的是整站、某个子目录，还是某次改版涉及的旧路径？把主域名、子域名、协议（http 或 https）和目录层级写清楚。比如只查 https://example.com/blog/ 下的文章，就不要把商城、帮助中心混进来。范围越明确，后面拿到的状态码越容易判断归属。
准备URL来源清单：死链不会自己出现
死链查询的输入通常来自几类位置，逐项收集：
- 站点地图中的URL：能反映你希望被发现的页面，但不保证已被收录。
- 站内链接与导航：包括菜单、面包屑、正文内链、分页链接。
- 外部来源：其他站点指向你的链接、旧域名或旧路径的引用。
- 历史记录：改版前的路径表、重定向规则文件、CDN或服务器访问日志。
怎么查：从站点地图导出全部URL，再抓取站内链接形成一份完整清单。结果说明什么：如果某条URL只出现在外部来源、站内已经没有任何入口，它更可能是历史遗留地址，需要单独判断是否该保留重定向。
准备HTTP状态码与访问证据
死链的核心判断依据是服务器返回的状态码，而不是页面看起来是否正常。检查前先确认你能拿到：
- 目标URL返回的状态码，如 200、301、302、404、410、500。
- 是否发生跳转，跳转链有几跳，最终落到哪个URL。
- 访问时使用的User-Agent、请求时间和请求方式（GET或HEAD）。
怎么查：用命令行工具或在线状态检查工具请求目标URL，记录状态码和跳转链。结果说明什么：404 和 410 通常表示资源不存在，301 和 302 是跳转而非死链；如果返回 500，属于服务器错误，不能直接归为死链，要先排查服务端问题。同一现象可能有多个解释，比如页面打不开既可能是链接失效，也可能是服务器临时故障，需要结合请求时间和多次结果判断。
准备robots.txt与站点地图现状
检查前先保存当前的 robots.txt 和站点地图文件，确认它们是否允许抓取目标路径、是否列出了已失效的URL。怎么查：直接打开这两个文件，对照待查URL逐条比对。结果说明什么：robots.txt 的抓取限制不等于可靠的索引移除，被 robots.txt 屏蔽的URL仍可能出现在外部链接或搜索结果中；站点地图不保证收录，里面列出的URL也可能返回404。两者只能作为线索，不能替代状态码检查。
准备记录表格与判断标准
把上面收集到的信息整理成一张表，每行至少包含：URL、来源、状态码、跳转目标、检查时间、初步判断。判断标准可以这样定：
- 返回 404 或 410，且站内无有效入口——按死链处理。
- 返回 301 或 302，且最终页面正常——按跳转处理，检查是否该改成直接链接。
- 返回 200，但内容与预期不符——按内容错位处理，不是死链。
- 返回 5xx 或超时——先复测，排除服务器临时问题。
假设某篇文章旧地址返回 301 到新地址，这不算死链；如果旧地址返回 404 且没有任何跳转，才需要修复或补重定向。适用条件是你能稳定复现该状态码；如果多次请求结果不一致，应记录不同结果并继续观察，而不是直接下结论。
下一步：先小范围验证再全量执行
准备好上述信息后，先挑10到20条URL做一次小范围死链查询，核对状态码、跳转链和来源是否对得上。确认记录表能准确区分死链、跳转和服务器错误后，再扩展到全站。这样能避免一开始就拿到大量混杂结果，反而无法定位真正需要修复的链接。
