google mobile friendly test停用后如何检查适配？

Google 已于 2023 年 12 月停用 google mobile friendly test 和 Search Console 中的“移动设备易用性”报告。原先“一次检测、给出是否适合移动设备”的入口消失，并不意味着移动适配不再影响收录和排名；Google 仍主要使用 Smartphone Googlebot 抓取网页，并以移动版内容作为索引和评估基础。

真正需要替代的不是一个绿色“通过”标识，而是三类判断：Google 能否抓取并渲染移动页面；用户在真实手机网络下能否正常使用；页面的速度和布局稳定性是否拖累体验。单一工具无法覆盖这三件事，较稳妥的做法是把 URL 检查、PageSpeed Insights 与真机验证组合使用。

先用 URL 检查确认：Google 看到的页面是否正常

进入 Google Search Console 的“网址检查”，输入完整 URL，优先查看已编入索引的版本。这里要确认的不是页面在自己电脑上能不能打开，而是 Google 最近抓取的页面是否可索引、是否选定了预期的规范网页，以及抓取是否使用 Smartphone Googlebot。

页面刚修改、尚未重新抓取，或怀疑 Google 读取结果与浏览器不同，可使用“测试实际网址”。重点检查抓取和呈现结果：若截图中出现空白区域、主内容缺失、弹窗遮挡、样式错乱或报错，问题通常不在“屏幕尺寸”，而在资源加载、前端渲染或访问限制。

• JavaScript 依赖：首屏主内容、产品参数、语言切换内容若完全依赖脚本异步加载，需要确认 Google 渲染后确实能取得这些内容。
• 资源可访问性：CSS、JavaScript、图片 CDN 或字体文件被 robots.txt、WAF、地区限制或登录校验拦截，会导致 Googlebot 得到不完整页面。
• 响应式一致性：桌面端与移动端不要因 CSS 隐藏而丢失核心产品信息、正文、内部链接或结构化数据。
• 异常状态码：移动端访问被错误跳转、返回 4xx/5xx，或被导向不相关页面，都会影响正常抓取。

URL 检查适合回答“搜索引擎能否看到”，但它不是速度测试工具，也不能替代用户操作测试。检查结果正常，只能说明索引链路没有明显障碍。

PageSpeed Insights 用于发现移动性能和布局问题

PageSpeed Insights（PSI）应作为日常排查入口。输入网址后，注意区分“实际用户数据”和 Lighthouse 实验室数据。前者来自满足条件的 Chrome 用户体验数据集，反映已有访问中的体验；后者是在模拟移动环境下运行，适合定位当前页面可复现的性能问题。

移动端尤其应关注三项 Core Web Vitals：LCP 反映主要内容出现速度，INP 反映点击、展开菜单、提交表单等交互响应，CLS 反映页面加载时元素是否跳动。它们不是“移动适配”的全部，却经常暴露影响询盘和浏览的问题，例如首屏大图未压缩、第三方追踪脚本过多、Cookie 横幅挤压内容、图片和嵌入内容未预留尺寸。

PSI 的诊断建议应按页面实际功能判断，不宜机械追求满分。外贸网站常见的多语言脚本、客服工具、表单验证、地图和视频都会增加加载成本。更有价值的处理顺序是：先保证首屏核心内容和询盘入口可用，再压缩图片、延迟非关键脚本，最后评估非必要第三方组件是否应移除。

浏览器设备模式只能做初筛，真机仍不可省略

Chrome DevTools 的设备工具栏可以快速切换屏幕宽度、像素密度和网络限速，适合在改版时检查断点：导航是否折叠正确、表格是否横向溢出、按钮是否被截断、固定底部联系方式是否遮挡表单。它的优势是效率高，限制是不能完整模拟不同系统浏览器、键盘弹起、权限弹窗和真实网络波动。

涉及询盘、下单或下载资料的页面，应至少在常见手机浏览器上完成完整路径测试：从搜索落地页进入，切换语言，打开产品详情，点击 WhatsApp、邮箱或表单，提交后确认成功提示和邮件通知是否正常。许多页面在视觉上“适配”，但国家区号输入框无法调起数字键盘、验证码被悬浮按钮遮住、附件上传失败，这类问题不会由原来的 mobile friendly test 自动识别。

不要把“响应式设计”误判为“移动端合格”

响应式 CSS 解决的是布局随屏幕变化的问题，不能自动解决移动体验。常见风险包括：桌面大图直接缩小后首屏加载过慢；产品规格表在手机上难以阅读；菜单层级过深；小字号和密集链接造成误触；弹窗或广告覆盖主体内容；移动端保留了过多动画和自动播放视频。

对于依赖 Google 自然流量的页面，还应检查移动版与桌面版的内容信号是否一致。若移动端为了“简洁”删除了产品型号、应用说明、FAQ、面包屑和相关产品链接，Google 用移动版本建立索引时可读取的信息也会减少。正确做法不是把信息简单隐藏，而是通过折叠区、锚点导航、短段落和可横滑表格改善阅读方式，同时保留可抓取的核心内容。

把检查放进发布流程，而不是等收录异常后补救

每次更换主题、改动导航、接入营销脚本、增加多语言页面或调整 CDN 后，都应抽查首页、核心产品页、内容页和表单落地页。先在浏览器设备模式确认布局，再用 PSI 查看移动性能和布局位移，最后通过 Search Console 对重要 URL 进行实际网址测试。若页面已收录但流量或展示异常，再结合 Search Console 的“网页索引”状态、抓取时间和规范页信息判断问题范围。

停用 google mobile friendly test 后，检测工作从一次性的“合格/不合格”变成持续验证。对运营执行而言，最关键的不是寻找一个完全相同的替代按钮，而是区分渲染、性能与转化路径这三种问题：Google 看不到，先处理抓取和资源；页面打开慢，先处理首屏和脚本；用户无法完成动作，再回到真机流程逐项修复。