先分清站点用的是哪一种移动适配

同一篇内容在手机端和电脑端表现不一样时，收录问题往往不是内容质量本身，而是页面被拆成了两套入口。动手之前先确认站点属于哪一类：

• 响应式：同一套 URL，靠 CSS 适配屏幕。收录入口只有一个，问题多出在渲染环节。
• 独立移动域：例如 m.example.com 与 www 各自有 URL。入口变成两套，容易出现重复与分散。
• 动态服务：URL 相同，但按 User-Agent 返回不同 HTML。表面是一个入口，实际是两套内容。

三种方式的核对重点并不相同，先归类再检查，能避免在错误的模板上反复改动。

同一 URL 的方案：先看抓取到的正文主体

响应式和动态服务共同的坑

这两种方式 URL 不变，但如果移动端把正文折叠成“展开全文”，或者内容要等 JavaScript 二次请求才填充，抓取到的初始 HTML 里可能只剩标题和一句摘要。核对方式很直接：用移动 UA 请求一次，看原始响应里的文字量，而不是只看浏览器里渲染完的效果。

如果两端 HTML 差异明显，重点确认三处：正文主体是否在初始响应中；被隐藏的内容是否属于可解析的样式隐藏；是否有整块内容依赖异步接口返回。

动态服务还要额外看缓存

按 UA 分发内容的站点，务必确认缓存层没有把桌面版本发给了移动 UA，或者反过来。一个常见现象是：缓存命中后，爬虫拿到的 HTML 与当前页面模板对不上，正文结构甚至标签都对不齐。核对时清一次缓存再抓，看两次结果是否一致。

独立移动域：URL 对应、指向和跳转要能互相对上

移动域的问题通常集中在“对应关系断掉”。检查这几点：

• 移动页能否被直接抓取，robots.txt 是否误屏蔽了 m 目录。
• 移动页是否有自引用 canonical，而不是笼统地指向桌面页。
• 桌面页与移动页之间是否有可解析的跳转或标注关系，而不是只靠一段 JS 判断屏幕宽度。
• 移动页是否出现在 sitemap 或站内链接中，还是只能靠跳转才能被发现。

如果移动页内容与桌面页基本一致，通常把其中一个版本作为收录主版本、另一个用 canonical 收敛即可；如果移动页是精简版（正文大幅缩短、参数被裁掉），两套都保留反而会分散信号。

一套可执行的核对顺序

1. 列出移动 URL 与桌面 URL 的对应表，先看有没有页面缺一半。
2. 分别用移动 UA 和桌面 UA 抓取，保存原始 HTML，不依赖渲染结果。
3. 对比两端正文主体的文字量，明显缩短的那一端要单独排查原因。
4. 检查 canonical 与页面间的互相指向是否自洽，有没有指向一个抓取受限的地址。
5. 检查移动端是否存在独立的屏蔽设置：noindex、robots 规则、登录墙、App 跳转遮罩。
6. 确认内链和 sitemap 使用的是哪一套 URL，避免两套入口混着提交。
7. 最后再看索引中实际保留的是哪个版本，以及是否长期停留在旧版本上。

几个反复出现的情况

• 移动页打开后自动跳到 App 下载页，抓取到的正文为空。
• 移动端默认只显示摘要，完整内容要点击展开，初始 HTML 里没有正文。
• 图片和评论区懒加载，正文本身没问题，但页面整体可解析内容偏少。
• UA 判断把未知爬虫当成桌面端，返回了带弹窗或跳转的版本。
• 移动域被整体 noindex，同时又出现在 sitemap 中，信号互相矛盾。

移动适配的核对目标不是让两端内容完全一致，而是让“被收录的版本”和“用户实际看到的版本”对得上。先统一入口，再谈内容质量，顺序反了会白做很多无用功。

如果两端差异确实必要，就把差异控制在不影响正文主体的范围内，让标题、核心正文和主要链接保持一致，其余展示形式可以各按各的来。这样既保留了移动体验，也不会让索引在两个版本之间反复选择。