Search Console 发来通知，一两周后 Pages 报告里有效页数往下走，曝光掉 15-40%。Mobile-first indexing 的意思是：Google 用你页面的移动渲染作为抓取、索引和排名用的 canonical 版本。桌面版有、而移动版 HTML 没有的东西——正文、结构化数据、内链、图片 alt——对 Google 来说基本就是不存在。
最快的修法： 用移动 user-agent 抓同一个 URL，看原始 HTML（不是浏览器里那个活的 DOM），跟桌面 HTML 做 diff。把正文、JSON-LD、<a href> 链接、alt 文本上的每一处差异补齐，再对掉得最惨的几个页面请求重新索引。完全恢复一般要 4-8 周。
本文讲的是被丢掉的桌面端信号，不是 mobile usability（另文）。截至 2026 年 6 月，mobile-first 是 Google 唯一的模式——没法退出，对已经有移动版的站也没有桌面端兜底。
先澄清一件事：accordion 和 tab 是没问题的
一个常见的误导：有人看到移动版把内容塞进 accordion 或 tab，就以为这是病根。不是。Google 官方说得很明确：
You can have a different design on mobile to maximize user experience (for example, moving content into accordions or tabs); just make sure that the content is equivalent to the desktop site.
只要文本在渲染好的 HTML 里，Googlebot 就会读折叠的 accordion 和 tab 内容，不管它当前是不是显示状态。Google 真正不会索引的是下面这一类。
常见原因
1. 主内容靠用户交互才懒加载
真正把内容搞掉索引的就是这个。如果某一段要等点击、滑动、轻触或敲键盘之后才去拉正文，Googlebot 永远看不到。Google 直接这么写：
Don’t lazy-load primary content upon user interaction. Google won’t load content that requires user interactions (for example, swiping, clicking, or typing) to load.
点了才 fetch() 的 “Show details” 按钮、滚动到底才加载的评论，都掉进这个坑。而文本已经在 HTML 里的 accordion 不会。
怎么判断：打开移动 URL，用 “View source”（原始 HTML），不是 “Inspect”（活的 DOM）。如果某段正文不在 raw source 里、要交互之后才出现，那它就不在索引里。
2. 移动站是独立 m.example.com 子域且内容更薄
老的 m-dot 架构，好几年前做的：引语短、没有 FAQ、没有相关链接。Google 现在把 m.example.com 当 canonical，桌面那些更丰富的内容被忽略。
怎么判断：m.example.com/article/x 和 www.example.com/article/x 并排对比，数字数、数内链。移动版明显更短就是它。
3. 结构化数据只在桌面模板里（或里面写的是桌面 URL）
桌面输出 Article、Breadcrumb、Product JSON-LD；响应式模板在小视口”为减小 payload”跳过 JSON-LD，或者移动版 JSON-LD 里硬编码的还是桌面 URL。Google 要求这里对齐：
Make sure that your mobile and desktop sites have the same structured data… Make sure that URLs in the structured data on the mobile versions are updated to the mobile URLs.
怎么判断：移动 URL → view source → grep application/ld+json。和桌面对比数量和 @type，并确认里面的 URL 指向的是移动/canonical 版本。
注意：Google 在 2026 年 5 月 7 日 deprecated FAQ 富媒体结果（FAQ rich results），Search Console 的 FAQ 报告和 Rich Results Test 支持在 2026 年 6 月也被移除。FAQPage 标记仍是合法的 Schema.org 类型，Google 仍会解析它（Bing 和各 AI 回答引擎也会），所以留着没坏处——只是别再指望 Google SERP 里出现那个 FAQ 面板，也别把索引下跌赖到缺 FAQ 富媒体上。
4. 桌面侧边栏的内链在移动端没了
桌面有 sidebar 列 20 条相关文章、作者 bio、归档链接。移动把所有东西塞进 hamburger 菜单，链接要轻触之后 JS 才注入。Googlebot 失去这些内链信号，抓取发现和链接权重都被削弱。
怎么判断：
curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15" \
"https://yoursite.com/article/x" | grep -o '<a href=' | wc -l把这个数跟桌面 UA fetch 对比。掉得多就说明移动 HTML 缺链接。
5. 移动版图片缺 alt 或 srcset 更薄
桌面是 <img alt="详细 alt 文本">；移动用了另一个 <picture> 没 alt，或者只给缩略图源。Image Search 排名直接崩。Google 要求很明确：“Make sure that the mobile site has the same alt text for images as the desktop site.”
怎么判断：移动 view source → grep <img。找漏掉 alt= 的、或者跟桌面图片 URL 不同的。
6. Robots meta 或 canonical 在两个视口不一致
模板 bug：只在移动视口输出 <meta name="robots" content="noindex">（或反过来），或者 canonical 根据 user-agent 指向不同 URL。Google 的规则：“Use the same robots meta tags on the mobile and desktop site.”
怎么判断：同一个 URL 用桌面 UA 和移动 UA 各 fetch 一次，对比 <meta name="robots"> 和 <link rel="canonical">。任何差异都是 bug。
7. 遗留的 AMP 页被当成移动 canonical
如果你还在跑 AMP，而被索引的 canonical 是 AMP 版本，那 AMP 校验错误或缺内容就直接伤害这个页。AMP 实质上已经走到生命周期尽头：好几年前就失去了 Top Stories 和徽标优势，Search Console 的 AMP 报告也在逐步下线。Core Web Vitals 达标的标准 HTML 能做到 AMP 以前做的一切。
怎么判断：看你的页面是不是还在发 <link rel="amphtml">，以及 Search Console 是不是把 AMP URL 报成 canonical。如果是，退掉 AMP、只发一套响应式页面，才是长久的修法。
你属于哪一类？
| 移动原始 HTML 里的症状 | 可能原因 | 对应小节 |
|---|---|---|
| 段落正文要点击/滚动之后才出现 | 交互触发的懒加载 | #1 |
| 字数远低于桌面，且是独立 host | m-dot 内容薄 | #2 |
application/ld+json 数量比桌面少 | 条件输出结构化数据 | #3 |
<a href> 数量远低于桌面 | JS 注入导航链接 | #4 |
<img> 缺 alt 或图片 URL 不同 | 移动图片模板 | #5 |
robots/canonical 随 UA 不同 | 模板/UA bug | #6 |
页面发 rel="amphtml"，AMP 是 canonical | AMP 坏掉/遗留 | #7 |
最短修复路径
第 1 步：做内容对齐审计
挑 20 个代表页。每个抓桌面和移动 HTML，对比字数、链接数、JSON-LD 块、图片数、alt 文本。
for url in /article/a /article/b /category/c; do
echo "=== $url ==="
printf 'desktop words: '
curl -s -A "Mozilla/5.0 (X11; Linux x86_64)" "https://yoursite.com$url" | wc -w
printf 'mobile words: '
curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" "https://yoursite.com$url" | wc -w
done差异超过 10% 都得补齐。（curl 拿到的是服务端渲染的 HTML，不是 JS 注水后的 DOM——这恰好就是”交互懒加载坑”要看的那个视角。想看 Googlebot 跑完 JS 之后渲染出什么，用 URL Inspection 工具的 “View crawled page” / “Test live URL”，在那里读渲染后的 HTML。）
第 2 步：把交互门槛后的内容写进渲染好的 HTML
如果某段正文要用户操作之后才到，那它不会被索引。把文本放进 HTML，让 CSS 或一个 toggle 控制显隐。
<!-- 坏：点了才渲染正文 -->
<button onclick="loadSection()">Show details</button>
<div id="details"></div>
<!-- 好：内容在 HTML 里，CSS 隐藏，JS 只切显隐 -->
<details>
<summary>Show details</summary>
<div>实际内容写在 raw HTML 里。</div>
</details>第 3 步：m-dot 合并回响应式
如果还在跑 m.example.com，长久的修法是统一到 www.example.com 一套响应式站。短期内：给 m-dot 跟桌面一样的内容、结构化数据、内链，并配好双向的 rel="alternate"（桌面 → 移动）和 rel="canonical"（移动 → 桌面）。
第 4 步：每个视口都输出结构化数据
JSON-LD 不管屏幕多大都得在 HTML 里，里面的 URL 必须指向 canonical/移动 URL。永远别按视口宽度或 user-agent 条件注入。
第 5 步：内链不靠 JS 就能被发现
Hamburger 菜单里的链接应该是真正的 <a href> 元素、写在 HTML 里、由 CSS 隐藏，不是轻触时 JS 注入的：
<nav class="mobile-nav">
<a href="/categories/">Categories</a>
<a href="/authors/">Authors</a>
<a href="/archive/">Archive</a>
</nav>然后用 CSS 在 toggle 时切显隐。
第 6 步：meta 标签统一
确认 <meta name="robots">、<link rel="canonical">、<meta name="description"> 在桌面和移动视口完全一致。服务端渲染，不要靠 JS。
第 7 步：重提受影响的 URL
对齐做完后，对掉得最惨的页面打开 URL Inspection，点 “Request indexing”。Search Console 对手动提交大致限制在每个 property 每天 10-12 个 URL，所以排好优先级，其余的交给 XML sitemap。单个页面重新抓取一般 24-48 小时内会被拿到；曝光完全恢复通常要 4-8 周。
怎么确认修好了
- 实时测试：URL Inspection → “Test live URL” → “View crawled page” → “More info” → “HTML”。渲染后的 HTML 现在含有之前缺的文本、链接和 JSON-LD。
- 对齐 diff：重跑第 1 步那个
curl循环。桌面和移动字数差在 10% 以内。 - Search Console，2-4 周后：Pages 报告里有效页数回升，Performance 报告里受影响查询的曝光回来。按受影响页面过滤 Performance，专门盯这条曲线。
哪些情况可能不是你操作错了
Mobile-first 切换后曝光有一点波动是正常的，即使做到完全对齐——SERP 本身就会变。但集中在你自己页面上、超过 25% 的跌幅，基本都是内容对齐缺口，不是噪声。
容易误判的情况
误判成 Core Web Vitals 或 page experience 变化。Page experience 是真的有用，但它只是同等结果之间的 tiebreaker，单凭它不会抹掉 30% 的曝光。切 mobile-first 之后立刻的大跌，基本都是内容对齐问题，不是 CWV。（另外，2026 年初有个已知的 Search Console 报告 bug 造成过虚假的曝光下跌——动手修之前，先在实时的 Performance 报告里核实损失，别看缓存的仪表盘。）
预防建议
- 单一响应式代码库；不要搞 m-dot 子域。
- 移动端永远别把主内容卡在需要 JS 的交互之后。
- 所有结构化数据都在服务端渲染好的 HTML 里，里面写移动 URL。
- CI 抽样跑桌面 vs 移动 HTML diff。
- 每张图都审
alt，无论什么视口。
FAQ
- 能选择退出 mobile-first indexing 吗？ 不能。截至 2026 年 6 月它是唯一模式，没有开关，对有移动版的站也没有桌面兜底。
- Google 现在还看桌面内容吗？ 只对完全没有移动版的站作为罕见兜底。只要你有移动页，就当桌面独有的内容是看不见的。
- 移动端的 accordion 和 tab 安全吗？ 安全，只要文本在渲染好的 HTML 里。Google 会读折叠内容。危险的是要用户交互之后才加载的内容。
- 退掉 AMP 会伤排名吗？ 对几乎所有站来说不会。AMP 好几年前就没排名优势了，一个 Core Web Vitals 达标的响应式页面能打平。迁移时配好重定向，别让 canonical 断掉。
- 请求重新索引之后多久生效？ 单个 URL 一般 24-48 小时内被重新抓取，但受影响页面的曝光完全恢复通常要 4-8 周。