移动优先索引推行之后，搜索引擎的蜘蛛在抓取和评估一个站点时，越来越常以移动端 UA 的身份访问。也就是说，你在电脑上看到的那个排版整齐、内链完整的页面，未必是蜘蛛实际读到的那一份。很多站点的问题并不出在内容本身，而是移动版少了一块——导航被折进汉堡菜单、正文被塞进标签页、内链只剩几个图标按钮。
一、先弄清蜘蛛拿到的移动版是什么样
不要凭手机截图判断，截图看到的是渲染后的结果，而抓取的第一步往往是原始 HTML。更可靠的做法是主动复现蜘蛛的视角：
- 用移动端 User-Agent 请求几个代表性 URL，直接查看返回的 HTML 源码，确认正文、标题、主要链接是否都在里面。
- 再用渲染工具或抓取诊断类功能跑一遍，看渲染后还有没有内容被脚本补进来。
- 样本不要只挑首页，栏目页、详情页、列表第二页各取一两个，问题往往藏在模板分支里。
这一步做完，你通常会得到两个版本的对比：桌面版和移动版。接下来要判断的是，差异到底是正常的响应式收缩，还是内容真的少了。
二、移动端最常见的几类问题
1. 正文或内链被藏起来
为了移动端好看，有些模板会把次要内容默认折叠，或者用display:none隐藏掉整块区域。如果被隐藏的恰好是正文后半段、相关阅读、栏目入口，那移动版页面对蜘蛛来说就是一份残缺文档。判断标准很简单：这段内容对用户有价值，就不该在移动版里消失；如果它对用户没价值，桌面版也没必要留着。
2. 独立移动站与主站脱节
使用独立 m 域名的站点，容易出现几类割裂：移动站缺少桌面站的 canonical 指向、两边互相声明 canonical 形成循环、移动站的内链只在本域名内打转。这些都会让蜘蛛在两套 URL 之间来回判断，浪费抓取额度，也让权重分散。现在更推荐的做法是响应式同一套 URL，如果历史原因必须保留独立移动站，就要保证两边的一对一映射关系准确。
3. 移动版本身太重
移动端首屏加载慢，直接影响蜘蛛能拿到多少内容。常见原因是未压缩的大图、首屏就加载的第三方脚本、过多的字体文件。蜘蛛不会无限等待，抓取超时或渲染不完整，页面就可能只被抓到一半。先把首屏必要的资源压到最小，其余部分延迟加载，收益通常比换模板更直接。
4. 交互遮挡了内容
弹窗、浮层、强制下载提示、插屏广告，如果覆盖面积过大，用户和蜘蛛都可能拿不到真正的正文。移动端尤其容易踩这个坑，因为屏幕本身就小，一个全屏浮层就等于整页不可读。
三、按这个顺序做自查
- 列出站点的主要页面模板：首页、栏目页、详情页、列表页、搜索结果页。
- 每个模板挑两到三个 URL，分别用桌面 UA 和移动 UA 抓取源码，逐项对比正文、标题、主要内链数量。
- 打开渲染后的版本，确认懒加载、标签页、折叠块里的内容能被正常展开。
- 检查移动版与桌面版之间的 canonical、hreflang 等指向是否一致、是否形成循环。
- 用移动网络或限速模拟环境跑一次首屏加载，记录关键资源的体积。
- 把发现的问题按影响面排序，先修涉及主要模板、影响正文抓取的项，再处理体验类细节。
四、改完之后怎么验证
调整上线后不要只看首页。重新用移动 UA 抓取同一批 URL，对比修改前后的源码差异，确认正文和内链确实出现在 HTML 里，而不是靠脚本在客户端补出来。同时观察一段时间的抓取日志，看移动 UA 的访问是否更稳定、是否还大量停留在少数几个页面上。
移动端自查的目标不是让移动版和桌面版长得一模一样，而是保证两者承载的信息量一致。展示形式可以不同，能被读到的内容不该少。
这类自查不需要一次做完，把它并进日常的模板改动流程里更实际：任何一次模板调整之后，都用移动 UA 复查一遍主要模板，比等到流量下滑再回头排查省事得多。