谷歌开始给“隐形换页”记账了

一个用户在电商站里连续筛选了十几页商品，从传统网页指标的角度看，他只“打开”了一个页面。

Google 把实验性的软导航（Soft Navigation）指标加入了 Chrome UX Report（CrUX），用来统计应用内的页面切换，Search Console 也将跟进展示。这件事乍看是搜索工具箱里的一次小更新，但它的实质是：谷歌正在重新校准“什么算一次页面访问”。

对做惯了整页加载优化的人来说，这可能只是遥远的技术新闻；但对那些把大半个站点做成单页应用（SPA）的团队来说，这是一场迟到多年的测量补课——你的真实用户体验，终于要被完整看见了。

🕳️ 被漏掉的那一半用户旅程

先讲一个所有技术 SEO 都见过的场景。

一个内容站把列表页改成了 SPA：用户点进文章，正文内容换了，但 URL 只是靠 History API 悄悄推了一个新地址，页面没有传统意义上的“加载完成”事件。运营后台里，一次会话的页面浏览数、加载速度、交互体验，全都和用户实际看到的东西对不上。

更麻烦的是 Core Web Vitals 这套指标。LCP（最大内容绘制）、INP（交互到下一次绘制延迟）、CLS（累积布局偏移），传统上都锚定在“硬导航”——也就是浏览器完整加载一个新页面的过程上。SPA 里那种“点了按钮、内容切换、但没有整页刷新”的软导航，长期游离在这套体系之外。

这次的更新就是在填这个洞。根据 Search Engine Journal 的报道，Google 将统计应用内页面切换的实验性核心网页指标加入 CrUX，并计划在 Search Console 中跟进。

⚙️ 软导航到底是怎么被“记账”的

在讨论影响之前，值得先把测量机制说清楚，因为这直接决定了你的站点会不会被“记上一笔”。

根据 Chrome 团队在 web.dev 上发布的官方说明，软导航的判定是一套启发式规则，核心条件包括：

• 用户主动交互触发：由页面内的点击等交互引发，而不是脚本自动变更；
• URL 发生同源变化：通过 History API（pushState / replaceState）更新地址，且新地址与当前页面同源——跨域跳转本身就会触发硬导航，不在软导航统计之列；
• 页面内容发生明显更新：URL 变了、用户看到的内容也真的换了一大块，才被认定为一次“导航”。

一旦某次交互被判定为软导航，三项核心网页指标就会在这次“隐形换页”上重新记账：LCP 会按软导航重新选取并报告最大内容绘制，相当于每次应用内换页都有一份自己的“加载成绩单”；CLS 的布局偏移归因会按软导航重新划分，切换过程中的内容跳动不再被摊进上一个页面的账本；INP 也会按软导航归因交互延迟，让“点了按钮半天没反应”这类问题有了明确的测量对象。

同时也要注意官方口径里的边界：浏览器的前进/后退按钮、页面不可见时的变化等情形，不会被当作软导航计入。这和 CrUX 的整体原则一致——所有数据都来自真实用户（RUM）的现场数据，按 28 天窗口聚合，不含实验室模拟数据。目前这些指标以实验性（Experimental）身份出现，意味着谷歌仍可能调整判定规则与呈现方式，正式转正前不宜将结论钉死。

这里的产业逻辑很直接：测量口径决定优化优先级。

一个指标只有被看见，才会被排进迭代排期。过去十年，SPA 的交互体验问题之所以在技术 SEO 的待办清单里排名靠后，很大程度不是因为它不重要，而是因为现有指标“看不见”它。口径一改，资源的流向就会跟着变。谷歌很清楚这一点——把指标放进 CrUX 和 Search Console，就等于把它推到了每一个网站所有者的年度复盘会上。

🧩 SPA 十年，欠下的测量债

要理解这次补课，得先看懂这笔债是怎么欠下的。

过去十来年，前端技术的主流方向就是“去页面化”。主流框架让开发者可以只更新页面的一部分，用户全程感知不到传统意义的跳转。技术上这是巨大的进步：更少的白屏、更接近原生应用的流畅感。

但对测量体系来说，这是一场持续的错位。指标是按“页面”设计的，产品却是按“应用”做的。

“说明：上图是作者基于公开资料的粗略梳理，用于呈现“技术形态先行、度量标准滞后”的宏观脉络，节点年份为大致区间，不应作为精确的官方时间线引用。

错位带来的结果是双重的：

一方面，做了大量应用内交互优化的站点，这些努力在 Core Web Vitals 报告里体现不出来，等于白干；另一方面，SPA 在软导航过程中出现的性能劣化——切换卡顿、内容闪烁、焦点丢失——也不会在报告里被扣分，反而可能让团队产生“我们指标很好”的错觉。

