移动端与桌面端在网站索引申请上的差异,通常不是“提交两次”那么简单,而是同一URL在两种环境下被抓取、渲染和评估的结果可能不同。时间和人手有限时,先检查移动端与桌面端返回的HTML、状态码、可抓取性和渲染结果是否一致,再决定是否需要分别处理。下面是一份按优先级排列的可执行清单。
要查什么:同一路径在移动端User-Agent和桌面端User-Agent下,是否返回相同的状态码和重定向终点。
怎么查:用命令行工具分别发送两种User-Agent请求,观察状态码和Location头。例如:
curl -I -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" https://example.com/page
curl -I -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://example.com/page
结果说明什么:如果一端返回200、另一端返回301或404,说明两种环境下的可索引地址不一致。此时应优先统一状态码和重定向规则,否则网站索引申请会指向不同终点。若两端都返回200但最终URL不同,需要确认哪个是规范版本。
要查什么:robots.txt是否对移动端或桌面端User-Agent设置了不同的抓取限制;页面HTML中的meta robots是否在移动端被改成noindex。
怎么查:直接访问/robots.txt,搜索User-Agent段落,确认是否出现针对移动端或桌面端的单独规则。再分别用两种User-Agent抓取页面HTML,检查<meta name="robots">的内容是否一致。
结果说明什么:robots.txt的抓取限制不等于可靠的索引移除,它只阻止抓取,不保证已收录URL被移除。如果移动端被robots.txt屏蔽而桌面端没有,移动端页面可能无法被抓取,但桌面端仍可能留在索引中。meta robots的noindex则需要抓取后才能生效,若移动端被屏蔽抓取,noindex可能永远不被看到。
要查什么:移动端和桌面端在JavaScript执行后,渲染出的正文、标题、链接和结构化数据是否一致。
怎么查:使用支持两种User-Agent的渲染工具或浏览器开发者工具的设备模拟,分别查看渲染后的DOM。重点对比<title>、<h1>、正文首段和主要内链。
结果说明什么:如果移动端渲染后正文为空或只有加载提示,而桌面端有完整内容,说明移动端可能无法被正确评估。网站索引申请针对的是可被抓取和渲染的版本,渲染差异会直接影响索引结果。若两端内容一致,则这一项无需优先处理。
要查什么:移动端和桌面端页面中的canonical标签是否都指向同一个规范URL;hreflang是否因端不同而指向不同地址。
怎么查:分别抓取两种User-Agent下的HTML,提取<link rel="canonical">和<link rel="alternate" hreflang="...">的值,逐条对比。
结果说明什么:如果移动端canonical指向移动版URL、桌面端指向桌面版URL,而两者内容相同,可能造成重复索引信号冲突。此时应统一canonical到同一规范地址,除非确实存在独立的移动版且已正确配置。hreflang若按端拆分,需要确认语言和地区定位没有因此混乱。
要查什么:站点地图中列出的URL是否在移动端和桌面端都能正常访问;内部链接是否在移动端指向了不同的路径或参数。
怎么查:从站点地图中抽取若干URL,分别用两种User-Agent请求,记录状态码和最终地址。再在移动端渲染后的页面中,检查主导航和正文链接的href是否与桌面端一致。
结果说明什么:站点地图不保证收录,但它能反映你希望被索引的地址。如果站点地图中的URL在移动端返回错误或重定向到其他地址,网站索引申请的实际对象就会偏离预期。内部链接不一致时,移动端可能把抓取引向非规范版本。
如果只能先做一件事,优先对比状态码和最终地址,因为它决定页面是否可访问。其次检查robots.txt和meta robots,排除抓取和索引指令冲突。然后看渲染后内容是否完整。canonical和站点地图可以放在后面,因为它们更多影响规范信号而非可访问性。每项检查完成后,记录移动端与桌面端的结果差异,只对确实不一致的项安排修复,不必两端全部重做。
下一步:选一个代表页面,用两种User-Agent各抓一次,把状态码、最终URL、meta robots和canonical四项结果并排列出,差异项就是最先要处理的工作。