2026 移动友好测试：免费工具与 PageSpeed API

Google 在 2023 年 12 月下线了独立的 Mobile-Friendly Test，但你仍可免费检查移动可用性。用 PageSpeed Insights 与 Lighthouse 做性能诊断，用 Chrome DevTools 做布局检查，用真机检查导航与表单。这些检查回答的是不同问题。快的页面仍可能有够不着的按钮，可用的页面仍可能加载很慢。

想在 20 秒内拿到结论？跑我们的免费 移动友好测试：粘贴 URL，即可得到视口、固定宽度、过小文字、体积与抓取检查的评分，并附上每一项的修法。无需邮箱。

2026 年哪些移动友好检查器仍可用

“跑一下 Google 的 Mobile-Friendly Test”这条建议已经死了。Google 宣布自 2023 年 12 月 1 日起逐步下线 Search Console 的 Mobile Usability 报告、Mobile-Friendly Test 工具与 Mobile-Friendly Test API，公开报道在 2023 年 12 月 4 日 确认了下线。Google 在该公告中的理由：移动可用性仍是其页面体验指引的一部分，但自 2015 年以来已出现其他资源，“including Lighthouse from Chrome”。

Google 还在 2023 年 12 月 1 日从 Search 帮助文档中抹掉了该工具的每一处提及，并把 Search Console 移动可用性 URL 重定向到资源概览。在 2023 年 4 月公告 中，Google 把人们指向 Lighthouse 作为替代。仍把已下线工具当作现成选项的指南已经过时。

还有一个独立检查器可用：Bing 的 Mobile Friendliness Test Tool。它检查 Bing 如何看待移动页面，包括视口配置、内容宽度、可读性与点击间距。其结论不能说明 Google 或 AI 助手会如何排名或引用该页。

移动可用性与移动优先索引是不同的检查

Google 用页面内容的移动版做索引与排名。其 移动优先索引指引 支持响应式设计、动态服务与独立移动 URL。推荐响应式设计，因为更易实现与维护。

先确认 Googlebot 能访问移动端的内容、图像与元数据。再检查人能多容易使用它们。被挡住的移动页是抓取问题；挤在一起的按钮是可用性问题。单靠 Lighthouse 分数或点击目标测量，都无法告诉你页面是否会被索引。

想要专家眼神看站点，而不是再开一个审计标签页？见我们的 网站优化服务。

用 PageSpeed Insights 与 Lighthouse 跑移动审计

从 PageSpeed Insights 开始。粘贴 URL，运行，先读 Mobile 标签，再读 Desktop。

报告拆成人们常混淆的两半：

• 顶部的实地数据： 来自 Chrome UX Report 的真实 Chrome 用户测量，在 28 天滚动窗口 上每日更新。这才是 Google 页面体验信号实际使用的。
• 下方的实验室数据： 在 Google 服务器上的一次模拟 Lighthouse 跑分。有用做诊断，不是对真实用户的判决。

要通过完整的三项 Core Web Vitals 评估，页面需要在 全部三项指标的第 75 百分位 达到良好阈值。缺少实地数据意味着报告无法提供该完整评估；这不是页面失败的证据。Lighthouse 无法从单次导航跑分测量实地 INP。

来源：web.dev Core Web Vitals 阈值，截至 2026 年仍适用。INP 已于 2024 年 3 月 12 日取代 First Input Delay (FID) 成为 Core Web Vital，因此忽略仍让你优化 FID 的清单。

两次挪动门柱的 PageSpeed Insights 变更

在 2024 年 12 月 5 日，PageSpeed Insights 调整了对 CPU（处理器）的节流力度，通常会抬高移动实验室跑分中的 Total Blocking Time。实地与桌面结果未受影响。若你的移动实验室分数掉了、却什么都没上线，这是合理原因。

