不少站长对站点的理解还停留在“有两套页面”：PC 端一套、移动端一套，蜘蛛各抓各的、各收录各的。实际情况是，搜索引擎早已把移动端页面当作主要的抓取与索引对象，PC 端版本更像是一个对照视图。两端内容不一致时，进入索引的很可能是移动端那句话、那张图、那个标题。
移动优先索引，优先在哪里
所谓移动优先索引，是指搜索引擎在抓取、渲染、判断页面内容时，主要采用移动端代理（通常是智能手机的 UA）看到的版本。这个版本会作为主文档进入索引，用来理解页面主题、抽取标题与正文、识别图片、读取结构化数据、发现内链。PC 端版本仍会被抓取，但更多是作为参考，而不是索引内容的主要来源。
因此，那种“PC 端首页写得很全，移动端首页只放了一个横幅和几行字”的做法，最终留在索引里的往往是那个很空的版本。页面主题没变，但可用的内容信号少了一大截。
两端不一致时，先看这几处
- 正文：移动端折叠、隐藏、懒加载后没有渲染出来的段落，PC 端有，索引里没有。
- 标题与描述：两端 title、h1 不一致时，移动端那份更容易被采用。
- 内链：移动端导航收进汉堡菜单，或由 JS 动态插入，蜘蛛能顺着走的链接会明显减少。
- 图片与替代文本：移动端用背景图替换掉 img，alt 信息随之丢失。
- 结构化数据：只写在 PC 模板里，移动端模板没有输出。
- 指令与限制：移动端模板误带 noindex，或 robots.txt 里针对移动 UA 有额外限制。
这些问题单看都不致命，叠在一起就会出现“PC 端看着正常、搜索里的展示却残缺”的情况，而排查时又容易只盯着 PC 端页面，方向就跑偏了。
独立移动站：两套 URL，别把关系搞乱
如果使用 m.example.com 这类独立移动站，两套 URL 的对应关系必须清楚：每一对页面之间要能互相发现，canonical 指向要保持一致，不能出现 A 指向 B、B 又对蜘蛛说不要收录这种自相矛盾的组合。早年的常见做法是移动端 canonical 指向 PC 端，现在更普遍的是移动端自指；两种方案本身都可以，前提是同一站点内选一种并贯彻到底。
另一种常见失误是改版、换域名时只处理了 PC 端的跳转和标注，移动端还停在旧 URL 上。蜘蛛在移动端抓到的是一份“没人管”的页面，收录自然混乱。
响应式站点也不能掉以轻心
响应式布局不等于自动安全。如果内容是通过 JS 按屏幕宽度判断后注入的，移动端很可能拿不到；如果把大段正文用 display:none 藏起来，内容质量评估也会受影响。更常见的是为了移动端速度做“精简版”，把正文砍掉一半、把参数表整段删除——这是最不划算的一种优化。
一份可以照着做的移动端自查清单
- 用手机 UA 抓取一次 HTML，与 PC 版逐项对比正文、标题、图片、结构化数据。
- 在关闭 JS 的状态下再看一次，确认核心内容不依赖脚本才出现。
- 核对移动端模板输出的 meta robots，确认没有被全局误伤。
- 检查移动端导航里的链接是否为可抓取的 a 标签，数量是否与 PC 端接近。
- 确认 canonical 与备用标注在两端互相吻合，没有互相打架。
- 用站点工具查看页面时，注意抓取的到底是哪个版本，别只看 PC 端的渲染结果。
- 选取几个重点栏目页，人工在手机上打开，看看正文、图文、参数是否完整。
发现问题之后
处理顺序上，优先改模板而不是逐页修补：移动端缺内容就补齐渲染逻辑，导航恢复成真实链接，canonical 关系统一，确认移动端没有意外的 noindex。改完之后不必反复提交，等蜘蛛按自己的节奏回访即可。真正要盯的是“下一个新页面发布时，同样的问题会不会再出现”。
收录的前提是蜘蛛能看到；在移动优先的语境下，这句话更准确的说法是——蜘蛛在手机上能看到什么，才决定索引里留下什么。