检查移动端与桌面端的收录差异,核心不是分别查两个数字,而是确认同一URL在两个环境下返回的HTML、状态码和可抓取性是否一致。如果移动端返回的内容更少、状态码不同,或关键内容依赖客户端脚本才出现,收录结果就可能分叉。起点是选一组有代表性的URL,用相同请求头分别抓取并对比。
收录差异可能来自三个层面,需要分开判断:
这三层的排查顺序应从响应层开始。响应层不一致时,讨论渲染和索引没有意义。
以下步骤可直接执行,不需要特定工具,用命令行即可完成:
rel="canonical"是否一致。判断结果的标准很简单:如果移动端和桌面端的初始HTML中核心内容一致、状态码一致、canonical一致,那么收录差异更可能来自索引层而非内容层。如果初始HTML中移动端缺少核心内容,则应优先修复服务端返回或渲染方案。
robots.txt的抓取限制不等于可靠的索引移除。即使某个User-Agent被禁止抓取,已收录的URL仍可能出现在结果中,因为限制的是抓取而非索引。检查时应确认移动端和桌面端是否被同一组规则覆盖,而不是假设禁止抓取就等于不被收录。
站点地图不保证收录,它只是提交URL的渠道。检查时可以把站点地图中的URL与两端实际可抓取的URL做交集对比,看是否存在只提交了桌面端可访问、移动端返回异常的页面。
假设某详情页桌面端返回200,正文约3000字符;移动端User-Agent请求返回200,但正文只有导航和页脚,核心内容为空。这时可以判断:差异出在响应层,移动端服务端没有输出主体内容。修复方向是让服务端对移动端请求也返回完整HTML,或改用同构渲染。
如果两端初始HTML都包含完整正文,但移动端收录量明显偏低,则应转向检查抓取日志、站点地图提交情况和内部链接是否对移动端有额外限制。此时问题更可能在索引层。
第一,HTTPS不保证安全无漏洞或排名,它只是传输层加密。检查收录差异时不要把HTTPS当作收录的充分条件。
第二,不同搜索引擎对移动端和桌面端的处理方式不同,支持情况须分别核查。同一组URL在A搜索引擎的移动端收录正常,不代表B搜索引擎也正常。检查时应按搜索引擎分别记录结果,而不是合并成一个结论。
下一步:选一组URL,用桌面和移动端User-Agent各请求一次,记录状态码和正文长度。出现不一致的URL,先修响应层,再查索引层。