PageSpeed Insights（PSI）及其 API 在 2025 年 10 月 20 日迁到 Lighthouse 13.0。版本会改变你看到的诊断项，因此每次结果都记下 Lighthouse 版本。对持续真实用户监控，Google 推荐 CrUX API 或 CrUX History API：它计划停止在 PSI API 中包含 CrUX 实地数据。

Mobile-Friendly Test API 有替代吗？

旧的 Mobile-Friendly Test API 随工具一起下线。PageSpeed Insights API 可以自动化一次移动 Lighthouse 跑分，但不会复现旧的移动友好通过/失败结果。你仍需要布局与交互检查。

下面的请求要的是移动性能、无障碍与 SEO 诊断。把示例 URL 换成你想测的公开页面：

curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'

Google 的 入门指南 允许无密钥试用 API，并建议对频繁自动化请求使用密钥。在安排批量任务前核对项目当前配额。若响应是 HTTP 429，去查配额，而不是把它当成被测页的结果。API 参考 记录了参数与响应字段。

读 lighthouseResult.categories 看类别分数，读 lighthouseResult.audits 看单项结果。分数用 0 到 1 的刻度；0.92 对应 100 分里的 92。把 fetchTime 与 lighthouseVersion 和被测 URL 一起保存，以便日后用已知跑分做比较。在把响应当成审计前，先处理 HTTP 错误与 runtimeError。

对实地性能，用 CrUX API 或 CrUX History API。某 URL 可能真实用户数据不足。把该状态与差结果分开，不要把实验室分数报成实地 Core Web Vitals 通过。

在本地跑 Lighthouse

Lighthouse 内置于 Chrome DevTools。打开页面，右键选 Inspect，打开 Lighthouse 面板，选 Mobile，再点 Generate report。它对着你安装的 Chrome 跑，且从不把结果上报远程服务器，因此你可以审计 staging 与受密码保护的构建，这些是 PSI 够不到的。

移动预设不是瞎猜。Lighthouse 施加 4x CPU 减速乘数，把桌面 CPU 拖进中端移动区间，外加代表 4G 连接最差四分位的 “Slow 4G” 网络预设。设备模拟使用 Moto G Power 配置，视口为 412×823，设备缩放因子 1.75，启用移动与触摸，依据 Lighthouse 自己的 constants.js（本文更早版本曾引用 2.625，那是 Lighthouse 已退役的旧 Moto G4 配置的缩放因子，不是当前值）。

Lighthouse 13 用与 DevTools 对齐的洞察替换了许多性能审计，保留 unsized-images 与 non-composited-animations 作为诊断。它也移除了旧的字号审计。诊断被移除并不等于不可读文字可接受；在手机上检查页面真实文字。

Chrome DevTools 设备模拟走查

分数告诉你速度。模拟告诉你页面是否可用。两者都要跑。

1. 在 Chrome 打开页面，按 Inspect 快捷键，再切换 Device Toolbar。
2. 先选窄视口。在 360×800 与 390×844 测试，再逐步升到平板宽度。
3. 把节流设为 Mid-tier mobile，或手动施加 Slow 4G 加 4x CPU，以匹配 Lighthouse 配置。
4. 旋转到横屏。在每种方向打开主导航、表单，以及结账或联系步骤。
5. 在你缩放时盯着 Elements 面板，找出哪个容器溢出。

模拟能抓住、分数永远抓不住的：

• 挤在邻居边上的小点击目标，包括 Lighthouse tap-targets 审计 覆盖的情况
• 固定宽度表格、嵌入或过大图像造成的水平溢出
• 在短屏上吃掉半个视口的粘性页眉与 cookie 横幅
• 关闭按钮被推到画布外的模态框
• 触发错误键盘或聚焦时缩放的输入框

对舒适触摸控件，布局允许时瞄准 48×48 CSS 像素。Lighthouse 文档化的规则同时考虑目标尺寸与邻近目标重叠；它不会让每个更小的控件都失败。单独的 WCAG 2.2 AA 目标尺寸标准 用 24×24 CSS 像素，并带间距等例外。两者都不是通用的 Google 排名阈值。

