引言：官網不是產品，別用同一套技術
很多 SaaS 團隊在立項時只問一個問題：「官網和產品能不能共用一套程式碼？」答案是可以，但「能共用」不等於「該共用」。
官網承擔的是行銷職能——它要被搜尋引擎收錄、要被訪客秒懂、要被用戶在群組裡轉發。而 SPA（Single Page Application，單頁應用）是給「登入後的產品」量身打造的前端形態：互動密集、需要客戶端狀態、對 SEO 沒有要求。把行銷官網套進 SPA 的殼子裡，等於讓一個業務員穿上工程師的防火衣——能穿，但一開口就露餡。
本文從四個維度，拆解為什麼 SaaS 官網不建議做成 SPA。
一、SEO：SPA 的多波渲染，讓內容遲遲進不了索引
SPA 最大的問題不在「能不能被搜尋引擎收錄」，而在「多久才能被收錄」。
Google 採用**兩波索引（two-wave indexing）**機制：第一波先抓取你回傳的原始 HTML，第二波再把頁面放入渲染佇列、用無頭瀏覽器執行 JavaScript 後補抓內容。問題是——
- 你的 SPA 首頁回傳的往往只是一個
<div id="root"></div>空殼，第一波抓不到任何內文； - 真正的內容要等第二波渲染，而渲染佇列可能積壓數小時、數天甚至數週；
- Googlebot 執行腳本還有逾時上限（渲染預算），複雜的頁面可能只渲染到一半就被放棄；
- 大量頁面進入「已抓取但未收錄（Crawled – currently not indexed）」狀態。
結果就是：SaaS 官網辛苦寫好的產品介紹、定價邏輯、說明文件，在搜尋引擎眼裡存在感極低。而如果你的產品資料、用戶評價是靠非同步介面載入的，爬蟲極可能完全看不到。
更麻煩的是：很多 SPA 用 hash 路由（#/pricing），把整個站點壓成一個 URL，爬蟲把整個產品目錄當成「一頁」處理；而每個頁面還需要獨立的 HTTP 狀態碼和 canonical 標籤才能被正確解析，SPA 預設做不到。
結論：搜尋引擎優先獎勵「HTML 裡就有內容、JS 只是增強」的頁面。SPA 把內容和 JS 深度綁定，等於主動給 SEO 設障礙——你的競爭對手用 SSR 一秒進索引，你要等一週，排名怎麼可能搶得過。
二、效能：Core Web Vitals 與首次渲染的「白螢幕稅」
官網的第一屏決定轉換，而 SPA 恰恰把最乾淨的內容藏在了最重的技術之後。
用戶端渲染（CSR）的流程是：瀏覽器先拿到一個幾乎為空的 HTML → 下載動輒數百 KB 的 JS 包 → 解析執行 → 才真正渲染出文字、圖片和按鈕。在行動端，這一串序列請求會帶來明顯的白螢幕期（blank white screen）。
一組來自業界測試的數據：
- 主流框架的「Hello World」最小 JS 包都超過 200KB（Next.js 約 248KB、Remix 約 228KB、Nuxt 約 191KB）——這還只是空專案，業務越重，包越大；
- 實測中，大型 SPA 首屏可能要在 JS 包完全解析後才出現內容，白螢幕時間可達數秒甚至更久；
- Google 官方也承認，多頁應用（MPA）在結構上對 Core Web Vitals 更有利——整頁跳轉能命中更多快取資源，能改善用於統計的 75 分位分布；
- SPA 的 hydration（注水）會占用主執行緒，訪客可能看到頁面「看起來載入完了」，但點按鈕毫無回應——這就是被 INP／TTI 懲罰的場景。
結論：對轉換至關重要的 LCP（最大內容渲染）、CLS（版面位移）、INP（互動延遲）三項指標，SPA 預設全部是劣勢。而官網偏偏是訪客第一次見到你品牌的地方——第一印象就白螢幕三秒，誰還有耐心註冊？
三、社群分享：連結在微信、LinkedIn、Slack 裡「無人認領」
官網內容很大一部分流量來自社群分享。你把產品介紹傳給客戶、貼到群裡、發到動態牆——對方看到的縮圖、標題、描述，決定的可是你品牌的門面。
問題是：社群平台的爬蟲（微信、LinkedIn、X、Slack、WhatsApp）基本上不執行 JavaScript。 它們只讀取伺服器第一次回傳的 HTML。SPA 回傳的是一張空頁面，沒有og:title、og:image、og:description，於是——
- 分享出來的是白板或預設占位圖，標題寫著「React App」或一堆亂碼；
- 沒有縮圖、沒有摘要，點擊率直線下降；
- 即便你費勁給 SPA 加了 OpenGraph 標籤，如果標籤不是放在首次回應的 HTML 裡，照樣失效。
結論：官網的本職就是「被轉發」。如果分享出去是一張白板，等於你的業務在動態牆替你發了一條空廣告。而 SSR／SSG 生成的頁面，社群爬蟲一抓一個準，縮圖、標題、描述全部到位。
四、轉換率與心智：每慢一秒，都在燒錢
以上技術問題最終都會落到同一個詞上——轉換率。
- 有統計顯示，頁面載入延遲 1 秒，轉換率約下降 7%；
- 100ms 的延遲可能帶來約 1% 的營收損失；
- 53% 的行動端用戶在頁面載入超過 3 秒後選擇離開；
- 單體 JS 包超過 2MB，在行動端很容易出現多秒的首屏載入。
對於 SaaS 官網，每一秒都對應著真實的註冊、試用、成交機會。請權衡一下：用 SPA「省下的開發工時」，是否真的值得用「流失的曝光和轉換」去償還？答案通常是不值得。
五、那到底該怎麼搭？——SSR／SSG + SPA 混合架構
解決方式不是「放棄一切前端框架」，而是把你真正需要的技術用在正確的地方。主流成熟方案是混合架構（hybrid）：
| 區域 | 建議方案 | 原因 |
|---|---|---|
| 官網的公共頁（首頁、定價、部落格、文件） | SSR 或 SSG（預渲染 HTML） | 內容進索引、秒開、社群縮圖齊全 |
| 登入後的產品區（用戶後台／儀表板 app.copyark.com） | SPA／客戶端元件 | 互動密集、無需 SEO，效能只要保證登入用戶 |
業內框架的官方文件也明確認可這一分工：Next.js 官方文件說，行銷頁用 SSG／SSR 是「最適合 SEO」的選擇，而 CSR 更適合「不需要進入搜尋引擎索引」的登入後頁面。很多時候，你甚至可以在同一個 Next.js 專案裡，讓/pricing、/blog走伺服器端渲染，讓/app走認證後客戶端渲染——程式碼沒多寫幾行，SEO 和效能問題卻迎刃而解。
結語：官網是「門面」，請用「門面」的架構
一句話總結：SaaS 官網不只是「網站」，它是你的銷售漏斗。 做漏斗的地方，要的是被看見、被秒懂、能被分享。SPA 省下的是開發的一時半刻，付出的卻是 SEO 排名的長期失利、Core Web Vitals 的不達標、社群分享的白板——而這些恰恰是決定 SaaS 早期獲客成敗的命門。
把 SPA 留給登入後的產品，把 SSR／SSG 留給門面。這個看似「技術潔癖」的選擇，往往才是 SaaS 團隊做過最划算的一筆技術投資。