先把“对不上”的具体表现说清楚

移动端收录和 PC 端不一致，常见的有几种：PC 页面早就进了索引，移动端 URL 一直没动静；两边都被收录，但移动端展示的标题、摘要和 PC 差很多；移动端页面进过索引又消失；以及 m 域名下冒出一批本不该收录的参数页。这几种表现背后的原因并不相同，先分清表现，再决定从哪里查。

第一步：确认自己用的是哪种适配方式

适配方式不同，出问题的位置完全不同。

• 响应式（同一套 URL）：理论上只有一份 URL，出现差异多半是渲染或展现层面的问题，而不是两份 URL 争收录。
• 独立移动站（m 域名）：存在两套 URL，差异通常来自跳转、标签和 sitemap 的配置。
• 动态服务（同一 URL 返回不同 HTML）：取决于识别 User-Agent 是否稳定，容易出现该返回移动版时却返回了 PC 版。

先确定自己属于哪一类，后面的排查才有方向。

响应式站点：重点查渲染与资源屏蔽

响应式站点如果出现移动端表现异常，多数不是“收录问题”，而是移动端抓取时页面没被完整渲染。

• robots.txt 是否屏蔽了 CSS、JS 或图片目录，导致移动端抓取时拿到的是一张“裸 HTML”。
• 正文是否依赖懒加载或滚动触发，首屏 HTML 里其实是空的。
• 是否存在弹窗、浮层、引导下载 App 的遮罩，把主要内容挡在后面。
• viewport 和字体、宽度设置是否让渲染出的内容大量缺失。

这类站点只需要一份 URL，如果 PC 收录正常而移动端展现异常，优先怀疑渲染，而不是去改收录相关的配置。

独立 m 域名：重点查跳转与标签

• 移动端抓取时是否被 302 跳到 PC 页，或反过来形成循环跳转，最后落在一个非预期的 URL 上。
• m 页面是否误加了 noindex，尤其是模板继承、条件判断写错的时候。
• canonical 指向是否自洽：是指向 PC 页，还是自指，还是两种写法在不同模板里混用。
• 是否有独立的移动 sitemap，且里面只放移动 URL；PC sitemap 里是否混进了 m 链接。
• 两套 URL 的内链是否各自闭环，还是 PC 页面全部链向 PC，移动页面成了孤岛。

这几项里任何一项出错，都可能让其中一端长期拿不到正常的发现路径。

内容与内链的差异往往被忽略

移动端为了阅读体验常做裁剪：正文只保留前半段、参数表格折叠起来、评论区去掉、相关推荐换一套。改动幅度小没问题，如果裁得太多，移动端页面在内容完整度上会明显弱于 PC 端，被抓取后自然不占优势。

内链同理。不少站点移动端导航是 JS 渲染的，或者干脆省略了面包屑和分类入口，结果移动端 URL 的入链数量远少于 PC 端，URL 被发现的速度也就慢了一截。

建议的排查顺序

1. 用移动端 User-Agent 抓一次页面，确认返回的是移动版还是 PC 版。
2. 看首屏 HTML 里有没有正文，还是必须等 JS 执行完才出现。
3. 检查 robots meta、canonical 等标签在两边是否成对、是否自洽。
4. 核对 sitemap，移动 URL 是否在里面，PC sitemap 里是否混了移动 URL。
5. 统计移动端页面的内链入口数量，看是否只藏在某个按钮或提交动作之后。
6. 对比两边内容差异，判断是轻微裁剪还是整体替换。
7. 最后再看收录与展现状态，区分是没被抓、抓了没渲染，还是渲染了但内容判低。

移动端收录慢或缺失，多数时候不是引擎“更偏向 PC 端”，而是移动端在可抓取性、可渲染性和内容完整度上先输了一步。

处理原则：先补齐，再谈收敛

确定问题落在哪一层之后再动手：抓取不到就修跳转和屏蔽规则，渲染不出来就改加载方式，内容被裁得太狠就恢复主体信息，内链缺失就补入口。不要一上来就给整个 m 目录加 noindex，那只是把可见的问题藏起来，移动端的流量入口也会一起丢。