收录对不上时，大多数人的第一反应是去查内容质量、重复内容和 URL 规范。这些当然要查，但在此之前有一个更容易被跳过的前提：搜索引擎主要是用移动端 UA 抓取并评估页面的。你平时用桌面浏览器打开看到的那个完整版本，未必就是索引里保存的版本。
所以，核对收录的顺序应该往前挪一步：先确认蜘蛛拿到的移动端 HTML 和你以为的页面是不是同一个东西，再去讨论质量、重复和规范化。
一、先用两个 UA 各抓一次
最简单的动作是：拿移动端 UA 抓一次页面，再拿桌面 UA 抓一次，把两份 HTML 放在一起对比。重点看正文主体、主要导航链接、canonical 标签和指向的资源文件。
响应式站点两份代码通常一致，基本能过这一关。真正容易出问题的是独立移动域名和动态服务这两种方式——移动端返回的 HTML 里正文被砍掉大半，只剩标题、一张图和一句“请在桌面端查看”，而索引里保存的恰恰就是这一份。
二、三种建站方式各自的核对点
响应式：同一套代码
- 确认 viewport 设置正常，页面没有因为宽度判断而隐藏主体内容。
- 确认 CSS、JS 没有被 robots.txt 屏蔽，否则渲染结果会与浏览器不同。
- 用折叠、Tab、轮播藏起来的正文，仍然要保证它在 HTML 源码里存在。
独立移动域名：如 m 开头的子域
- 桌面页要指向移动页的 alternate，移动页要指向桌面页的 alternate，两边成对出现。
- 移动页自身的 canonical 应指向自己，不要反过来指向桌面页，那会让两套页面互相打架。
- 移动域名如果被 robots.txt 整段屏蔽，桌面页上的 alternate 就失去了意义，蜘蛛根本进不去。
动态服务：同一 URL 返回不同 HTML
- 这种模式下 canonical 保持自引用即可，不需要额外的 alternate。
- 要注意别让移动端返回的内容明显少于桌面端，否则索引里就是那个缩水版本。
- 留意 Vary 头与缓存配置，避免把移动端结果错误地返回给桌面端蜘蛛。
三、三处最容易出问题的差异
正文与主要链接。移动端为了加载速度，常把评论、参数表、部分段落直接不输出，而不是用 CSS 隐藏。这两者的区别很大：CSS 隐藏的内容还在 HTML 里，直接不输出的内容对蜘蛛等于不存在。列表页和栏目页同理，移动端少输出了几个入口链接，就等于少了几条爬取路径。
canonical 与 alternate 的成对关系。独立移动站最容易犯的错是两边都写自引用，或者只有一边写了 alternate。核对时把两个版本的 head 区域并排看一遍，确认指向关系是闭合的、不是单向的。
可抓取资源。被屏蔽的 CSS 会让渲染后的页面结构变形，被屏蔽的图片和脚本则可能让蜘蛛判断页面内容不完整。移动端尤其常见把静态资源放在单独的 CDN 子域上，却忘了给这个子域放行。
四、一套可执行的核对顺序
- 用移动端 UA 抓取目标 URL，保存 HTML。
- 用桌面端 UA 抓取同一 URL，保存 HTML。
- 对比两份源码中正文文本的长度与主要链接数量。
- 对比两份的 canonical 与 alternate，确认关系闭合。
- 检查 robots.txt 是否放行了 CSS、JS、图片所在路径。
- 确认移动端返回的状态码正常，没有把移动 UA 导向登录页或验证页。
- 以上都对齐后，再回到内容质量、重复与 URL 规范层面继续排查。
移动优先索引不是“只抓移动端”，而是“以移动端版本作为判断依据”。桌面端仍然会被抓取，只是当两个版本不一致时，索引更倾向于采用移动端看到的内容。
五、两个常见误区
一是以为做了响应式就万事大吉。响应式只解决了代码统一的问题，不解决内容输出被条件判断砍掉、资源被屏蔽的问题，这些仍然要单独核对。
二是把移动端的加载优化做成内容删减。为了速度删除正文段落、折叠全部评论、精简列表入口，短期看是加载变快了，长期看是索引里的页面变薄了。可以优化传输方式，但正文和入口最好保持完整输出。