从行业里的普遍情况看，这几年不少 SPA 站点在做技术体检时，都需要额外自建 RUM（真实用户监测）来补齐官方口径的盲区，才能看清应用内部的体验真相（这一点属于作者的行业观察，而非来自某项官方统计）。谷歌这次把软导航指标正式纳入官方报告，等于把过去各家自己“打野路子”补的课，收编进了标准体系。

这笔债的本质是：技术形态跑在了度量标准前面，现在标准开始追了。

🎯 四象限：谁最该紧张

这次更新对不同站点的影响完全不对称。我们把典型的站点类型放进两个维度里看：横轴是完成软导航测量改造的技术门槛，纵轴是站点对搜索流量的暴露程度（也就是被这次口径变化波及的商业风险）。

“说明：图中各站点的坐标为作者的定性判断，仅用于示意相对位置，不代表精确测算。

右上象限是风险最高的群体：电商和内容类 SPA 站点。它们既是重度搜索流量依赖者，又是应用内换页的重度使用者。过去它们享受了 SPA 的技术红利，如今也要第一个面对新口径下的重新打分。

左下象限是传统多页架构的官网：页面切换天然就是硬导航，新旧口径差异不大，基本可以旁观。

值得注意的是 SaaS 和后台型产品——它们技术形态最像应用，但对搜索流量依赖低，软导航指标对它们更多是产品体验优化工具，而非 SEO 生死题。

同一个信号，对不同玩家是不同的棋局。看清自己在哪个象限，比急着动手更重要。

🛠️ 团队现在该做什么

判断更新性质之后，下一个问题是：这次要不要立刻砸资源？

先看时间节奏。谷歌给这类指标的惯例路径是：先以实验性身份进入 CrUX，观察数据质量与开发者反馈，再决定是否转正并纳入 Search Console 正式视图。（这一路径是基于以往指标的惯例推演，属于作者的分析判断，非官方承诺。）基于这个惯例，一个合理的行动节奏大致是：

具体到动作层面，核心是把“痛点”和“解法”对应清楚：

我把新旧两套口径的差异整理成一张对照表，方便团队内部对齐：

一句话原则：实验期做监测，不做豪赌。 押注指标会转正，但不押注指标的具体算法不会变。真正稳健的动作是把自家 SPA 的换页体验摸清楚——无论指标怎么变，真实的用户体验不会变。

💡 产业逻辑：定义指标的人，定义议程

最后说一层更宏观的判断。

谷歌每隔一段时间就会对“网页”这个基本单位做一次重新定义。上一次是移动优先索引，把“移动端看到的东西”定为标准答案；这一次是对软导航的收编，把“应用内发生的事”也纳入搜索体验的账本。

这里面有一个容易被忽略的权力结构：指标即议程。

当 Core Web Vitals 只认硬导航时，全行业的性能预算、招聘重点、外包合同里的验收条款，都围绕硬导航展开。一旦软导航指标转正并可能进入排名信号体系（注意：目前它还只是实验性指标，谷歌并未承诺其在搜索排名中的角色，以下产业影响推演均为分析观点），新的优化产业会随之生长——监测工具要加功能，代理商会卖新服务，工程团队的 OKR 要重写。

对营销侧的管理者，我的建议是三条：

第一，别把这次当成纯技术新闻。软导航数据的出现，意味着你的 SEO 团队和前端团队之间的沟通界面要重画——过去“指标不好找后端”，现在“应用内体验不好找前端”。

第二，警惕两类极端反应。一类是无动于衷，等指标转正后再手忙脚乱；另一类是过度反应，实验指标刚出就推倒重做架构。多数团队的最优解在中间：先把监测补上，把看不见的看清楚。

第三，把这次更新当作一次免费的架构健康检查。如果你的站点在软导航口径下表现会明显恶化，那说明问题早就存在，只是旧指标替你遮住了。

小结

谷歌把软导航指标放进 CrUX、并计划跟进 Search Console，表面是一次工具更新，实质是对 SPA 时代测量债的一次系统性清偿。测量机制上，它以“用户交互 + 同源 URL 变化 + 内容明显更新”的启发式判定软导航，并让 LCP、CLS、INP 在每次应用内换页上单独记账——数据依然来自真实用户现场数据，只是账本终于摊开了。

对重度依赖搜索流量、又大量使用应用内换页的站点，这是必须跟进的信号；对多页架构站点，这是一次低成本旁观的机会窗口；对整个产业，这是“指标定义权”的又一次行使。

接下来的关键观察点有两个：一是实验性指标何时转正、判定规则是否稳定；二是它最终是否与搜索排名产生关联——在谷歌给出明确表态之前，任何关于排名影响的说法都应视为推测。在那之前，最聪明的动作是——先看见，再优化。