Google 搜索中的 Signed Exchange 实战指南

💡 核心摘要：Signed Exchange（SXG）允许 Google 搜索以注重隐私的方式预提取页面关键资源。用户点击搜索结果时，HTML、CSS、JS、图片或字体等资源可能已经可用，从而更快开始渲染并改善 LCP。SXG 不是内容质量替代品，也不是所有网站都必须接入的 SEO 基建。

一、Signed Exchange 是什么

Signed Exchange，简称 SXG，是一种 Web Packaging 技术。它允许第三方缓存分发由原始站点加密签名的内容，同时保持浏览器地址栏显示原始网址。

在 Google 搜索中，SXG 的主要价值是预提取。Google 搜索可以在保护用户隐私的前提下，提前获取页面关键资源。用户真正点击结果时，页面能更快开始渲染。

这对 Largest Contentful Paint（LCP）尤其相关。首屏关键内容更快出现，整体网页体验也可能改善。

二、SXG 适合解决什么问题

SXG 主要适合已经有较好内容和技术基础，但仍想进一步优化搜索点击后首屏加载的网站。

例如新闻站、内容站、电商活动页、文档站和高流量落地页，如果搜索点击占比高，且 LCP 受网络延迟、跨地区访问或关键资源加载影响，SXG 可能有价值。

但如果网站目前存在内容质量差、不可索引、移动端混乱、广告遮挡或 JS 严重阻塞等基础问题，优先级应放在基础修复，而不是直接接入 SXG。

三、SXG 如何改善用户体验

普通搜索点击流程中，用户点击结果后，浏览器才开始请求页面和关键资源。网络延迟、服务器响应、TLS、HTML 下载、CSS/JS/图片加载都会影响首屏。

使用 SXG 后，Google 搜索可能提前预提取关键资源。当用户点击结果时，这些资源已经可用，页面更快进入渲染流程。

官方文档指出，这可能改善 LCP，从而对整体网页体验有帮助。

💡 SXG 的价值来自“更早准备资源”，不是改变页面内容、排名信号或搜索结果标题。

四、实现前先确认技术成本

SXG 不是简单添加一个 meta 标签。它涉及服务器、证书、签名、缓存、内容有效期、设备适配、Cookie 个性化、调试和监控。

通常需要工程团队理解 Web Packager、NGINX SXG 模块、证书要求和缓存行为。对小型内容站来说，如果当前性能问题可以通过图片优化、缓存、CDN、减少 JS 解决，就不一定要优先接入 SXG。

建议把 SXG 看作高级性能优化，而不是 SEO 入门必做项。

五、设置合适的失效日期

Google 会使用 SXG 缓存预提取内容，并可能多次提供缓存的 SXG。因此，缓存新鲜度非常重要。

官方要求应适当设置 SXG 的失效日期。一般来说，失效日期应早于 HTTP 标头确定的缓存失效日期，并且如果内容是 JavaScript 或内联 JavaScript，应早于 1 天后；否则应早于 7 天后。

这能降低用户看到过期内容的风险，尤其适合新闻、价格、库存、活动、用户状态和动态内容。

六、处理个性化内容和 Cookie

SXG 最容易踩坑的场景之一，是页面包含个性化内容，例如购物车、登录状态、会员价格、推荐内容或地区化结果。

官方建议把个性化内容迁移到 SXG 外部的延迟加载元素中。另一种方式是添加带有 Vary: Cookie 签名的标头，这样带有该标头的 SXG 只会向没有 Cookie 的访问者显示。

如果处理不好，用户可能看到不适合自己的缓存状态，或者缓存命中被大幅削弱。

七、保证多设备正确显示

Google 还要求确保内容在多种设备上提供时能正确显示。

最稳妥方式是采用响应式设计，让同一个 URL 根据设备自适应。如果使用独立移动 URL 或桌面 URL，需要正确处理对应关系。

