多數人以為，只要把網站做成 PWA（漸進式網頁應用），Google 看待這個網站的方式就會跟著不一樣。其實不然，PWA 靠的是 Service Worker、Web App Manifest 這些跑在瀏覽器端的技術，Googlebot 抓到的，還是同一份 HTML。
裝了 PWA，網站確實會多出一些使用者體驗：離線也能開、可以加到手機主畫面、啟動速度變快。但這些好處全部發生在使用者的瀏覽器裡，跟 Google 排名系統怎麼評估這個頁面是兩件事。很多團隊會把「做了 PWA 之後排名進步了」跟「PWA 讓排名進步」混為一談，忽略了同一次改版裡，往往還動了內容架構、內部連結、頁面速度這些真正影響排名的因素。
PWA 值不值得投入，答案不是單純的是或否，而是要先分清楚「PWA 帶來的體驗提升」跟「PWA 本身」這兩件事，才不會把力氣錯放在追一個不存在的排名紅利上。
PWA 是什麼？
PWA 全名是 Progressive Web App（漸進式網頁應用），核心是 3 個技術要素疊在同一個網站上：Service Worker、Web App Manifest，以及 HTTPS。Service Worker 是一段在瀏覽器背景執行的程式碼，負責攔截網路請求、管理快取，讓網站在斷網或訊號不穩時仍能開啟部分內容。Web App Manifest 是一份設定檔，定義網站的名稱、圖示與啟動畫面，讓使用者可以把網站加到主畫面，點開之後的樣子跟原生 App 幾乎沒有差別。HTTPS 則是前兩者能運作的前提，Service Worker 只在加密連線上才會啟用。
這 3 樣東西合起來，會讓網站在使用者手機上感覺像 App，可是它們全部是瀏覽器端的技術，不會讓伺服器吐給 Googlebot 的那份 HTML 結構有任何不同。web.dev 的 PWA Checklist 把「Is installable」列在核心清單裡，而 Google 在 web.dev 公布的 Chrome 可安裝條件，要求網站走 HTTPS、附上一份有效的 Web App Manifest，使用者也要在頁面上點擊過、停留至少 30 秒；早期條件還要求註冊 Service Worker，現在 Chrome 已經不再把它列為必要條件。符合這些條件，瀏覽器才會判定這個網站可安裝，才會跳出加到主畫面的提示。
同一份 Checklist 卻把「能不能被搜尋發現」（Discoverable in search）另外放進進階的 Optimal 清單，自成一項，跟可安裝那一項完全脫鉤：網站要有 canonical URL、每個網址要有獨一無二且描述清楚的標題與 meta description，建議再加上 Schema.org 的結構化資料。換句話說，Google 自己把「這是不是一個 PWA」跟「這篇內容能不能被搜到」分成兩個各自獨立的檢查項，做到前者不會自動拿到後者。一個網站可以把 Service Worker、Manifest、HTTPS 全部做滿，可安裝的條件全部過關，搜尋引擎依然抓不到它的內容，因為那些條件量的是像不像 App，不是網頁寫得好不好找。
反過來說，一個完全沒做 PWA 的傳統網站，只要 canonical URL 設對、標題與描述寫得清楚、結構化資料補齊，一樣能在 Google 搜尋裡被完整索引。PWA 是不是值得做，取決於這個網站需不需要像 App 的體驗，跟它能不能被搜到，是兩條平行的軌道，不會因為做了其中一條就自動跑贏另一條。
PWA 不是讓網站排名變好的捷徑
先把立場說在前面，不要為了搜尋排名去做 PWA。Google 已經直接表態，PWA 跟排名之間沒有因果關係，這不是保守的推測，而是 Google 的 John Mueller 親口否定過的一個常見迷思。
Mueller 在 2017 年底於 Google Webmaster 論壇被問到 PWA 是否對排名有幫助時，回答得很直接，PWA 目前在 Google 搜尋沒有任何優勢，而且就他所知，Google 沒有計畫改變這一點。他同時補充，PWA 可以是快速做出一個互動網站的好方法，也能提供離線存取、推播通知這類實用功能，但這些體驗上的優點，並不會自動換成排名上的內在優勢。
Mueller 沒有否定 PWA 的價值，他否定的只是「PWA 本身」跟「排名」之間的連結。很多團隊會觀察到「網站改版做了 PWA，之後排名進步了」，就把兩件同時發生的事當成因果關係。但那次改版裡，通常同時動了內容架構、頁面速度、內部連結這些真正影響排名的因素，PWA 只是剛好搭上同一班改版列車，不是排名進步的原因。把功勞算在 PWA 頭上，反而會讓團隊誤判下一次該投入的重點在哪裡。
Googlebot 把 PWA 當成普通 HTML 頁面處理
不是 Google 不重視 PWA，而是 Googlebot 的爬取與渲染機制，原本就不分這是 PWA 還是傳統網站。
2021 年 11 月的 Google Search Central office-hours 直播裡，有人直接問 Mueller，某個主要競爭對手最近把網站從一般的 HTML、CSS、JavaScript 改成 PWA 之後，排名出現大幅跳升，這是不是代表 PWA 本身會影響排名。Mueller 的回答是，這些都只是做網站的不同方式，不管是用哪一種框架、格式或做成 PWA，Google 多半都把它們當成普通的 HTML 頁面處理。單純換成 PWA，不足以解釋排名為什麼進步，通常是同一次改版裡動到的其他東西，像是內部連結、內容本身、網站變快或變慢，在真正起作用。
Mueller 這裡回答的就是 PWA 本身的情境，不是拿別的例子類推過來。Googlebot 看一個頁面時，認的是渲染完成後拿到的那份 HTML，不會因為這個網站背後掛了 Service Worker、有 Manifest 檔就給予不同待遇。使用者在瀏覽器裡感受到的「App 感」，跟 Google 排名系統看到的東西，是兩個不同的層次，一個發生在使用者的裝置上，一個發生在搜尋引擎的爬取與索引流程裡，兩者不會互相傳遞。
Core Web Vitals 認效能，不認 PWA 這個標籤
PWA 跟 SEO 唯一沾得上邊的地方，不是「做了 PWA」這件事本身，而是 PWA 常見的技術手法，像 Service Worker 快取、資源預先載入，如果做得扎實，可以把 Core Web Vitals 的實際數據拉高，而 Core Web Vitals 是 Google 明確承認的排名訊號之一。
Google Search Central 的文件〈Understanding page experience in Google Search results〉講得很清楚，沒有單一訊號能決定排名，核心排名系統會綜合看一系列跟整體頁面體驗有關的訊號；文件同時強調，Google 搜尋一向優先呈現最相關的內容，就算頁面體驗不夠理想，相關的內容還是會被顯示出來，並提醒站方，單純為了 SEO 去追求完美的頁面體驗分數，可能不是最值得投入時間的地方。
換句話說，Core Web Vitals 是真訊號，但分數不是目的，內容相關性才是前提。web.dev 的 PWA Checklist 把「Starts fast, stays fast」放在 Core 基礎清單裡，並且註明 Lighthouse 的效能稽核就是以 Core Web Vitals 為基礎。這代表 PWA 常做的快取、預載這類效能優化，確實跟 Core Web Vitals 的分數直接掛鉤，但掛鉤的是效能好不好，不是有沒有掛 PWA 這個標籤。一個完全沒做 PWA、只是把圖片壓好、把不必要的 JavaScript 拿掉的傳統網站，一樣拿得到一模一樣的效能加分，PWA 在這裡不是必要條件，只是眾多能拉高效能的做法之一。
外殼式架構與純前端渲染，讓索引比想像中晚一步到
PWA 做得好或許有加分，但也藏著一個常被忽略的風險。很多 PWA 為了做到開起來像 App 一樣快，會採用外殼式架構（app shell），也就是使用者第一次拿到的 HTML 幾乎是空殼，實際內容全部靠前端 JavaScript 動態灌進去。
Google Search Central 的文件〈JavaScript SEO basics〉直接點名這個模式，提到部分 JavaScript 網站會使用 app shell 模式，初始 HTML 並不包含實際內容，Google 必須先執行 JavaScript，才看得到 JavaScript 產生出來的真正頁面內容。文件同時說明，一個頁面會先進入爬取佇列，之後才排進獨立的渲染佇列去執行 JavaScript，兩者是分開的兩道程序，不是同一時間發生。
對外殼式架構的 PWA 來說，這代表 Googlebot 抓到第一版 HTML 時，看到的內容非常有限，要等到它排進渲染佇列、把 JavaScript 跑完，才拿得到完整內容。這中間多出來的工序，也多出一段等待的時間。如果一個網站選了純前端渲染，又沒有搭配伺服器端渲染或預先渲染，反而可能讓內容更晚才被看到，跟靠 PWA 幫 SEO 的初衷正好相反。
Google Search Central 同系列的〈Fix Search-related JavaScript problems〉文件也給出對應建議，遇到 Googlebot 不支援的效果（文件舉的例子是靠 WebGL 呈現的相片特效），可以直接拿掉，或改用伺服器端渲染把它預先渲染完成再送出，讓所有使用者，包含 Googlebot 在內，都能拿到內容。這條建議一樣適用在 PWA 常見的前端框架架構上，做 PWA 不代表可以跳過這一步。
重度回訪、行動優先的產品型網站，做 PWA 順便把體驗訊號做對
前面幾節在講不要為了排名去做 PWA，但這不代表 PWA 一無是處。當一個網站的本質是使用者會重複回來用，像工具型網站、會員制服務、電商、內容聚合平台，PWA 的離線快取與可安裝能力解決的是真實的使用體驗問題，不是虛構出來的 SEO 捷徑。
這類網站的回訪流量原本就佔大宗，Core Web Vitals 用的是真實使用者資料計分，重度回訪的使用者體驗一旦被 PWA 拉高，現場數據自然容易跟著變好。這種情況下做 PWA，SEO 上的加分是體驗投資帶來的附帶結果，不是本末倒置去追一個不存在的排名優惠。
Google 在 web.dev 公布過一個具代表性的國際案例，Twitter Lite 改成 PWA 之後，整個 PWA 透過網路傳輸的資料量只有 600KB，相較安裝原生 Android App 要下載 23.5MB，差距非常明顯；在 3G 網路環境下，多數裝置的首次載入 5 秒內完成，回訪使用者重新開啟 PWA 則能在 3 秒內完成。案例裡還提到，使用者把它加到主畫面之後，平均每天有 25 萬名不重複使用者從主畫面捷徑開啟 Twitter Lite，平均一天開啟 4 次。這幾個數字說明的是體驗改善，不是搜尋排名的變化，但體驗改善會回頭反映在 Core Web Vitals 的現場數據上。
即使是這種值得做的場景，前面提到的伺服器端渲染或預先渲染仍然不能省。PWA 帶來的體驗好處，跟正確的渲染策略，是要同時做到的兩件事，不是做了 PWA 就可以跳過渲染策略，也不是渲染做對了就能忽略體驗。重度回訪、行動裝置為主、需要離線或推播的產品型網站，做 PWA 是把資源投在對的地方；把它當成排名捷徑套用到所有網站，才是搞錯了因果。
PWA 值不值得做，答案不在「這樣會不會讓排名變好」這個問題裡，而在「使用者需不需要這種體驗」。把離線存取、可安裝、快速啟動這些能力用在真正需要重度回訪的產品上，體驗變好了，效能數據通常也會跟著變好，這是體驗投資帶來的順帶結果。反過來，如果只是想找一條捷徑繞過內容深度、頁面結構、真正的載入速度這些排名系統看重的東西，PWA 幫不上忙，Googlebot 看到的仍然只是同一份 HTML。
先想清楚自己的網站屬不屬於那種使用者會一直回來用的類型，再決定要不要投入 PWA，會比先問做了會不會加分，更接近問題的核心。