PWA 的 SEO 难题：渐进式 Web 应用会在哪些地方掉链子（2026）

多数讲 PWA 与搜索的文章，都把两者的关系写成一边倒的利好：PWA 快，快的站点排名好，所以 PWA 排名好。这话用在成品上没错，用在通往成品的路上就有误导性。PWA 的 SEO 难题是真实存在的，而且是结构性的、不是表面问题，根源基本都能归到一件事上——PWA 是一个碰巧住在某个 URL 上的应用，而搜索引擎是一套默认「URL 就是一篇文档」的系统。

本文写的是这件事的失败面。如果你想先看正面案例，之前那篇 如何借助 PWA 提升 SEO 排名 已经讲过。下面讲的是通常会出什么问题。

为什么 PWA 会有普通站点没有的 SEO 问题

传统站点交给爬虫的是一篇文档。PWA 交出去的通常是一个应用外壳，外加一份「怎么把文档拼出来」的说明。所有难题都是从这个差异往下派生的：爬虫看到了什么、有没有及时看到、每个视图有没有自己的地址、缓存副本和新访客拿到的内容是否一致。

这些都不是无解的问题。但它们都静默发生——你不会收到任何报错，你得到的是一个技术上在线、功能上隐形的页面。

难题一：客户端渲染，与 Google 实际索引到的东西

Googlebot 会执行 JavaScript，但渲染是第二轮，有自己的排队队列。第一轮它看到的是你的原始 HTML。如果那份 HTML 只有一个空的 <div id="app">，那你在意的一切——标题、正文、内链、结构化数据——就全都押在渲染那一轮能否顺利完成上。

实际会出的问题：

• 渲染被推迟。 页面被发现了，但卡在渲染队列里，于是收录比发布晚上好几天甚至几周。
• 渲染部分失败。 一个脚本报错、一个被拦截的资源、一个永远不返回的请求，都会让爬虫拿到一个半成品页面，而且不会有任何「这里缺东西」的信号。
• 内容依赖交互才出现。 藏在点击、滚动触发、懒加载 tab 后面的内容，经常根本不会被看到。

解法是别让主要内容依赖客户端执行：需要排名的页面做服务端渲染或预渲染，把关键内容、标题和链接放进首个 HTML 响应里。验证要看渲染后的 HTML，别用自己的浏览器打开看一眼就算数——你的浏览器不是那个约束条件。

难题二：路由、URL 与单页应用陷阱

搜索索引的是 URL。一个切换视图却不换地址的应用，在索引眼里就是一个页面。

典型症状是：站点有四十个界面、索引里只有三个 URL；或者内容只存在于井号锚点之后。相关的坑还有：路由能访问、但没有任何可爬取的 <a href> 指向它；以及把翻页完全做成状态。

解法：每个需要被索引的视图都要有独立、干净、服务端能解析的 URL，能通过真正的 <a> 标签抵达，直接请求时返回正确的状态码——包括对不存在的内容返回真正的 404。一个对任何路径都返回 200 空壳的路由，比 404 更糟，因为它会凭空制造出无限多的薄页面。

难题三：Service Worker 缓存把过期内容发出去

Service Worker 是 PWA 「秒开」体感的来源，同时它也是一层由你控制、夹在内容和所有请求方之间的缓存。策略写错，你可能会把几个月前的页面副本、甚至离线兜底页，发给爬虫。

解法：HTML 文档用「先用缓存但同时回源校验」这类会重新验证的策略，别用 cache-first；激进缓存只用于带哈希文件名的静态资源；并确保离线兜底页永远不会被返回给一个可能是爬虫的请求。发版时给缓存打版本号并清理旧版本。

难题四：信号被稀释和重复

PWA 比静态站更容易堆出近似重复的地址：同一份内容同时挂在根路径和应用路径下、带不带尾斜杠的两个版本、并不改变内容的查询参数状态、以及单独的移动版或应用外壳入口。