认清上限。模拟是缩放桌面浏览器并假装慢 CPU。它不会复现真实触摸延迟、iOS Safari 怪癖、拇指可达范围，或中端 Android 在热节流下处理重脚本的方式。每次审计都在真机上收尾。

在 Search Console 读 Core Web Vitals 移动数据

旧的 Mobile Usability 报告没了。用 Search Console 的 Core Web Vitals 报告看真实用户性能，再分开检查布局与交互。

打开 Search Console，进入 Core Web Vitals，处理 Mobile 报告。Google 按设备拆分概览，把交付相似体验的 URL 分组，并把每组标成其最差指标的状态。因此模板上一项差指标会把该模板下每个 URL 拖进 Poor。

我们怎么读：

• 点移动图表旁的 Open report，再切换 Poor、Needs improvement 与 Good 标签。
• 读 “Why URLs aren’t considered good” 表。它点名失败指标与被突破的阈值。
• 修模板，不是修单个 URL。组级状态意味着一次模板修复能带动许多页面。
• 部署后使用 Start Tracking。Google 跑 28 天监控会话，仅当问题在整窗内持续缺席时才标为已修复。

两点限定。数据是 28 天滚动聚合，所以周二上线的修复周三不会显现。且 Google 明确说 PageSpeed Insights 数据可能与 Core Web Vitals 报告不同，因为一个是单设备配置上的实验室跑分，另一个是成千上万次真实会话。两者不一致时，相信实地数据，用实验室跑分找原因。web.dev 更深入解释实验室与实地的分裂。同样的指标也坐落在我们如何做 网站优化 里。

最常见的移动失败与修法

这些是上面工具专为抓住的失败，附上各自使用的阈值或规则。

注意哪个工具检测什么。没有任何单一检查器覆盖整张表，这正是旧的单一通过/失败徽章从来不够的原因。

我们跑的审计，一步一步

这是我们在自己站点与客户站点上按顺序使用的序列。

1. 挑三个 URL，不是一个。 首页、一个头部服务或产品页，以及一篇博文。模板失败方式不同。
2. 先 Search Console。 Core Web Vitals，Mobile 视图。记下哪些 URL 组坐在 Poor 或 Needs improvement，以及点名了哪项指标。这是真实用户，因此它定优先级。
3. 对每个失败组中的一个 URL 跑 PSI。 比较实地与实验室。若实地说 Poor、实验室说还行，去找第三方脚本、登录态，或干净实验室跑分永远看不到的慢源。
4. 在同一三个 URL 上本地跑 Lighthouse。 Mobile 预设。读 tap-targets 与 unsized-images 诊断，以及 Accessibility 面板的对比度失败。
5. DevTools 设备模式 360×800。 打开导航、表单与主转化步骤。旋转。找溢出与被挡内容。
6. 在同一批 URL 上跑 Bing 的 Mobile Friendliness Test，拿第二个爬虫对视口、宽度、可读性与点击间距的结论。
7. 一部真机，有中端 Android 更好。 用蜂窝网络加载，不是办公室 Wi-Fi。端到端完成转化动作。
8. 上线模板修复，然后在 Search Console 点 Start Tracking，并预期验证清零前要等 28 天。

为什么实地数据与实验室数据不一致

Google 明确说 PageSpeed Insights 数据可能与 Core Web Vitals 报告不同。实验室数据是单一设备配置上的一次模拟跑分。实地数据是真实 Chrome 用户 28 天滚动聚合。web.dev 关于实验室与实地数据的指南 点名常见原因：真实设备与网络比实验室变化更大，第三方脚本对真实用户表现不同，缓存与往返缓存改变回访，且 CrUX 只报告有足够流量的 URL。不一致时，把实地数据当判决，把实验室跑分当诊断。

