死链检测方法：移动端与桌面端怎样检查差异
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9c6a88aa6865.html
📄
死链检测方法：移动端与桌面端怎样检查差异
移动端与桌面端检查死链的核心差异在于：同一链接可能因为页面渲染方式、跳转逻辑或抓取工具设置不同，在一端返回正常状态，在另一端却暴露为死链。因此不能只依赖桌面端结果，而应分别用移动端视角和桌面端视角采集链接，再对比状态码、最终地址和页面内容，找出只在某一端失效的链接。
先观察：两端链接列表为什么可能不同
桌面端页面常把导航、相关推荐和页脚链接一次性输出在 HTML 中；移动端可能采用折叠菜单、懒加载或动态渲染，链接在初始 HTML 里并不完整。此时用同一份链接清单去测，会漏掉只在移动端出现的入口。判断方法很直接：分别保存两端渲染后的 HTML，搜索 <a> 标签的 href，对比链接集合。若移动端链接数量明显偏少，说明需要先解决采集完整性问题，而不是急着判定死链。
判断：状态码、跳转和内容三层对比
拿到两份链接清单后，逐条请求并记录三项信息：HTTP 状态码、重定向链的最终 URL、最终页面是否包含有效内容。常见差异及解释如下：
- 桌面端返回 200，移动端返回 404：可能是移动端专用路径、User-Agent 分流或 CDN 规则导致，属于已经定位到请求差异，需要分别核对服务器配置。
- 两端状态码相同但最终地址不同：可能是重定向规则按设备区分，要检查目标页面是否都有效。
- 状态码为 200 但页面为空或提示错误：属于软 404，不能只看状态码，要检查标题和正文关键内容是否存在。
- 一端超时、另一端正常：可能是网络、DNS 或防护策略差异，需要重复测试并记录发生条件，不要直接断定为死链。
可以用命令行分别模拟两种客户端请求，例如：
curl -I -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" https://example.com/page
再换成桌面端 User-Agent 执行一次，对比返回的 Location 和状态码。假设某页面在桌面请求返回 301 并最终到达有效页，而移动请求返回 404，这就说明差异发生在服务端分流环节，应优先检查移动端规则，而不是修改页面上的链接文字。
处理：按差异类型分别修复
如果链接只在移动端缺失，优先修正渲染或菜单输出逻辑，确保链接真实存在于可抓取的 HTML 中。如果链接在两端都失效，统一更新为目标地址或移除入口。如果重定向链在某一端循环或指向失效页，应简化跳转规则，让两端落到同一有效目标。修复时不要用 robots.txt 屏蔽失效路径来代替处理，抓取限制不等于可靠的索引移除，也不能解决用户点击后看到错误页的问题。
复查：用同一份清单验证两端结果
修复后重新采集两端链接，生成对比表，至少包含：来源页面、链接地址、桌面状态码、移动状态码、最终 URL、复查日期。复查时确认三点：原先失效的链接在两端都返回有效内容；新出现的链接已纳入清单；重定向不再指向新的失效地址。站点地图可以作为发现链接的辅助来源，但不保证收录，也不能替代实际请求验证。若站点使用 HTTPS，也不要因为协议是 HTTPS 就跳过状态码和内容检查，HTTPS 不保证页面本身有效。
下一步：选取站点中访问量最高的若干入口页，分别用移动端和桌面端各跑一遍链接采集与状态检查，把两端结果不一致的链接单独列出，按上面的差异类型逐条处理并记录复查结果。
