网站死链查询，移动端与桌面端怎样检查差异
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a2d3ce5cf025.html
📄
网站死链查询，移动端与桌面端怎样检查差异
网站死链查询时，移动端与桌面端的差异通常来自三处：抓取时声明的用户代理不同、页面实际渲染出的链接不同、以及重定向或错误页在两种环境下返回的状态不同。因此不能只在一端查完就认为另一端也没问题。最直接的做法是分别用移动端用户代理和桌面端用户代理各抓一遍链接，再对比两批结果中状态码不一致的 URL。
先观察：两端可能查出不同结果的原因
桌面端和移动端在死链查询中产生差异，常见原因有以下几类：
- 响应式页面在窄屏下隐藏了部分导航或列表，这些被隐藏的链接在移动端抓取时可能根本不会出现，于是移动端查不出，桌面端能查出。
- 站点对移动端用户代理返回不同模板，移动模板里可能多出或缺少某些链接。
- 同一 URL 在服务端根据用户代理做重定向，桌面端跳到可用页，移动端跳到失效页，或相反。
- 移动端专属页面（如
/m/路径）只在移动环境下被引用，桌面端抓取不会触达。
这些都属于“可能原因”，要确认是哪一种，必须靠两端抓取结果比对，而不是凭经验断言。
判断：用两组用户代理分别抓取再对比
执行步骤如下。第一步，选定一个爬取工具或脚本，能自定义 User-Agent 和并发数。第二步，用桌面端 User-Agent 抓取站点，导出所有被引用 URL 及其状态码。第三步，用移动端 User-Agent 抓取同一站点，导出同样字段。第四步，把两份结果按 URL 对齐，筛出状态码不一致的记录。
判断结果时注意：
- 两端都返回 404 或 410，说明是真实死链，与设备无关，直接修。
- 仅一端返回 404，另一端返回 200，说明存在用户代理相关的差异，需要检查服务端重定向规则或模板逻辑。
- 一端根本没抓到某 URL，说明该链接在那一端的渲染结果里不存在，属于链接可见性差异，不等于死链。
假设某页面在桌面端导航里有一个指向旧栏目的链接，返回 404；移动端导航折叠后没有这个链接。此时桌面端查出死链，移动端查不出。这不是移动端没问题，而是移动端用户看不到这个入口——但搜索引擎的移动端抓取仍可能通过其他路径发现它，所以两端都要修。
处理：按差异类型分别修
如果是重定向规则导致的差异，检查服务端配置里是否按 User-Agent 分流。分流规则应保证两端最终落到同一个可用目标，或至少都不落到错误页。如果是模板差异导致的链接缺失，确认移动端模板是否遗漏了必要的内链，尤其是分页、面包屑和列表页链接。如果是移动端专属路径失效，优先把移动端引用改到与桌面端一致的 URL，或为移动端路径设置正确的重定向。
处理时不要用 robots.txt 屏蔽来“解决”死链。robots.txt 的抓取限制不等于可靠的索引移除，被屏蔽的 URL 仍可能因外部链接被收录，且屏蔽后你无法通过抓取确认它是否真的失效。
复查：改完后再跑一次两端对比
修改后重新用两组用户代理抓取，确认之前不一致的 URL 现在状态码一致且为 200，或一致地指向正确目标。复查项包括：状态码是否一致、最终 URL 是否一致、页面标题是否正常返回。如果站点有站点地图，可把两端抓取到的有效 URL 与站点地图对照，但站点地图不保证收录，它只是提交线索，不能当作两端一致性的证据。
另外，HTTPS 只说明传输层加密，不代表页面没有死链，也不代表排名更好，复查时不必把它当作死链判断依据。
下一步：先固定一组桌面端和一组移动端 User-Agent，对首页和主要栏目各抓一层，导出状态码对比表。如果两端差异集中在少数模板，优先修模板；如果差异分散且无规律，再从服务端重定向规则查起。
