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

死链检测_移动端与桌面端怎样检查差异

移动端与桌面端的死链差异，主要来自三处：页面给两端返回的HTML不同、链接由脚本在特定视口或触摸环境下才注入、以及重定向或拦截规则按User-Agent区分。因此不能只用桌面爬虫扫一遍就当作结论。时间人手有限时，先做“同一URL双端抓取对比”，再针对差异条目做点击验证，优先处理移动端返回404/410而桌面端正常的链接，因为移动优先索引下这类问题影响面更大。

先判断你的站点是否可能出现双端差异

不是所有站点都需要双端分别检测。满足以下任一条件时，差异检查才有必要：

• 使用响应式设计但通过CSS或JS在移动端隐藏了部分导航、页脚或推荐位链接。
• 存在独立的移动域名或移动路径，例如 m.example.com 与主域各自维护。
• 页面依赖JavaScript渲染，且脚本根据屏幕宽度或触摸能力决定是否输出链接。
• 服务器或CDN按User-Agent做重定向、跳转或屏蔽。

如果站点是纯静态、两端输出完全一致的HTML，且链接都在服务端渲染，那么一次桌面抓取基本可以覆盖，把精力放到别处更划算。

用同一批URL做双端抓取对比

核心做法是固定URL清单，只改变请求身份，比较返回结果。可执行步骤如下：

1. 从站点地图、内链或日志中整理一份待测URL清单，先取主要栏目和流量靠前的页面，不必一次全站。
2. 用桌面User-Agent抓取一遍，记录每个URL的状态码和最终跳转地址。
3. 用常见移动User-Agent（如iPhone、Android各取一个）再抓一遍，记录同样的字段。
4. 把两份结果按URL对齐，标出状态码不同、最终地址不同、或一端完全取不到内容的条目。

命令行工具可以用 curl 指定请求头，例如：

curl -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -I -L https://example.com/page

其中 -I 只看响应头，-L 跟随跳转。把 -A 换成桌面User-Agent再跑一次，对比两次的状态码与 Location。这只是假设示例，实际域名和UA字符串请替换成你要测的目标。

差异条目要分清“返回错误”和“链接不存在”

抓取对比会得到两类不同问题，处理方式不一样：

• 状态码差异：桌面返回200，移动返回404或410。这通常是服务端按UA分流配置出错，属于必须优先修的技术问题。
• 链接集合差异：两端都能打开，但移动端HTML里少了某些 <a> 链接，或多了桌面端没有的链接。需要判断是设计上有意隐藏，还是渲染逻辑漏掉了。

注意，抓取工具看到的HTML不等于用户看到的页面。如果链接是滚动或点击后才由脚本插入，纯抓取可能两端都取不到，这时要改用能执行JavaScript的渲染方式，或直接在真机/模拟器上手动核对。

移动端优先处理顺序与验收信号

时间和人手有限时，按这个顺序安排：

1. 先修移动端404/410而桌面端正常的URL，这类是明确的死链。
2. 再查移动端缺失的重要导航和转化路径链接，例如加入购物车、联系入口。
3. 最后处理仅在移动端多出的无效链接，优先级相对低。

验收信号可以这样定：同一批URL在桌面与移动两种User-Agent下，状态码一致；移动端关键导航链接可点击且能到达有效页面；修复后重新跑一次双端对比，差异条目数量下降。不要用“抓取一次没报错”当作通过，要确认对比清单里的差异项确实被消除。

容易误判的几种情况

双端结果不同，不一定都是死链：

• 移动端被重定向到精简版页面，原URL仍有效，只是最终地址变了，这不算死链，但要确认跳转目标可访问。
• 页面因登录态或地区限制返回403，与链接本身是否失效无关，需单独核对权限规则。
• 抓取超时或限速导致一端失败，属于请求环境问题，应重试后再判断。

另外要区分：robots.txt 的抓取限制不等于可靠的索引移除；站点地图不保证收录。这些规则影响的是抓取与索引，不能替代对链接本身是否可访问的检查。

下一步：挑10个主要栏目页，用桌面和移动两个User-Agent各抓一次，把状态码不同的URL列成一张表，先修移动端报错的那几条。