CSR、SSR、SSG、ISR 差在哪？渲染模式怎麼選才對 SEO 好
「HTML 在哪裡產生」是一個純架構決定，卻直接決定了 索引流程 的第三關能不能過，爬蟲拿到的到底是完整內容，還是一個空的 <div>。
四種模式
| 模式 | 全名 | HTML 在哪產生 | 什麼時候產生 |
|---|---|---|---|
| CSR | Client-Side Rendering | 瀏覽器 | 使用者開啟頁面時 |
| SSR | Server-Side Rendering | 伺服器 | 每次請求 |
| SSG | Static Site Generation | 建置機器 | 建置時（部署前） |
| ISR | Incremental Static Regeneration | 伺服器 | 建置時產生，過期後背景更新 |
爬蟲看到什麼
這是最關鍵的差異。
| 模式 | 搜尋引擎爬蟲 | 社群平台爬蟲 |
|---|---|---|
| CSR | 需等第二階段渲染，有延遲與失敗風險 | 看不到內容 |
| SSR | 完整內容 | 完整內容 |
| SSG | 完整內容 | 完整內容 |
| ISR | 完整內容 | 完整內容 |
社群爬蟲不執行 JavaScript
這一點常被忽略。Google 至少會排隊渲染，但 Facebook、X、LINE 等平台的預覽爬蟲 完全不執行 JavaScript。純 CSR 的頁面被分享出去時，Open Graph 標籤如果是靠程式碼注入的，卡片就會一片空白。
各模式的取捨
| CSR | SSR | SSG | ISR | |
|---|---|---|---|---|
| SEO 友善 | 差 | 好 | 好 | 好 |
| TTFB | 快（靜態檔） | 慢（要組裝） | 最快 | 快 |
| 首屏內容出現 | 慢 | 快 | 最快 | 快 |
| 內容即時性 | 即時 | 即時 | 建置時的快照 | 接近即時 |
| 伺服器成本 | 無 | 高 | 無 | 中 |
| 頁面切換 | 最快 | 較慢 | 最快 | 最快 |
| 實作複雜度 | 低 | 高 | 低 | 中 |
留意 SSR 的 TTFB 那一格：伺服器端渲染不見得整體更快。它買到的是「首屏內容早點出現」與「爬蟲讀得到」，代價是伺服器要花時間組裝，第一個位元組反而可能來得比靜態檔慢。
決策表
不必糾結，照專案型態對照就好：
| 專案型態 | 建議 | 理由 |
|---|---|---|
| 文件站、部落格、官網 | SSG | 內容不常變、全部靜態最快也最省 |
| 電商商品頁 | ISR 或 SSR | 價格與庫存要新，但也要被收錄 |
| 新聞、內容平台 | SSR 或 ISR | 內容量大且更新頻繁 |
| 後台管理介面 | CSR | 登入後才看得到，不需要被收錄 |
| 首頁靜態、內頁動態 | 混合 | 依路由分別設定，多數框架都支援 |
不需要全站統一
最常見的誤解是「渲染模式要整站一致」。實際上現代框架都支援 逐路由設定：行銷頁走 SSG、商品頁走 ISR、後台走 CSR，這是完全合理的組合。
已經是純前端專案怎麼辦
不必一次改成 SSR。按這個順序評估，成本從低到高：
- 盤點哪些頁面真的需要被收錄：登入後的操作介面不需要，通常只有首頁與內容頁需要。
- 只對那幾頁做預渲染：建置時把指定路由跑成靜態 HTML，其餘維持原狀。改動最小，也不需要 Node 伺服器。
- 確認檔頭標籤有正確更新：路由切換時
<title>與description要跟著換，做法見 SPA 動態更新 title 與 meta 。 - 真的需要即時內容時才上 SSR：這一步才會引入伺服器與部署複雜度。
Vue 專案的具體做法見 Vue 與 Nuxt 的 SSR 實作 。
水合的成本
SSR 與 SSG 都會讓瀏覽器拿到現成的 HTML，但頁面要能互動，還得執行一次 水合（Hydration），把事件監聽掛回既有的 DOM 上。
這段時間畫面看得到卻按不動，是 INP 變差的常見原因。改善方向是部分水合與島嶼架構，詳見 水合 Hydration 與 INP 。
怎麼驗證
用檢視原始碼，不要用開發者工具
開發者工具的元素面板顯示的是 執行完程式碼之後 的 DOM，永遠看得到內容，什麼問題都驗不出來。
要用瀏覽器的「檢視網頁原始碼」（Ctrl + U），那是伺服器實際回傳的內容，也是社群爬蟲看到的東西。
進一步的驗證用 Google Search Console 的網址檢查，它會顯示搜尋引擎渲染後的實際 HTML 與截圖。排查步驟見 純 CSR 的 SEO 問題 。
這一組還有這些主題
| 主題 | 說明 |
|---|---|
| 純 CSR 的 SEO 問題 | 兩階段渲染、渲染佇列延遲與驗證方式 |
| Vue 與 Nuxt 的 SSR 實作 | SPA 的 SEO 缺口、SSR 與預渲染的成本比較 |
| SPA 動態更新 title 與 meta | 路由切換時更新檔頭的三種做法 |
| 水合 Hydration 與 INP | 水合成本、不一致的成因與部分水合 |
常見問題
Google 會執行 JavaScript，那純 CSR 應該沒問題吧？
Google 確實會渲染，但那是排在佇列裡的第二階段，輪到之前內容都不算數，而且程式碼出錯就直接放棄。更關鍵的是社群平台的爬蟲完全不執行 JavaScript，分享連結時只會抓到空的容器，預覽卡片一片空白，詳見 純 CSR 的 SEO 問題 。
只做預渲染夠不夠？
對內容不常變動、頁面數不多的網站夠用。預渲染在建置時把指定路由跑出靜態 HTML，改動最小、不需要 Node 伺服器。缺點是路由必須事先列舉，動態產生的網址無法涵蓋。
SSR 一定比 CSR 快嗎？
首次內容出現得比較快，但整體不一定。伺服器要組裝 HTML，第一個位元組的回應時間 反而可能變長；後續的頁面切換也因為每次都要回伺服器而慢於用戶端路由。SSR 買到的是首屏速度與可被爬取，不是全面更快。
已經是純前端專案，最小的改動是什麼？
先確認哪些頁面真的需要被搜尋引擎收錄。通常只有首頁與內容頁需要，登入後的操作介面不需要。針對那少數幾頁做預渲染或靜態產生，其餘維持原狀，成本遠低於整站改成伺服器端渲染。
怎麼確認搜尋引擎看到的內容？
用瀏覽器的檢視網頁原始碼功能，不要用開發者工具的元素面板，後者顯示的是執行完程式碼的結果。原始碼裡看不到主要內容就是有問題。進一步可以用 網址檢查工具 看搜尋引擎渲染後的實際結果。
