测试死链接，移动端与桌面端怎样检查差异

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

测试死链接，移动端与桌面端怎样检查差异

移动端与桌面端检查死链接的差异，核心不在链接本身是否有效，而在两端触发的链接集合、跳转路径和检测环境不同。同一个 URL 在桌面端返回 200，在移动端可能因重定向到失效的移动页、被 robots.txt 限制或依赖触摸事件才暴露而变成死链。因此正确做法是：两端分别抓取链接清单，再对差异项单独验证，而不是用一次桌面扫描的结果推断移动端。

为什么同一批链接在两端结果不同

常见原因可以分成三类，需要区分“可能原因”和“已经定位的原因”，不要看到差异就断言是某一项造成的。

重定向链不同：桌面访问 /page 正常，移动端可能被 302 到 /m/page，而后者已删除。此时死链出现在移动端，桌面端扫描不到。
抓取规则不同：部分站点对移动 UA 返回不同内容或状态码。如果 robots.txt 对移动 UA 有额外限制，爬虫可能根本不请求该链接。注意 robots.txt 的抓取限制不等于可靠的索引移除，它只影响抓取，不代表页面已被移除或不会被以其他方式收录。
交互触发不同：移动端导航常折叠在汉堡菜单里，桌面端悬停才显示的链接在触摸设备上可能无法触发。这类链接在静态 HTML 抓取中可能两端都抓不到，需要模拟交互才能发现。

移动端检查的具体做法

移动端检查要覆盖静态链接和交互后链接两部分。

用移动 User-Agent 抓取页面，保存所有 <a href> 及 <link>、<script src> 等资源地址。可执行命令示例：curl -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -s https://example.com/page | grep -o 'href="[^"]*"'。这只能拿到初始 HTML 中的链接。
在移动视口（如 375×812）下用浏览器开发者工具或自动化脚本展开菜单、点击标签页、滚动懒加载区域，记录新出现的请求。
对收集到的每个 URL 发请求，记录状态码、重定向链和最终 URL。状态码为 4xx、5xx，或重定向终点为 4xx/5xx，都算死链。

适用条件：站点有独立的移动模板或服务端按 UA 分流时，必须做这一步。如果站点是响应式设计且两端 DOM 完全一致，差异通常只来自交互触发，静态抓取结果可复用。

桌面端检查的具体做法

桌面端检查相对直接，但要注意两点：一是 JavaScript 渲染后才插入的链接，纯 HTML 抓取拿不到；二是悬停菜单、下拉框里的链接需要模拟 hover 才会出现在 DOM 中。

静态抓取：适合服务端渲染的页面，速度快，能覆盖大部分正文链接。
渲染后抓取：用无头浏览器等待网络空闲后再提取链接，能覆盖前端框架生成的导航和卡片。
交互抓取：对悬停菜单、折叠面板执行 hover 或 click，再提取链接。

判断结果时，把桌面端和移动端的链接清单做差集：只在移动端出现的、只在桌面端出现的、两端都有但状态码不同的。这三类就是需要人工复核的差异项。

两端差异的验收信号

完成一轮检查后，用以下信号判断是否收敛：

两端链接清单的差集已逐条确认，每条差异都能说明是重定向、UA 分流还是交互触发造成的。
所有 4xx/5xx 链接已记录来源页面和触发条件（静态、点击、滚动）。
重定向链长度和终点已核对，没有指向已删除的移动页。
修复后重新跑一遍两端抓取，差异项状态码变为 2xx 或 3xx 且终点有效。

如果差异项数量很大，优先处理出现在导航、页脚、商品卡片等高频区域的链接，这些位置的死链对用户和抓取的影响更直接。

下一步

先选一个移动端和桌面端表现可能不同的页面（例如带独立移动模板的详情页），按上面的方法各跑一次链接提取，把两份清单做差集。差集结果会直接告诉你需要重点验证的是重定向规则、UA 分流还是交互脚本。