Search Console 发通知：“Your site is now indexed mobile-first”。一两周后，Pages 报告里有效页数往下走，曝光掉了 15-40%。Mobile-first 意思是 Google 用你页面的移动渲染作为排名用的 canonical 版本。桌面版有的、移动版没有的东西——内容、结构化数据、内链、alt 文本——对 Google 来说基本就消失了。
本文聚焦的是被丢掉的桌面端信号，不是 mobile usability（另文）。修法核心是让移动版在内容上跟桌面版对齐。
常见原因
1. 移动版把内容塞进 tab / accordion，但没渲染进 HTML
桌面显示完整文章。移动为了适配小屏，用 accordion 通过 JS 懒加载段落内容。Googlebot 渲染移动版，但爬虫不触发 accordion 的 JS。藏起来的内容继续藏着。
怎么判断：在移动 URL view source（或 DevTools 移动模拟，注意要 “View source” 不是 “Inspect”）。如果章节正文不在 raw HTML 里，那就不在索引里。
2. 移动站是独立 m.example.com 子域且内容更薄
老的 m-dot 架构。移动站是好几年前做的，引语短、没有 FAQ、没有相关链接。Google 现在把 m.example.com 当 canonical，桌面那些更丰富的内容被忽略。
怎么判断：m.example.com/article/x 和 www.example.com/article/x 并排对比。数字数、数内链。移动版明显更短就是它。
3. 结构化数据只在桌面模板里
桌面输出 Article、FAQPage、Breadcrumb JSON-LD。响应式模板在小视口”为减小 payload”跳过 JSON-LD。Rich result 消失。
怎么判断：移动 URL → view source → grep application/ld+json。和桌面 view source 对比数量和类型。
4. 桌面侧边栏的内链在移动端被藏起来
桌面有 sidebar 列 20 条相关文章、作者 bio、归档链接。移动把所有东西塞进 hamburger 菜单，JS 加载。Googlebot 失去这些内链信号。
怎么判断：curl -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0)" https://yoursite.com/article/x，数 <a href= 个数。和桌面 UA fetch 对比。
5. 移动版图片 alt 缺失或 srcset 不一样
桌面 <img alt="详细 alt 文本">；移动用了另一个 <picture> 没 alt，或者用缩略图版本。Image Search 排名直接崩。
怎么判断：移动 view source → grep <img。找漏掉 alt= 的、或者跟桌面图片 URL 不同的。
6. Robots meta 或 canonical 在两个视口不一致
模板 bug：只在移动视口输出 <meta name="robots" content="noindex">（或反过来）。或者 canonical 根据 user-agent 指向不同 URL。
怎么判断：同一个 URL 用桌面 UA 和移动 UA 各 fetch 一次。对比 <meta name="robots"> 和 <link rel="canonical">。任何差异都是 bug。
7. AMP 页作为移动 canonical 但渲染坏了
之前用 AMP 当移动 canonical 的，AMP 校验错误或缺内容就直接伤害非 AMP 页索引。
怎么判断：Search Console → AMP 报告。任何错误现在都会影响排名。
最短修复路径
第 1 步：做内容对齐审计
挑 20 个代表页。每个抓桌面 HTML 和移动 HTML。对比字数、链接数、结构化数据块、图片数、alt 文本。
for url in /article/a /article/b /category/c; do
echo "=== $url ==="
curl -s -A "Mozilla/5.0 (X11; Linux)" "https://yoursite.com$url" | wc -w
curl -s -A "Mozilla/5.0 (iPhone)" "https://yoursite.com$url" | wc -w
done差异 > 10% 都得补齐。
第 2 步：accordion / tab 内容写进 raw HTML
哪怕用 CSS 藏或者 tab UI 折叠，内容必须在渲染好的 HTML 里，不能等用户点击才 JS 拉。
<!-- 坏：点了才渲染 -->
<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 里。永远别按视口宽度或 user-agent 条件注入。
第 5 步：内链不依赖 JS 就能被发现
Hamburger 菜单应该是 CSS 隐藏的 HTML 链接，不是点击时 JS 注入的链接：
<nav class="mobile-nav">
<a href="/categories/">Categories</a>
<a href="/authors/">Authors</a>
<a href="/archive/">Archive</a>
</nav>然后用 CSS 类切显示隐藏。
第 6 步：meta 标签统一
确认 <meta name="robots">、<link rel="canonical">、<meta name="description"> 在桌面和移动视口完全一致。服务端渲染，不要靠 JS。
第 7 步：重提受影响的 URL
对齐做完后，URL Inspection → “Request indexing”，挑影响最大的 20-50 个页面。完全恢复一般 4-8 周。
哪些情况可能不是你操作错了
Mobile-first 切换后一点点曝光跌是正常的，即使做到完全对齐——SERP 本来就会变。但 > 25% 的跌幅基本都是内容差距问题，不是正常波动。
容易误判的情况
误判成 Core Web Vitals 或 page experience 更新。Page experience 有影响，但只是 tiebreaker。切 mobile-first 之后立刻 30% 曝光跌，基本都是内容对齐问题，不是 CWV。
预防建议
- 单一响应式代码库；不要搞 m-dot 子域。
- 移动端永远别把内容卡在需要 JS 的交互之后。
- 所有结构化数据都在服务端渲染好的 HTML 里。
- CI 抽样跑桌面 vs 移动 HTML diff。
- 每张图都审 alt，无论什么视口。
FAQ
- 能选择退出 mobile-first indexing 吗？ 不能——2023 年起所有站都默认 mobile-first。
- Google 现在还看桌面内容吗？ 很少——只对完全没有移动版的站。别指望。