移动优先索引已经运行多年，但对不少站点来说，“移动页”和“桌面页”仍然是两套东西。蜘蛛抓取时更倾向使用移动端 UA 访问，也就是说它拿到的 HTML 很可能不是你在地脑浏览器里看到的那一份。如果两份页面在正文、内链、状态码上出现错位，后续判断基本就按那台“手机”看到的结果来。
三种实现方式，各自的错位点
响应式：一份 HTML 走天下
结构最省心，桌面和移动看到的是同一个 URL、同一份源码。要注意“视觉上隐藏”不等于“抓取不到”：用 CSS 隐藏的文本仍然留在 HTML 里，蜘蛛能看到；但如果菜单或内容要靠点击后才由 JS 注入，抓取时就未必存在。移动端把大段内容折叠起来通常不影响抓取，前提是折叠逻辑不是纯前端异步拉取。
动态服务：同一 URL 返回不同 HTML
服务器根据 UA 返回不同版本，URL 保持不变。这种模式要盯住缓存层：如果 CDN 或反向代理只按 URL 做缓存键，很可能把桌面版返回给移动 UA，或者反过来。配置 Vary: User-Agent 之类的响应头，并抽查缓存命中后的实际 HTML，是比较稳妥的做法。搜索引擎一般能接受这种做法，前提是两版内容实质一致。
独立 m 站：两套 URL
m.example.com 这类结构最容易出现分叉。常见问题包括：两个版本互相 canonical 指向混乱、移动页整体被 robots.txt 屏蔽、移动页缺少指向桌面页的内链。比较清晰的做法是每个页面 canonical 指向自身，同时保证移动版本本身能被正常抓取和渲染，而不是“先屏蔽掉，再指望主站被理解”。
移动端容易漏掉的内容与链接
- 汉堡菜单里的导航链接：如果是点击后才由 JS 注入 DOM，抓取时可能拿不到，主导航最好保留在初始 HTML 中。
- Tab 与轮播：只渲染第一屏，后面的内容对蜘蛛不可见。
- “加载更多”按钮：用 button 加异步请求代替 a 标签时，后续列表页就断在抓取路径上了，建议保留可点击的分页 URL。
- APP 下载浮层与强制跳转：有些移动页会直接 302 到应用商店，蜘蛛跟过去只能看到一个无关页面，主题内容就此丢失。
- 懒加载图片：不影响链接发现，但图片地址如果只在滚动后才写入 src，图片索引可能拿不到。
一套对齐检查清单
- 用移动端 UA 抓取几个典型页面的原始 HTML，与桌面版逐项对比 title、H1、正文段落数、内链数量。
- 确认 robots.txt 没有针对移动 UA 的额外规则，也没有屏蔽渲染所需的 JS、CSS。
- 检查 WAF、CDN、防火墙规则是否对移动 UA 或爬虫 UA 有特殊拦截，避免返回验证页或 403。
- 检查是否存在按 UA 分流的状态码差异，比如移动端返回 302、桌面端返回 200。
- 抽查缓存层返回的 HTML，确认不会出现版本串号。
移动优先不是让桌面版随便做，而是意味着蜘蛛对页面的判断更依赖移动版本。两版一致时这套机制几乎无感；一旦错位，问题往往出现在抓取阶段而不是展示阶段，排查顺序也应该从抓到的 HTML 开始。
最后提醒一点：不必追求两版像素级相同，重点是主体内容、可抓取链接和 HTTP 状态保持一致。每次改版或调整导航结构后，用移动 UA 复抓一遍关键页面，比等到日志里出现异常再回头查要省事得多。