解法：每个可索引视图都要有自指的 canonical，而且要由解析后的路由生成，不要用当前浏览器地址生成；不改变内容的参数排除在可索引 URL 之外；用重定向强制统一域名和尾斜杠约定。

难题五：Core Web Vitals 量的是外壳，不是内容

PWA 完全可能实验室跑分很漂亮、真实体验却很差，因为外壳瞬间就画出来了、内容后到。LCP 是对着真实内容量的；外壳快、数据请求慢，得到的就是「第一印象好、指标难看」。水合（hydration）的开销会直接落在交互响应性上；而当真实内容替换掉尺寸不一致的骨架占位时，布局偏移几乎必然发生。

解法：看真实用户字段数据而不是实验室数据；给异步到达的内容预留布局空间；把「到真实内容的时间」当成关键指标，而不是「到首次绘制的时间」。

难题六：多语言与 locale 路由

语言切换在应用里通常是客户端状态；但对搜索来说，它必须是可寻址的。如果同一个 URL 根据存储的偏好或 IP 猜测返回不同语言，索引里就只会留下一个版本——而且常常是错的那个——hreflang 也没有稳定的目标可指。

解法：每个语言各有各的 URL；绝不根据地理位置重定向爬虫；让「页面是什么语言」成为地址的属性，而不是会话的属性。

一个能省时间的排查顺序

当一个 PWA 在搜索里表现不佳时，按这个顺序查，定位最快：

1. 这个 URL 到底被索引了吗？ 没有的话，问题在发现或渲染，内容质量此刻还谈不上。
2. 渲染后的 HTML 里有内容吗？ 把原始响应和渲染结果对比一下。大多数「发了但隐形」的案例都在这一步能解释。
3. 每个视图有独立 URL、且有链接可达吗？ 没有的话，再多内容工作也托不起深层页面。
4. 缓存副本是最新的吗？ 用冷缓存拉一次做对比。
5. 信号收敛了吗？ canonical、统一域名、统一尾斜杠。
6. 最后才轮到内容与意图。 页面是否回答了这个查询当然是真问题，但它是最后一个问题，不是第一个。

多数团队从第 6 步开始查，然后花几周时间给一批压根没被渲染过的页面改文案。

常见问题

PWA 对 SEO 是负面的吗？

不是。这套架构本身是中性的，做得好的 PWA 在体验类信号上可以胜过传统站点。风险在于 PWA 会以静态站不可能出现的方式静默失败：内容对爬虫从未渲染、视图没有独立 URL、缓存副本悄悄过期。问题来自实现选择，不来自技术本身。

Google 会索引 PWA 用 JavaScript 渲染出来的内容吗？

会，但走的是有独立队列、也有独立失败模式的第二轮渲染。依赖 JavaScript 才出现的内容，被索引得更晚、也更不可靠。需要排名的页面，请把内容放进第一个响应里。

Service Worker 会影响爬取吗？

会。对 HTML 文档采用 cache-first 策略，可能把过期页面或离线兜底页发出去。激进缓存只留给带版本号的静态资源，文档一律做重新验证。

PWA 里每个界面都需要独立 URL 吗？

你希望被搜索找到的界面需要。纯粹属于应用状态的界面——设置弹窗、结账流程里的某一步——不需要可索引，给它们地址反而可能制造薄页面。判断标准是：会不会有人真的去搜这段内容。

小结

PWA 的 SEO 难题，几乎都是同一个问题的不同版本：应用心里的「页面」和搜索引擎心里的「页面」跑偏了。 把两者拉回一致——内容放进首个响应、每个可索引视图一个 URL、缓存做重新验证、canonical 信号收敛——这套架构的性能优势才会真正记在你账上，而不是被一个空壳挡住。

如果分发方式这件事在你那边还没定，PWA 与 APK 对比 和 PWA 与原生 App 对比 讲了搜索之外的取舍。