📍 WDQWDWQD987AAAAA:216.73.217.37
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c169528c5c45.html
📄

网站死链查询，怎样检查前后环节的依赖

网站死链查询不能只看“链接返回404”这一条结果，而要检查死链前后的依赖链：链接从哪个页面产生、指向哪个URL、该URL是否被重定向、重定向终点是否有效、服务器是否因权限或规则拦截。最关键的一步是把每个死链还原成“来源页→链接→目标URL→最终响应”的完整链路，再逐段判断哪一环失效。

准备：先分清死链的三种来源

开始查询前，先给疑似死链分类，否则后续检查容易混在一起：

• 站内死链：自己页面上的链接指向了不存在的站内URL，常见于栏目改版、文章删除、URL规则调整。
• 外链失效：其他网站指向你的URL已经不存在，这属于外部引用问题，不在你页面HTML里。
• 资源死链：图片、CSS、JS、字体等资源路径失效，页面可能仍能打开，但样式或功能异常。

准备阶段要收集三类证据：一份待检查URL清单、一份页面HTML中提取出的链接清单、一份服务器访问日志或状态码记录。没有这三类材料，后面的“前后环节”就无从对照。

实施：沿链路逐段检查依赖

对每个疑似死链，按以下顺序检查，不要跳步：

1. 检查来源页是否还存在：如果来源页本身已删除或已改URL，那么它上面的链接自然失去意义。先确认来源页返回200，再谈链接问题。
2. 检查链接是否真的写在HTML里：用浏览器查看源代码或抓取工具提取href，确认链接不是由JavaScript动态生成、不是被注释掉、不是只在特定登录状态下出现。
3. 检查目标URL的响应状态：用HTTP状态码工具请求该URL，记录返回的是404、410、301、302、403还是500。不同状态码指向不同环节的问题。
4. 检查重定向链：如果返回301或302，继续跟踪Location头，直到最终URL。常见问题是重定向到另一个同样失效的地址，形成死链链。
5. 检查服务器与规则层：如果状态码是403或500，问题可能不在链接本身，而在权限配置、防火墙、伪静态规则或后端程序。此时要查看服务器错误日志，而不是继续改链接。

例如，假设某页面链接/old-page返回301，跳转到/new-page，而/new-page返回404。这里的依赖关系是：来源页有效，链接有效，重定向规则有效，但重定向终点失效。修复对象是/new-page或重定向目标，而不是来源页上的链接文本。

验证：用对照法确认修复真的生效

修复后不能只看单个URL是否返回200，要验证整条链路：

• 来源页重新抓取，确认链接指向的仍是修复后的目标。
• 目标URL直接请求，确认返回200且内容与预期一致。
• 如果存在重定向，确认重定向终点返回200，且没有多余跳转。
• 检查该URL是否被robots.txt限制抓取。robots.txt的抓取限制不等于可靠的索引移除，它只约束爬虫行为，不能替代404或410处理。
• 检查站点地图中是否仍包含已失效URL。站点地图不保证收录，但包含死链会浪费抓取预算并干扰后续核查。

验证时建议保留修复前后的状态码记录。判断结果是：如果来源页、链接、目标URL、重定向终点四段都返回预期状态，才算这条依赖链修复完成；只要有一段仍异常，就继续定位该段。

维护：把死链检查变成可重复的环节

死链会随内容更新持续产生，维护重点是让检查可重复：

• 定期从站点地图、导航、文章正文和资源文件中提取链接，形成检查清单。
• 把状态码异常按404、410、301链、403、500分组，分别对应内容删除、重定向配置、权限规则和程序错误。
• 对确认不再需要的URL返回410，对已迁移URL配置指向有效终点的301，避免重定向到无效地址。
• 记录每次修复的来源页、目标URL、状态码变化和修复时间，便于下次对照。

如果站点使用HTTPS，也要注意HTTPS不保证安全无漏洞或排名，它只解决传输加密问题，不能替代对死链本身的状态码检查。不同搜索引擎对410和301的处理节奏可能不同，需要分别核查，不能假设一处修复会立刻在所有搜索场景中同步生效。

下一步：从当前访问日志或抓取结果中挑出10个疑似死链，按“来源页→链接→目标URL→最终响应”画成四列表格，先定位断在哪一段，再决定改链接、改重定向还是改服务器规则。