检查移动端与桌面端差异,核心做法是按 User-Agent 把日志分成两组,再对比同一批 URL 的抓取频次、状态码和抓取耗时。常见误解是“日志里移动端记录少,就说明移动端有问题”。实际上,搜索引擎的移动爬虫和桌面爬虫抓取节奏本来就可能不同,记录少不等于抓取失败,必须结合状态码和请求目标一起判断。
日志中的 User-Agent 是分组的起点。常见标识包括含 Mobile、Android、iPhone 的移动爬虫,以及不含这些字段的桌面爬虫。不同搜索引擎的命名方式不同,需要分别核查,不能拿一家的规则套另一家。
分组时注意两点:
如果分组本身错了,后面的对比就全部失真。所以第一步是把日志按 UA 归类,统计各组的请求总量,确认样本量足够再进入下一步。
移动端和桌面端请求总数不同,通常不代表故障。真正需要对比的是同一批 URL 在两端的表现:
判断结果时要设条件:只有当移动端出现持续的高比例错误状态码,或同一 URL 在移动端长期无法抓取时,才值得进一步排查。单纯频次低,先观察一到两周再下结论。
假设你已有一份包含 UA、URL、状态码、时间戳的日志,按下面顺序操作:
如果手动请求正常,但日志里移动端持续报错,可能是爬虫 IP 被限流或 CDN 规则误伤;如果手动请求也异常,问题出在服务端对移动 UA 的处理逻辑上。
坑一:把 robots.txt 限制当成索引移除。 如果 robots.txt 对移动爬虫做了限制,日志里移动端记录会减少,但这不等于页面已从索引中移除。robots.txt 只控制抓取,不控制索引。
坑二:用站点地图判断抓取状态。 站点地图里列出了 URL,不代表移动爬虫一定会抓。日志才是抓取行为的直接记录。
坑三:忽略 HTTPS 与状态码的关系。 HTTPS 不保证页面无漏洞,也不保证移动端一定返回 200。证书配置问题可能导致移动端请求失败,需要单独检查。
下一步建议:先导出最近 7 天日志,按 UA 分成移动组和桌面组,统计两组的 4xx、5xx 占比。如果移动组错误率显著高于桌面组,再对异常 URL 逐条手动验证。