移动端优先索引下被降权的一个月：自适应改造与响应式验证的复盘
去年十月，我们接手了一家设备制造商官网的改版收尾。站点是老牌 ASP.NET 项目，桌面端多年积累，收录稳定，PC 端自然流量一直占七成以上。改版上线后第四周，客户在周报里丢来一句话：移动端流量掉了差不多一半，百度指数后台和 Google Analytics 的曲线都塌了。桌面端数据没动，塌的只有移动来源。这篇文章把那一个月的排查、改造和验证过程完整复盘一遍，重点讲清楚移动端优先索引（mobile-first indexing）机制下，一个「看起来没问题」的站点是怎么被降权的。
事故现场：桌面端正常，移动端塌方
先交代背景。这家厂商的官网历史包袱很重：2016 年前后做过一次「移动版」，当时的做法是单独建了一套 m 子域页面，模板里砍掉了大段产品参数、砍掉了案例展示，只留联系表单和几行简介。七年间桌面主站内容迭代了无数轮，m 站几乎没人维护，两边早就不是同一个站了。
十月改版的需求本来很简单：换视觉、换 CMS、统一域名。供应商交付的新站用的是所谓「自适应模板」，浏览器窗口缩到多窄都能看，验收时在手机上划了一圈，观感不错，签了字。
第 3 周，百度搜索资源平台的流量与关键词报告显示移动端点击量从日均 1400 左右跌到 600 出头；Google 那边 Search Console 的效果报告同步下滑，移动设备占比从 58% 掉到 34%。桌面端两条曲线纹丝不动。这个特征很关键——如果整站被惩罚，两端应该一起跌；只跌移动端，问题大概率出在「移动端抓取到的页面」上，而不是内容质量或外链。
排查过程：两套工具，两条线索
Google Search Console 的网址检查
我们最早怀疑是新站上线后的正常波动，等了一周没有回升，才开始动手。第一步用的是 Google Search Console 顶部的网址检查（URL Inspection）工具，把核心产品页的 URL 丢进去，点「测试实际网址」。
这个工具有个很多人忽略的能力：测试完成后可以分别查看「已抓取的网页」，而且能在设置里切换用户代理（User-Agent），分别以桌面端 Googlebot 和智能手机版 Googlebot 两种身份请求同一 URL。我们把两种 UA 的抓取结果并排对比，差异一目了然：
- 智能手机版 Googlebot 抓到的 HTML 里，正文段落只有桌面版的四分之一左右，产品参数表整个消失；
- 页面
<head>里的部分 meta 描述在移动版本里是空的； - 结构化数据报告显示，桌面 UA 抓取能解析出 Product 和 Organization 两个 JSON-LD 块，移动 UA 抓取只能解析出 Organization，Product 块不存在。
顺带用命令行复现了一遍，确认这不是 GSC 的显示问题：
# 用智能手机 Googlebot 的 UA 抓取页面，统计正文容器内的文本量
curl -s -A "Mozilla/5.0 (Linux; Android 6.0; Nexus 5) AppleWebKit/537.36 Chrome/89.0 Mobile Safari/537.36" \
https://example.com/products/xyz-300 | grep -o 'product-detail' | wc -l
# 再用桌面版 Googlebot 的 UA 抓同一个 URL，做对照
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
https://example.com/products/xyz-300 | grep -o 'product-detail' | wc -l
两次输出的次数不一样，说明服务器在根据 UA 返回不同 HTML。也就是说新站虽然换了皮，但底层还残留着旧的 UA 判断逻辑——检测到移动 UA 就重定向或输出精简模板，而这个精简模板继承自那个七年没维护的 m 站。
百度搜索资源平台的移动友好度检测
Google 这边的证据链完整了，但国内流量主要来自百度，还得在百度侧验证。百度搜索资源平台提供了移动友好度检测，把同一批产品页 URL 逐个提交，结果里明确标出两类问题：页面加载后被截断的正文区域，以及「资源无法被爬虫获取」的告警。部分页面还提示标题与页面内容相关性弱——因为移动版输出的 <title> 是模板默认值，和桌面版精心写的标题完全不同。
两套工具指向同一个结论：百度和 Google 的移动爬虫抓到的都是那份残缺的移动 HTML，索引库里存的其实是残缺页。排名自然按残缺页算，流量下滑不是惩罚，是「移动端优先索引」机制下的一次精准反映——爬虫看见什么，就索引什么。
根因定位：移动端到底缺了什么
我们把新旧两套模板做了逐项 diff，缺的东西比预想的多。整理成一张清单：
| 缺失项 | 桌面版 | 移动版（改造前） | 对索引的影响 |
|---|---|---|---|
<title> 与 meta 描述 |
逐页定制 | 模板默认值或为空 | 快照标题错乱，点击率下降 |
| 正文段落与参数表 | 完整 | 删减约六成 | 内容相关性信号缺失 |
| Product JSON-LD | 有 | 无 | 富摘要与实体识别失效 |
| 图片 srcset 与 alt | 有 | 无 alt，单尺寸大图 | 图片搜索流量归零 |
| 规范标签 canonical | 指向自身 | 缺失 | 移动页与桌面页判定混乱 |
定位过程里有个教训值得记下来：验收阶段所有人都在真机上「看」页面，没人用爬虫 UA「抓」页面。页面渲染给人和渲染给爬虫是两条完全不同的路径，前者看视觉，后者看 HTML 源码。移动端适配做得好不好，最终裁判是爬虫的解析器，不是人眼。
响应式改造要点
根因清楚了，改造方案没有悬念：放弃 UA 判断输出双模板的做法，改成标准的响应式设计（Responsive Web Design），让同一个 URL 对所有设备返回同一份 HTML，布局差异交给 CSS 处理。Google 官方文档对移动端站点给了三种实现路径——响应式设计、动态服务、独立网址，并明确推荐响应式，因为它最不容易出错。百度同样支持响应式，且在移动友好度标准里对自适应布局有明确加分项。
改造时我们守住了几条线：
同一 URL 同一 HTML。 删掉所有 UA 检测和跳转逻辑，服务器对所有 UA 返回同一份 HTML。这是移动端优先索引成立的前提，也是这次事故的总根源。
viewport 元数据。 每个页面 <head> 里必须有正确的 viewport 声明，这是响应式的开关：
<!-- viewport 必须包含 width=device-width，让布局宽度等于设备宽度 -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- initial-scale 禁止设成大于 1 的值，否则首屏会被放大裁切 -->
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">
<!-- 禁止出现 user-scalable=no 这类限制缩放的写法，会被判定为移动不友好 -->
<!-- 页面主体内容不要依赖横向滚动，宽度超出 viewport 的表格要给容器加 overflow 处理 -->
断点与媒体查询。 用 CSS 媒体查询（media query）按视口宽度切换布局，断点不追求数量，覆盖主流设备即可：
/* 基础样式：移动优先，默认按小屏写一列布局 */
.product-list { display: block; padding: 12px; }
/* 平板断点：768px 以上切成两列网格 */
@media (min-width: 768px) {
.product-list { display: grid; grid-template-columns: 1fr 1fr; gap: 16px; }
}
/* 桌面断点：1200px 以上三列，并恢复侧边导航 */
@media (min-width: 1200px) {
.product-list { grid-template-columns: 1fr 1fr 1fr; }
.side-nav { display: block; }
}
/* 关键内容禁止 display:none 隐藏——移动端隐藏的内容爬虫一样会拿到， */
/* 但两端内容必须一致，不能靠 CSS 在桌面端补一份不同的文案 */
图片自适应。 用 srcset 和 sizes 按设备分辨率下发合适的图片，同时补齐 alt 文本，把图片搜索的流量口子重新打开。
结构化数据全量补齐。 Product、Organization、BreadcrumbList 三组 JSON-LD 在统一模板里输出，不再区分设备。这一步在一个月后的验证里带来了最直接的正反馈，富摘要恢复得比排名更快。
百度与 Google 在移动端处理上的几个差异点，也在这轮改造里摸清了：
| 差异点 | 百度 | |
|---|---|---|
| 索引基准 | 移动端优先索引已全量，以移动 UA 抓取为准 | 对自适应站点同样以移动抓取评估，未全量迁移的站点仍可能双端抓取 |
| 工具入口 | Search Console 网址检查 + 移动设备适合性测试 | 搜索资源平台的移动友好度检测与抓取诊断 |
| 转码/适配声明 | 不使用转码 | 历史上有转码机制，自适应站点需正确声明以避免被转码 |
| 生效速度 | 抓取调整后数天到两周 | 依赖抓取频次，小站点可能要三四周 |
原理剖析：索引管线为什么只认移动 UA
很多人到这一步还是会问：桌面版内容明明是全的，为什么搜索引擎不参考？这就要看移动端优先索引的管线到底怎么工作。
Google 从 2018 年开始推行移动端优先索引，到 2021 年 7 月官方宣布绝大多数站点已完成切换。切换之后，索引管线的主抓取队列里，智能手机版 Googlebot 是主力抓取器——桌面 UA 的抓取被降级为补充校验，不再是索引的输入源。也就是说，在「抓取 → 解析 → 建索引 → 排序」这条链路的第一环，决定库里存什么的，就是移动 UA 那一次请求返回的 HTML。
flowchart LR
A[调度器生成抓取任务] --> B[以智能手机版 UA 请求 URL]
B --> C{服务器是否按 UA 出不同 HTML?}
C -- 是 --> D[拿到精简版 HTML]
C -- 否 --> E[拿到统一完整 HTML]
D --> F[解析正文/标题/结构化数据]
E --> G[解析正文/标题/结构化数据]
F --> H[索引库存入残缺页<br/>相关性信号缺失]
G --> I[索引库存入完整页]
H --> J[移动端查询命中时<br/>排名与摘要按残缺页计算]
I --> K[排名与摘要按完整页计算]
为什么 Google 要这么设计？官方给的理由很朴素：来自移动设备的搜索占比早已过半，索引以移动版为准，才能保证用户在移动搜索结果里点开的页面和索引评估的是同一个东西。对百度同理——国内移动搜索占比更高，资源平台的评估体系整体围绕移动体验搭建。机制本身没有针对谁，它只是把「移动端内容」当成了站点内容的本体；桌面版在管线里退成了一个参考副本。你给移动端爬虫看什么，搜索引擎就认为你的站点是什么。理解了这一点，这次事故就不神秘了：不是算法打击，是站点主动向索引库提交了一份残缺的自我介绍。
验证：工具、渲染对比与数据
改造分两批上线：第一批是核心产品页，第二批是案例与新闻栏目。上线后的验证做了三层。
第一层是工具验证。Google 侧用 Search Console 的网址检查复核，两种 UA 抓取的 HTML 完全一致，结构化数据报告恢复 Product 项；再用官方的移动设备适合性测试（https://search.google.com/test/mobile-friendly）批量过页面，全部通过。百度侧重新跑移动友好度检测，截断与告警清零。
第二层是抓取渲染对比。对改造前后的页面各存了一份移动 UA 抓取快照，逐项核对标题、正文段落数、JSON-LD 块数、图片 alt 覆盖率，确保模板切换没有遗漏栏目。
第三层是数据。以下是改造后六周，以单站观测口径记录的对照数据（样本只有这一个站点，不具备普遍统计意义，仅供参考）：
| 指标 | 改造前（第 3 周） | 改造后第 2 周 | 改造后第 6 周 |
|---|---|---|---|
| 百度移动端日均点击 | 约 600 | 约 850 | 约 1350 |
| Google 移动端日均点击 | 约 420 | 约 560 | 约 780 |
| 百度移动收录量（核心栏目） | 1200 页 | 1500 页 | 2100 页 |
| 核心词移动端排名（前 10 个词） | 平均 21 位 | 平均 16 位 | 平均 9 位 |
| Product 富摘要展示 | 无 | 部分恢复 | 全量恢复 |
几个观察：收录量回升得比排名快，说明管线重建索引需要时间，排名是收录刷新之后的滞后指标；富摘要恢复几乎与新模板被抓取同步，结构化数据的红利兑现最直接；到第 6 周，移动端流量不仅收复失地，还因为内容补全超过了改版前水平——毕竟移动版从「简介页」变成了「完整站」。
排查与改造的完整路径，浓缩成一张流程图：
flowchart TD
A[移动端流量下滑 桌面端正常] --> B[Search Console 网址检查<br/>切换桌面/移动 UA 对比抓取]
B --> C{两端 HTML 是否一致?}
C -- 一致 --> D[排查外链/算法更新等其他因素]
C -- 不一致 --> E[百度移动友好度检测交叉验证]
E --> F[逐项 diff 定位缺失项<br/>标题/正文/JSON-LD/meta]
F --> G[响应式改造<br/>同一 URL 同一 HTML]
G --> H[移动友好性测试 + 渲染对比复核]
H --> I[分批上线 观察收录/排名/流量 4-6 周]
误区澄清与收尾
这一个月里反复出现的几个误区，值得单独拎出来。
一是「模板自适应等于移动端适配」。视觉上能缩放只是表象，适配的验收标准是移动 UA 抓到的 HTML 与桌面等价。二是「移动端可以适当精简内容」。在移动端优先索引机制下这个思路已经不成立——精简掉的每一段正文，都是索引库里缺失的相关性信号。三是「等流量掉了再查」。移动端适配问题完全可以在上线前用网址检查类工具做验收拦截，成本十分钟，代价是一周的开发排期。
趋势层面多说一句：搜索引擎的抓取评估正在全面向「移动端 + 渲染后 DOM」收敛，而生成式引擎优化（Generative Engine Optimization, GEO）所面向的 AI 爬虫，同样以单页完整 HTML 为解析对象——移动端内容做扎实，对传统 SEO 和 AI 引用是同一份基础设施。
如果这篇文章帮你避开了某个坑，欢迎在评论区交流你遇到的抓取与适配问题，典型的case我们可以拆开一起看。
参考与延伸
移动端优先索引、响应式设计、Google Search Console、百度搜索资源平台、收录下降、搜索引擎抓取、网址检查