搜索引擎的抓取与索引主体已经转向移动端 UA。这意味着同一个入口页，桌面端看起来正常，不代表移动端被抓取时也正常。很多「蜘蛛来过但没被收录」的情况，问题其实出在移动端返回的内容、跳转方式或者渲染结果上，而不是入口页本身不存在。
移动优先索引下的三个基本事实
在讨论具体配置之前，先把这三件事记住，后面所有核对都围绕它们展开。
- 抓取用的 UA 是移动端。如果入口页对不同 UA 返回不同 HTML，那么真正被看到的是移动端那一份。日志里区分移动与桌面 UA，是判断入口页对谁友好的第一步。
- 索引以移动端内容为准。移动端少了标题、正文或主要链接，桌面端补不回来。入口页如果为了移动端做了大幅精简，被精简掉的部分基本等于不存在。
- 渲染有超时。移动端网络环境更差，资源体积过大时，渲染可能在中途被放弃，最终只看到一个空壳页面。
响应式还是独立移动站
两种做法都能用，但维护成本差别很大。响应式只需要维护一个 URL、一套日志、一张证书，抓取链路最短，出现问题的环节也最少。
独立移动站通常意味着多一个 m 域名：多一套解析与证书、多一份缓存策略、日志被拆成两处，还要额外维护移动版与桌面版的对应关系。入口页数量一多，这套对应关系很容易失效，最后变成两边内容不一致。
如果确实用了独立移动站
- 移动版与桌面版需要互相标注对应关系，不能只靠 UA 判断跳转。
- 两边的标题、正文主体和主要链接应保持一致，不要把关键内容只放在一端。
- m 域名本身也要能被直接抓取，而不是必须经过一次跳转才能看到内容。
- 两边的状态码策略保持一致，避免一边 200、一边 302 或 404。
移动端最容易出问题的几个细节
viewport 与首屏内容
缺少 viewport 声明时，页面可能按桌面宽度渲染，移动端首屏往往只剩导航栏或大片空白。抓取拿到的正文位置要么在很靠后，要么根本不完整。核对时重点看：首屏能否看到入口页的核心链接与一段可读文字。
自动跳转与弹窗
打开页面就唤起 App、全屏遮罩、倒计时跳转，都会让抓取在拿到内容前就被带走。入口页上尤其不要做这类操作，因为入口页的价值就在于把链接稳定地暴露出来。
资源体积与加载顺序
阻塞首屏的 CSS/JS、未压缩的大图、自定义字体、多个统计脚本，都会拉长移动端的渲染时间。比较稳妥的做法是让正文和链接先出现在 HTML 里，脚本尽量延后加载，图片做好尺寸与压缩。
折叠与隐藏内容
移动端为了节省空间，经常把出链放进折叠区或标签页里，用 display:none 隐藏。隐藏内容被赋予的权重通常低于可见内容，重要链接不要只放在折叠区。
怎么验证移动端表现
- 用移动端 UA 抓取入口页，和桌面端返回的 HTML 做逐项比对，重点看标题、正文和链接数量。
- 检查渲染后的结果，确认正文、标题、主要出链确实存在，而不是只拿到框架。
- 翻访问日志，看移动 UA 的占比、状态码分布，以及是否出现大量 5xx 或超时。
- 确认内容不是靠 UA 判断或跳转才出现，避免改动 UA 就拿到另一份页面。
- 抽查几次抓取间隔，确认响应时间在合理范围内，没有明显的延迟尖峰。
落地建议
- 优先选响应式，入口页越简单越不容易出错。
- 入口页不做 App 唤起、不做全屏弹窗、不做倒计时跳转。
- 移动端与桌面端返回同一份 HTML，差异只放在样式层。
- 把移动 UA 的抓取情况纳入日常巡检，而不是只盯桌面端日志。
- 页面改动后，重新用移动 UA 抽查一遍链路，确认没有引入新的阻塞。
移动端适配解决的是「抓取链路能不能走通」，它不保证 URL 一定被发现或收录。把它当成入口页的基础卫生，而不是效果手段，预期会更接近实际。