死链接检测 - 移动端与桌面端检查差异：交付前怎么比对
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5edf55471dd3.html
📄
死链接检测 - 移动端与桌面端检查差异：交付前怎么比对
移动端与桌面端的死链接检测结果不一致，通常不是“谁漏了”，而是两端抓到的链接集合不同。差异主要来自响应式隐藏、UA 分流、触控事件、懒加载和跳转链路。判断方法很简单：分别用移动 UA 和桌面 UA 抓取同一批 URL，把两端发现的链接做差集，再逐条确认差异是“真实存在的链接”还是“抓取方式造成的假差异”。
先分清三类差异来源
多人协作时最容易返工的地方，是把三种情况混在一起讨论。建议在交付文档里把差异分成三栏，分别记录现象、可能原因和已定位原因。
- 内容差异：同一页面在移动端少渲染了一段导航或页脚，链接自然少。常见于响应式布局用
display:none隐藏整块区域。 - 抓取差异：链接在 HTML 里存在，但移动端抓取工具没有触发滚动或点击，导致懒加载链接没被采集。
- 跳转差异：移动 UA 被重定向到
m.子域或独立移动路径，桌面端停留在原路径，两套页面各自维护链接，失效情况不同。
只有第三类属于“两端真的指向不同资源”，前两类更多是检测方法问题。判断依据是：查看页面原始 HTML 里是否存在该 <a> 标签。存在但没被抓到，是抓取差异；不存在，是内容差异。
移动端与桌面端的具体检查步骤
下面这套流程可以直接放进协作交付清单，每步都留下可核对的产物。
- 固定同一批入口 URL，不要一端用首页、另一端用栏目页，否则差集没有意义。
- 桌面端用常规桌面 UA 抓取，移动端用主流移动 UA 抓取。两端都记录：发现的链接、HTTP 状态码、最终跳转地址。
- 对两端结果按“最终跳转地址”归一化，而不是按原始链接。否则
http到https、带不带www的差异会污染结果。 - 做差集：只出现在桌面端、只出现在移动端、两端都有但状态码不同。第三类优先处理。
- 对每条差异链接，用浏览器手动切换设备模拟再点一次，确认是渲染问题还是真实失效。
这里要区分“可能原因”和“已经定位的原因”。例如移动端某链接返回 404，可能是移动路径本身失效，也可能是重定向规则把参数拼错。只有复现并看到最终 URL 后，才能写成已定位原因。
懒加载与触控链接怎么核对
移动端大量使用滚动加载和点击展开，直接抓 HTML 常常漏链接。核对时注意两点：
- 懒加载链接：检查原始 HTML 中是否已有
href。如果链接在滚动后才由脚本注入，抓取工具不执行脚本就会漏。此时应改用能执行 JS 的抓取方式，或让开发在初始 HTML 中输出链接。 - 触控事件：有些移动端“链接”实际是绑定
click或touchstart的按钮，没有href。这类不是死链接检测的对象，但会影响“移动端链接更少”的误判，需要在报告里单独标注。
假设某页面桌面端有 120 个链接、移动端只抓到 80 个，差值 40 个全部来自折叠菜单。假设场景下，这属于内容差异而非死链接，处理方式是确认折叠菜单展开后的链接状态，而不是直接判定移动端有 40 个死链。
跳转链路与状态码的比对条件
两端状态码不同，最常见的解释是重定向目标不同。核对时按最终地址判断，并注意以下条件：
- 移动 UA 跳转到独立移动站时，两套站的失效链接要分别维护，不能只修一套。
- 302 与 301 对检测结果影响不同：临时跳转可能随会话变化，检测时要固定请求条件。
- 返回 200 不代表链接有效，可能是软 404 页面。要结合页面标题和正文判断。
robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。检测死链接时，如果某链接被 robots.txt 屏蔽，抓取工具可能拿不到状态码，这时应单独标注“未检测”，不要写成“正常”。
交付时怎么记录才不返工
建议每条差异记录四个字段：原始链接、最终地址、桌面端状态、移动端状态。再加一列“差异类型”，从内容差异、抓取差异、跳转差异中选一个。这样开发拿到清单能直接定位，不用重新跑一遍。
判断优先级：两端状态码不同且都是 4xx 或 5xx 的，先修；只有一端能抓到的，先确认是否真实存在；懒加载导致的漏抓，先改抓取方式再复检。适用条件是两端共用同一套内容源；如果移动端是独立站点，则按两套站分别出报告。
下一步可以拿一个代表性栏目页做小范围试跑：桌面 UA 与移动 UA 各抓一次，按上面的四字段表格填一遍，确认差集里没有误判后，再扩大到全站。
