网站收录

移动端与桌面端两套 URL:收录口径不一致时的自查顺序

同一个页面在手机和电脑上可能是两套 URL,收录时容易出现一个版本进了索引、另一个迟迟不被收录的情况。本文按适配方式分类,梳理移动版可达性、canonical 与 alternate 的成对关系、内容一致性、sitemap 覆盖等检查点,给出一套从外到内的自查顺序。

网站收录

移动端与桌面端两套 URL:收录口径不一致时的自查顺序

同一个页面,在手机上打开和电脑上打开,看到的可能不是同一份 HTML。如果这种差异是用两套 URL 实现的(比如桌面版和 m 站),收录环节就容易出现口径不一致:桌面版进了索引,移动版长期没有;或者反过来,移动版被收录,但正文被削得很短,在结果里表现很差。这类问题不是抓取失败,而是两套地址在告诉搜索引擎两件不同的事。

先确认站点用的是哪种移动适配方式

适配方式决定了要检查什么,先分清再排查,能省掉一大半无用功。

响应式:同一套 URL,问题最少

桌面和移动共用一个地址,HTML 相同,只是 CSS 断点不同。收录上基本没有双版本困扰,需要留意的是移动端渲染后正文是否被折叠、隐藏或被脚本延迟加载,导致渲染结果里内容为空。

独立 m 站:两套 URL,必须成对检查

桌面版和移动版各有自己的地址,此时最重要的是两个地址之间的关系有没有声明清楚。常见的做法是两套页面各自 self-canonical,再用 alternate 互相指向,让引擎知道它们是同一内容的不同版本。如果移动版的 canonical 指向桌面版,实际效果相当于把移动版权重全部让给桌面版,移动版很难单独进索引。想清楚你希望哪个版本被收录,再决定指向关系,不要两套页面各写一套互相矛盾的声明。

动态服务:同一 URL,按 UA 返回不同 HTML

最容易出问题的是缓存层。如果 CDN 或反向代理只按 URL 做缓存,就可能把桌面版 HTML 返回给以移动 UA 抓取的蜘蛛,或者反过来。需要确认响应里带有正确的 Vary 头,并检查缓存策略是否按 User-Agent 区分。

几个常见的收录卡点

  • robots.txt 只放行了某一类 User-Agent,另一个版本的可抓取路径被挡住了。
  • 移动版缺少 canonical,或者 canonical 指向的地址返回 301、404。
  • 移动版正文被大幅裁剪,只剩标题和摘要,容易被当成内容不足的页面。
  • 移动版内链全部指向桌面版(或全部指向移动版),导致其中一个版本几乎没有站内入口。
  • sitemap 只列了桌面版,移动版只能靠内链被发现,收录速度明显偏慢。
  • 移动版页面返回 200,但主要内容靠脚本渲染,渲染后仍是空壳。

自查顺序:从外到内一步步收窄

  1. 确认可达性。用移动 UA 请求移动版地址,看返回状态码和最终落点,确认没有意外跳到桌面版或错误页。
  2. 检查抓取许可。核对 robots.txt、meta robots 与响应头里的 X-Robots-Tag,两个版本都要看,别只看桌面版。
  3. 核对 canonical 与 alternate。逐对检查指向是否互相一致、是否指向可访问的地址,避免出现 A 指向 B、B 指向 C 的断链。
  4. 比对正文与内链。移动版的核心内容应当与桌面版一致,内链也应当能走通,而不是把用户和蜘蛛都赶回桌面版。
  5. 检查 sitemap 覆盖。确认希望被收录的版本出现在 sitemap 中,格式与状态码正常。
  6. 看渲染结果。用 URL 检查类工具查看渲染后的 HTML,确认正文没有被脚本吃掉。
不要对同一个 URL 按不同 UA 返回内容差异极大、又各自声明不同 canonical 的页面。信号互相打架时,判断会变得很不确定,收录结果也就难以预测。

最后一点:移动适配方式一旦确定,尽量在整站保持一致。改版或迁移时按目录分批推进,每批改完观察一段时间的收录情况,比一次性全站切换更容易定位问题出在哪一环。