网站死链检查：移动端与桌面端怎样检查差异？
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c0cfe11d3881.html
📄
网站死链检查：移动端与桌面端怎样检查差异？
移动端与桌面端的死链检查结果可能不同，原因不在“链接本身”变了，而在于页面给两端返回的内容、跳转路径或可点击元素不一样。要判断差异，最直接的办法是分别用移动端和桌面端的用户代理请求同一批链接，记录状态码、最终地址和页面内容，再对比不一致的条目。只在一端检查，很容易漏掉另一端才会出现的死链。
为什么同一链接在两端结果不同
死链检查的核心是看某个地址返回什么。服务器可以根据请求头里的 User-Agent 返回不同页面：桌面端拿到正常页，移动端被重定向到已下线的移动版；或者反过来，移动端正常，桌面端跳到一个 404。常见差异来源包括：
- 移动版与桌面版使用不同路径，例如
/m/与/，其中一套已废弃。 - 响应式页面按屏幕宽度隐藏或替换链接，导致某一端看不到某个入口。
- 重定向链在两端长度不同，中间某一跳失效。
- 页面由 JavaScript 渲染，两端拿到的初始 HTML 不同，链接在渲染后才出现。
这些都属于“可能原因”，不是看到差异就立刻断定。要确认是哪一种，需要看请求记录，而不是只看浏览器里点开的结果。
分别抓取：把两端数据放在一起比
可执行的做法是跑两次检查，只改 User-Agent，其余参数保持一致。假设用命令行工具抓取同一份 URL 列表：
curl -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -o /dev/null -s -w "%{http_code} %{url_effective}\n" -L "https://example.com/page"
把 -A 换成桌面端常见 UA 再跑一次，就得到两组“状态码 + 最终地址”。逐条对比：
- 状态码不同：一端 200、一端 404 或 410，说明该端确实拿到死链。
- 最终地址不同：两端跳到不同页面，检查是否有一条跳向失效地址。
- 状态码相同但内容不同：可能是软 404，即返回 200 却显示“页面不存在”，需要看正文关键词。
- 链接数量不同：一端多出或缺少入口，说明链接由脚本或样式控制。
判断结果时以“用户实际会遇到的端”为准：如果移动端用户占多数，移动端 404 的优先级更高，但桌面端死链同样要修，除非该路径已明确只服务一端。
检查项：哪些差异值得优先处理
不是所有差异都要马上改。可以按下面的检查项排序：
- 是否返回 404、410 或 5xx：这类是硬故障，两端都要清零。
- 是否形成重定向环或过长跳转链：两端分别数跳数，超过三跳就值得查。
- 失效链接是否在导航、页脚、正文首屏等关键位置：位置越显眼，影响越大。
- 失效链接是否被站内其他页面引用：引用越多，修复收益越高。
- 移动端是否被单独重定向到已下线页面：这是移动端特有的高发问题。
如果某条链接只在桌面端失效，而该页面本身已改为仅移动端可用，那么正确处理是让桌面端也跳转到有效地址，或返回明确的 301，而不是留着 404。
工具与手工检查的取舍
批量抓取工具适合覆盖全站，但多数工具默认只用一个 User-Agent，容易漏掉另一端。手工点击适合抽查关键路径，但无法覆盖全部链接。比较稳妥的组合是：先用工具各跑一次移动端和桌面端，导出两份结果，用表格做差集；再对差集里的每条链接手工确认一次。工具报告里的“死链”也要复核，因为超时、被限流或需要登录的页面可能被误判。
另外要分清：robots.txt 禁止抓取不等于页面已从索引移除，站点地图里列出的地址也不保证被收录。检查死链时关注的是链接可达性，不要把它和收录问题混在一起。
下一步怎么做
先选 20 到 50 条代表性链接，包含导航、正文、页脚和分页，分别用移动端与桌面端 UA 各请求一次，把状态码和最终地址记进同一张表。找出两端不一致的条目，按“硬故障优先、关键位置优先”的顺序逐条确认原因，再决定是修链接、改重定向还是调整页面输出。这样得到的差异清单，才是可以直接拿去修的依据。