如果页面不是响应式网页，可以使用 supported-media meta 标记声明页面适用媒体条件。

<meta name="supported-media" content="only screen and (max-width: 640px)">

但对现代站点而言，响应式设计通常更简单，也更不容易在 SXG 缓存和设备适配中出错。

八、监控和调试 SXG

SXG 上线后必须监控和调试。官方提供了 SXG 工具指南，也提到可以使用 SXG Validator Chrome 扩展检查是否符合 Google SXG 缓存要求。

如果 Googlebot 无法解析 SXG，可能会重新抓取不带 application/signed-exchange;v=b3 Accept 标头的 URL，以获取普通 text/html 版本。

如果出现 SXG 索引编制错误，Google 搜索会链接到未实施 SXG 的原始 URL。也就是说，SXG 失败不一定让页面完全消失，但会让预取和性能收益失效。

九、调试 Google SXG 缓存

Google SXG 缓存有对应的缓存 URL 格式。你可以直接查询缓存 URL，判断响应是否为 SXG。

如果响应是 SXG，说明源服务器响应符合 Google SXG 缓存要求。如果不是，响应可能包含说明原因的 HTTP 标头。

常见信号包括：Warning 标头表示存在错误导致 SXG 不符合缓存要求；Location 标头表示资源尚未被缓存系统提取，这不一定是 SXG 本身错误。

缓存系统可能会把原始 URL 加入队列获取最新副本。Googlebot 抓取速度、站点更新频率和缓存规则都会影响刷新。

十、AMP 页面怎么处理

对于 AMP 页面，应按照 AMP 的 SXG 指南实现，并使用 Search Console 中的 AMP 状态报告监控 SXG 错误。

AMP 生态对缓存和预加载有自己的机制。不要把非 AMP SXG 实现方式直接套到 AMP 页面上。

如果网站已经从 AMP 迁移到响应式页面，也要检查旧 AMP 关系、canonical、缓存和 SXG 配置是否仍然存在遗留问题。

十一、什么时候不建议优先做 SXG

以下情况不建议把 SXG 放在优先级前面：页面还没有稳定索引，内容质量不足，移动端不可用，广告和弹窗遮挡正文，LCP 慢主要来自未优化图片或服务器响应，前端 JS 长任务严重，团队没有能力监控缓存和签名问题。

SXG 能帮助缩短用户点击后的资源准备时间，但不能替代基础性能优化。它更适合“基础已经不错，想进一步提升搜索点击体验”的站点。

📌 核心收获

• ✓ SXG 用于隐私保护预取：Google 搜索可提前获取关键资源。
• ✓ 主要收益是改善加载体验：尤其可能帮助 LCP 和首屏渲染。
• ✓ 实现成本较高：涉及签名、缓存、失效日期、Cookie、设备适配和调试。
• ✓ 失效日期要谨慎设置：JS 或内联 JS 通常不超过 1 天，其他内容通常不超过 7 天。
• ✓ 个性化内容要外置或用 Vary: Cookie：避免错误缓存用户状态。
• ✓ SXG 不是基础 SEO 替代品：先修内容、索引、移动端和常规性能问题。

🚀 立刻行动

1. 先用 Search Console 和 PageSpeed Insights 判断 LCP 问题是否来自基础资源优化。
2. 如果搜索点击流量大且基础性能已较好，再评估 SXG 接入成本。
3. 与工程团队确认服务器、证书、Web Packager 或 NGINX SXG 模块实现方案。
4. 梳理页面中的个性化内容，把购物车、登录态、推荐等迁移到延迟加载区域。
5. 设置合理 SXG 失效日期，避免缓存过期内容。
6. 使用 SXG Validator 和 Google SXG 缓存 URL 检查缓存要求。
7. AMP 页面使用 Search Console 的 AMP 状态报告监控 SXG 错误。

来源：开始在 Google 搜索中使用 Signed Exchange | 本文为知识提炼与重新表达