我们审站点时先看 Search Console 实地数据，再用 PSI 与 Lighthouse 点名元素或脚本。Google 自己的优化指南就是剧本：

• 慢 LCP：优化 Largest Contentful Paint。压缩英雄图，提供现代格式，预加载 LCP 元素，不要对它懒加载。
• 高 INP：优化 Interaction to Next Paint。拆开长任务，推迟或移除阻塞主线程的第三方 JavaScript。
• 高 CLS：优化 Cumulative Layout Shift。为图像与嵌入设置 width、height 或 aspect-ratio，使它们加载时布局不跳。

Search Console 把交付相似体验的 URL 分组，并把每组标成其最差指标的状态。一次模板修复，例如共享卡片组件上的图像尺寸，可一次带动许多 URL。上线后使用 Start Tracking，并在 Google 标为已修复前等满 28 天窗口。

在主题变更、插件或应用安装，以及任何标签管理器部署之后重复这八步序列，外加定期季度巡检。第三方脚本是 Google INP 指引 中记录的 INP 风险，这就是第 3 步拿实地数据对照干净实验室跑分的原因。围绕这次移动检查的抓取、索引与页内工作，见我们的 搜索引擎优化 服务。

若你用 WordPress 或 Shopify

两个平台大多靠配置而不是代码就能走完大半路：

• 响应式主题，在承诺前先在 360px 测过
• 除 LCP 图外处处用原生懒加载
• 以正确尺寸提供现代图像格式，而不是用 CSS（层叠样式表）把桌面文件缩小
• Shopify Online Store 2.0 模板与区块级图像尺寸
• 审计已装应用与插件，因为每一个通常都会加阻塞渲染的 JavaScript

每次主题或应用变更后重跑 Lighthouse。移动分数就是在那里悄悄下滑。若主题本身就是天花板，修法是在现代框架上重建，从一开始就工程化性能与 SEO，这正是我们的 网站开发服务 交付的。

常见问题

Google 的测试没了，我现在怎么查移动友好度？

在 Chrome DevTools 的 Mobile 预设上跑 Lighthouse，检查 PageSpeed Insights 的 Mobile 标签，读 Search Console 的 Core Web Vitals 移动报告，再在真机上确认。若你想要通过/失败结论，Bing 的 Mobile Friendliness Test 仍会给一个。

移动友好与响应式有何区别？

移动友好意味着页面在手机上可用。响应式设计用流体布局与 CSS 媒体查询，把同一页面适配到不同视口。Google 推荐响应式设计以便维护，但也支持动态服务与独立移动 URL。

我需要单独的移动网站吗？

不需要。单一响应式 URL 更易维护，避免重复内容处理，并为 SEO 与 生成式引擎优化 给出同一套信号。

Google 会惩罚非移动友好的网站吗？

分开检查内容访问与用户体验。Google 需要访问并渲染你的移动内容才能索引。Core Web Vitals 用于排名，但 即使页面体验不达标，Google 仍会寻找相关内容。差的移动分数本身不能证明被取消索引、受惩罚或特定排名损失。

为什么 PageSpeed Insights 与 Search Console 不一致？

Google 说两者可以不同。PSI 实验室数据是单一设备配置上的一次模拟跑分。Search Console 报告的是跨 URL 组的真实 Chrome 用户 28 天滚动聚合。Google 的 Core Web Vitals 报告文档 与 web.dev 的实验室与实地文章 都告诉你把实地数据当判决，把实验室数据当诊断。

四个工具接替了那枚徽章

单一通过/失败徽章没了，也不会回来。接替它的更好：真实用户的实地测量、可在 staging 跑的实验室审计、用于布局的视口模拟，以及 Bing 第二个爬虫的结论。围绕这四项建流程，按 Search Console 说真实用户体验到的来排优先级，修模板而不是修单个 URL。

我们从温哥华做这件事，作为 网站优化。若移动性能在烧掉排名或转化，增长审计 是起点。