为什么移动端和 PC 端要分开核对
很多站点在核对收录时，习惯把注意力放在“这个 URL 有没有进索引”上，却忽略了同一个页面在移动端和 PC 端可能对应两个不同的地址。如果两套地址都被当成独立页面收进去，同一份内容就会在索引里出现两遍，既稀释了权重预期，也让后续的收录统计变得难以解释。
更麻烦的是，这类重复往往不会报错：页面状态码都是 200，内容也都能正常打开，只能通过在索引和日志里比对地址才能发现。
先确认站点用的是哪种适配方式
自适应（响应式）
一套 URL，靠 CSS 和视口适配不同终端。这种最省事，正常情况下一个地址就是一条记录，核对时只需抽查少量页面，确认移动端渲染是否正常。
独立移动站
常见写法是 m.example.com 或者 example.com/m/，PC 与移动各有一套完整 URL。这时必须明确哪一套是“主”，并通过 canonical、alternate 之类的标注把两套地址指向同一个实体。核对时要特别留意标注是否双向、有没有写错域名或路径。
同一 URL 动态适配
地址不变，服务端按 User-Agent 返回不同版本。这种情况下索引里通常只有一条地址，但要确认移动端返回的 HTML 不是空壳，也不是只有一段跳转脚本。
核对时具体查这几项
- 索引里的地址：按域名分组，看移动站域名或 /m/ 路径下的 URL 占了多少。如果占比异常高，说明很可能被当成独立页面收了。
- 标注关系：抽查若干页面，确认 canonical 指向的是同一套地址，而不是 PC 页指向自己、移动页也指向自己。
- 日志里的抓取：分别看移动 UA 和普通 UA 抓的地址是否一致，有没有出现两套地址都被反复抓取。
- sitemap 提交内容：确认提交的是主地址，还是把两套地址都列了进去。
- 移动端可访问性：确认移动站没有被 robots.txt 拦掉，也没有出现未登录就 302 回 PC 首页的情况。
三种常见情况怎么处理
两套都被收录且内容一致
先定主地址，把另一套通过 canonical 或 301 归并过去，然后观察索引的替换过程。不建议在同一时间既改标注又改 URL 结构，否则很难判断是哪一步起了作用。
只收了 PC 没收移动
多数情况下这不是问题，反而是正常结果。只要主地址进了索引、移动端能正常打开，就不必为了“两边都要收”额外做工作。
移动端页面内容明显更少
如果移动版砍掉了正文，只留标题和引导语，即使地址被收录，也很难撑住这个位置。核对时把移动端渲染后的正文长度和 PC 端对比一遍，差距过大就先补内容，而不是先纠结收录数量。
抓取正常、状态码正常，都不代表两套地址被正确合并。移动适配的问题通常只在索引层面暴露，所以核对要落到索引里的实际地址上。
一个可执行的顺序
- 列出站内所有可能产生多套地址的入口：移动域名、/m/ 路径、带设备参数的跳转链接。
- 抽样 20 到 30 个页面，记录索引中存在的地址、canonical 指向、移动端正文长度。
- 按模板归类，看重复是集中在某几个栏目，还是全站普遍存在。
- 确定主地址后，分批修改标注或做跳转，改完留出观察周期再统计。