最快修法：80% 被标”不适配移动端”的页面，都只是 <head> 里少了一行。把 <meta name="viewport" content="width=device-width, initial-scale=1"> 加进 base layout，重新部署，再用 PageSpeed Insights 切到 Mobile 标签跑一遍。如果 viewport 本来就有，那原因基本就是 tap target、横向溢出，或者正文字号小于 16px——往下逐项排查。
先说一下工具，因为这类文章常常比它描述的工具更”老”。Google 已在 2023 年 12 月 1 日下线了独立的 Mobile-Friendly Test 工具、Search Console 里的 Mobile Usability 报告，以及 Mobile-Friendly Test API。 如果你在找”移动设备易用性”标签，或者那个单一的绿色”页面适配移动设备”结论，它已经不存在了。Google 官方建议改用 Lighthouse（在 Chrome DevTools 里）和 PageSpeed Insights。Mobile-first indexing 自 2023 年起已全量铺开——Googlebot 抓取和排名用的都是页面的移动端渲染——所以一个在手机上没法用的页面，依然会收录降级、排名打折，只是现在换了套工具来诊断而已。
你属于哪一类
| 真机上的表现 | 大概率原因 | 跳转 |
|---|---|---|
| 整页渲染得很小，文字要捏开才看得清 | 缺 viewport meta | 原因 1 |
| 按钮/链接老点错，很难点准 | tap target 太小或挤在一起 | 原因 2 |
| 页面能横向滚，内容跑出屏幕边缘 | 某个元素比 viewport 宽 | 原因 3 |
| 桌面端正文清楚，手机上偏小 | 字号低于 16px | 原因 4 |
| 加载时弹窗/横幅盖住正文 | 侵入式 interstitial | 原因 5 |
| 布局出来前先闪 1-2 秒空白或无样式 | CSS 只在客户端加载 | 原因 6 |
常见原因
1. 缺 viewport meta（最致命）
没这一行，移动端浏览器会退回到 980px 的桌面 viewport 再缩小整页来适配，于是什么都显得很小：
<meta name="viewport" content="width=device-width, initial-scale=1">如何判断：
curl -sL https://yourdomain.com/page | grep -i viewport
# 找不到这一行就是缺2. tap target 太小或太近
Lighthouse 会把小于 48 x 48px 的可交互元素（按钮、链接、表单控件）标出来；达到或超过 48 x 48px 的目标不会触发这条审计。无障碍标准要松一点——WCAG 2.2 SC 2.5.8 Target Size (Minimum)，AA 级，要求 24 x 24 CSS px，除非目标周围间距足够。直接做到 48px 可以同时过这两条。相邻目标之间至少留 8px，免得一根手指同时点到两个。
如何判断： 用 Lighthouse 跑一遍页面（DevTools → Lighthouse → Mobile → Analyze），在 SEO 部分看 “Tap targets are not sized appropriately”，它会列出每个不合格的元素。或者用 Chrome DevTools → Device Mode 直接看每个按钮的 box 大小。
3. 横向滚动 / 内容超出 viewport
只要有一个元素的宽度写死、且大于屏幕（例如 width: 600px 在 360px 的手机上），整页就会横向滚。常见元凶：
- 大图没
max-width: 100% - 表格不响应式
- 代码块
pre没做 overflow 处理 - iframe 写死了
width
/* 万能修补 */
img, video, iframe {
max-width: 100%;
height: auto;
}
pre {
overflow-x: auto;
}
table {
display: block;
overflow-x: auto;
}如何判断： 在 DevTools Device Mode 里，把下面这段粘进 Console，列出所有比 viewport 宽的元素：
document.querySelectorAll('*').forEach(el => {
if (el.scrollWidth > document.documentElement.clientWidth)
console.log(el);
});4. 字号太小
桌面端的 14px，在手机上举到正常阅读距离看大约只有 10px 的感觉。正文保持 16px 或更大。
body {
font-size: 16px;
line-height: 1.6;
}
@media (max-width: 480px) {
body { font-size: 17px; } /* 小屏稍大 */
}5. 弹窗 / 同意横幅遮挡内容
Google 的”侵入式 interstitial”规则，会对用户从搜索进来后立刻盖住主内容的遮罩降权。Cookie / 同意提示应该做成顶部或底部的薄条，不要全屏弹窗。GDPR/Cookie 这类法律要求的横幅，只有在占用屏幕比例合理时才会被容忍。
6. 关键 CSS 只在客户端加载
如果基础样式没有服务端渲染、也没内联，移动端首屏会先显示 1-2 秒无样式内容，从而拉低 CLS（布局偏移）得分，并产生一次无样式内容闪烁（FOUC）。
如何判断： Chrome DevTools → 命令面板（Cmd/Ctrl+Shift+P）→ “Disable JavaScript” → 重新加载。如果页面现在变成无样式，说明你的关键 CSS 依赖了 JS。
最短修复路径
Step 1：用 PageSpeed Insights 拿到具体报错
https://pagespeed.web.dev/?url=https://yourdomain.com/your-page跑完停在 Mobile 标签。它会跑一次 Lighthouse 审计，列出实际问题——缺 viewport、tap target、字号可读性，以及 Core Web Vitals（LCP、INP、CLS）。注意：INP 已于 2024 年 3 月 12 日取代 FID，成为衡量响应性的 Core Web Vital——好的 INP 是在第 75 百分位低于 200ms。
Step 2：先加 viewport meta（约 80% 的情况一行解决）
在所有页面模板的 <head> 靠上位置：
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
...
</head>千万别加 user-scalable=no 或 maximum-scale=1——它会禁掉双指缩放，既伤无障碍，也会让 Lighthouse 的 “has a [user-scalable=no]” / viewport 审计不过。
Step 3：响应式 CSS 兜底
加到全局 stylesheet：
* { box-sizing: border-box; }
html, body { overflow-x: hidden; }
img, video, iframe { max-width: 100%; height: auto; }
pre, code { white-space: pre-wrap; overflow-x: auto; }
table { display: block; overflow-x: auto; }
button, a {
min-height: 48px;
min-width: 48px;
padding: 12px 16px;
}
body { font-size: 16px; line-height: 1.6; }Step 4：本地用 Chrome DevTools Device Mode 测
1. 打开 DevTools，切换设备工具栏 (Cmd/Ctrl+Shift+M)
2. 选一个真机配置，例如 "iPhone 15 Pro" 或 "Pixel 8"
3. 逐个模板走一遍，注意横向滚动 / 字小 / 按钮挤
4. Throttling：设为 "Mid-tier mobile"，看真实加载体验Step 5：部署后用 Search Console 验证
现在已经没有 “Mobile Usability” 报告了，改用 URL 检查（URL Inspection） 验证：
Search Console → URL 检查 → 粘贴修复后的 URL → 测试实际网址
→ 查看测试后的网页 → 屏幕截图渲染出来的截图应该是正常的手机端布局（宽度对、没有截断）。日常监控看 Search Console → Core Web Vitals → 移动设备，它按设备分段报告字段数据；随着真实用户数据累积，URL 会从 “Poor” 移动到 “Good”（修复上线后通常需要 28 天的字段数据）。
Step 6：把全站性检查加进 CI
独立的 Mobile-Friendly Test API 已经没有了，所以这条又便宜又值的不变量自己来守——每个页面都必须有 viewport meta，且不能禁用缩放：
// scripts/check-mobile-friendly.mjs
import fg from "fast-glob";
import fs from "node:fs";
const issues = [];
for (const f of fg.sync("dist/**/*.html")) {
const html = fs.readFileSync(f, "utf8");
if (!html.match(/<meta\s+name=["']viewport["']/i)) {
issues.push(`MISSING viewport: ${f}`);
}
if (html.match(/user-scalable\s*=\s*["']?no/i)) {
issues.push(`BAD viewport (user-scalable=no): ${f}`);
}
}
if (issues.length) { console.error(issues.join("\n")); process.exit(1); }想覆盖得更深，可以在每次部署时用 Lighthouse CI（@lhci/cli）跑几个代表性 URL，并对 SEO/无障碍分数设一个下限断言。
如何确认已修好
- PageSpeed Insights → Mobile 标签不再有 viewport / tap-target / 可读性的报错。
- DevTools Device Mode 选手机配置：没有横向滚动条、不用捏开、每个按钮都好点。
- Search Console → URL 检查 → 实际网址测试的截图渲染出干净的移动端布局。
- 接下来约 4 周内，该页面在移动端的 Core Web Vitals 状态向 “Good” 靠拢。
预防建议
- 新模板上线前先在真机（Pixel/iPhone）上测，而不只是桌面浏览器。
- 用响应式默认合理的 CSS 框架（Tailwind、Pico.css），让基础布局自动缩放。
- 正文字号永远 16px 起；可交互目标永远 48 x 48px。
- viewport meta 写进 base layout，任何模板都漏不掉。
- CI 拦截：页面缺 viewport meta 或写了
user-scalable=no，直接 build fail。
常见问题
Mobile-Friendly Test 去哪了？ Google 在 2023 年 12 月 1 日把它、Mobile Usability 报告和那套测试 API 一起下线了。改用 Chrome DevTools 里的 Lighthouse，或 PageSpeed Insights——这是 Google 推荐的替代品。
2026 年”不适配移动端”还算排名因素吗？ 算，但是间接的。Mobile-first indexing 意味着 Google 用页面的移动端渲染来排名。手机上难用的页面，Core Web Vitals（页面体验信号）更差、被抓取的渲染结果也更差，两者都可能压低排名。
我的 CSS 是响应式的，Google 还是报问题，为啥？ 响应式布局不等于 mobile-first 的内容一致。常见缺口：移动端菜单藏掉了桌面端有的链接（导致内部权重传递不同）、内容折在 Googlebot 不会展开的 tab 里、或主内容是 lazy-load 的、对爬虫渲染不出来。用 URL 检查 → 查看测试后的网页 → HTML 看渲染后的 HTML。
tap target 最小能做到多小？ Lighthouse 的审计在 48 x 48px 通过。无障碍下限（WCAG 2.2 SC 2.5.8，AA 级）是 24 x 24 CSS px 且间距足够。做到 48px 可以两边都满足。
修好之后 Google 多久会重新评估？ URL 检查的实际网址测试会立刻反映修复。Core Web Vitals 报告里的字段数据信号有延迟，因为它由约 28 天的真实用户数据汇总而来，所以状态大约会在四周内更新。