先說明：這裡的 CSR 是用戶端渲染（Client-Side Rendering），不是企業社會責任。CSR SSR 的差別在於網頁內容在哪裡產生：用戶端渲染先送出幾乎沒有內容的 HTML，再由瀏覽器執行 JavaScript 組出畫面；伺服器端渲染（Server-Side Rendering）則由伺服器產生完整 HTML 後送出。Google 能執行 JavaScript，但 CSR 網頁的主要內容要等轉譯後才看得到，而且不是所有漫遊器都能執行 JavaScript，所以 Google 搜尋中心仍建議採用伺服器端轉譯或預先轉譯，讓要被搜尋的內容與連結直接出現在伺服器回傳的 HTML。
CSR與SSR怎麼運作：內容在哪裡產生
Google 的中文文件把 rendering 譯為「轉譯」，和一般說的渲染是同一件事。依 Google 開發者網站 web.dev 的說明：
- 用戶端渲染（CSR）：在瀏覽器中轉譯應用程式，用 JavaScript 修改頁面結構。
- 伺服器端渲染（SSR）：在伺服器上轉譯，送給瀏覽器的是 HTML 而不是 JavaScript。
- 靜態產生：預先為每個網址產生獨立的 HTML 檔案。
- Hydration：在伺服器產生的 HTML 上執行用戶端指令碼，加入應用程式狀態與互動功能。
以商品頁為例，CSR 的原始 HTML 只有空的容器與程式檔，瀏覽器執行後才向 API 取得商品名稱、價格並顯示；SSR 則由伺服器查好資料，直接輸出含商品資訊的 HTML。想確認自家網站屬於哪一種，可在瀏覽器檢視網頁原始碼，看主要文字是否已經在裡面。若要找的是企業社會責任，請見企業社會責任是什麼。
渲染方式比較：CSR、SSR與靜態產生
| 比較項目 | CSR | SSR | 靜態產生 |
|---|---|---|---|
| 原始 HTML | 只有框架與程式檔 | 含完整內容 | 含完整內容 |
| 初次看到內容 | 要等 JavaScript 下載並執行 | 伺服器產生頁面需要時間，可能增加 TTFB | 檔案已預先產生，回應快 |
| 互動 | 載入後切換畫面快，但 JavaScript 越多越可能影響 INP | 搭配 Hydration 加上互動 | 搭配 Hydration 加上互動 |
| 伺服器負擔 | 主要提供程式檔與 API | 請求時在伺服器產生頁面 | 建置時產生，請求時負擔小 |
| Google 收錄 | 要經過轉譯才看得到內容 | 檢索時就看得到內容 | 檢索時就看得到內容 |
| 適合的頁面 | 登入後的後台與工具頁 | 頁數多、內容常變的頁面 | 頁數可預期、不需個人化的頁面 |
表中的 INP 是核心網頁指標之一，用戶端執行的 JavaScript 越多，越可能影響這項表現。
Google處理JavaScript的三個階段
Google 搜尋中心的「JavaScript SEO 基本概念」把流程分成檢索、轉譯、建立索引三個主要階段：
- 檢索：發出請求前，Googlebot 先讀 robots.txt 確認是否允許檢索；被封鎖的檔案或網頁，Google 不會轉譯其中的 JavaScript。
- 轉譯：除非 robots meta 標記或標頭告知不要建立索引，回傳 HTTP 200 狀態碼的網頁都會排入轉譯佇列，可能停留數秒，也可能更久。資源允許時，由無頭 Chromium 轉譯網頁並執行 JavaScript。
- 建立索引：Google 會再剖析轉譯後 HTML 裡的連結，把找到的網址排入檢索佇列，並用轉譯後的 HTML 建立網頁索引。
採用應用程式殼層模型的網站，初始 HTML 沒有實際內容，Google 必須執行 JavaScript 才看得到。官方仍建議伺服器端轉譯或預先轉譯，理由是使用者與檢索器都能更快取得內容，而且不是所有漫遊器都能執行 JavaScript。
CSR網站常見的SEO問題與修正
- 連結寫法：Google 只能找到 a 元素中含 href 屬性的連結，只靠點擊事件切換頁面的按鈕不會被當成連結。
- 網址結構：不要用網址片段（#）載入不同內容，改用 History API，讓每個頁面有獨立網址。
- 錯誤頁：單頁應用程式查無資料時，用 JavaScript 導向伺服器會回傳 404 狀態碼的網址，或在錯誤頁加上 noindex，避免錯誤頁被當成正常網頁。
- 不需互動就載入：Google 搜尋不會捲動或點選網頁，延遲載入要用瀏覽器內建功能或 IntersectionObserver，無限捲動要讓每個區塊有專屬網址。
- 中繼資料：可以用 JavaScript 設定標題與中繼說明，但不要用 JavaScript 把標準網址改成和原始 HTML 不同的網址；原始 HTML 有 noindex 時，Google 可能略過轉譯，事後用 JavaScript 移除不一定有效。
- 資源與快取：不要用 robots.txt 擋住轉譯需要的程式檔，檔名加上內容指紋，避免 Google 使用過期的程式。
動態轉譯、SSR與靜態產生怎麼選
動態轉譯是偵測漫遊器，提供伺服器轉譯版本給漫遊器，一般使用者仍拿到用戶端版本。Google 說明這是替代方案，不是長期的解決方案，建議改用伺服器端轉譯、靜態轉譯或 Hydration。新專案或改版時，可依頁面類型決定：
- 形象頁、文章、服務介紹：頁數可預期、內容不常變，適合靜態產生。
- 商品、價格或庫存常變、頁數很多：適合 SSR。web.dev 也提到，網址無法預先得知或不重複頁面極多時，靜態產生可能難以完成。
- 會員中心、後台、操作工具：不需要被搜尋，可以維持 CSR。
同一個網站可以混用：要被搜尋的頁面由伺服器輸出內容，再以 Hydration 加上互動。從 CSR 改成 SSR 等於換一套前端架構，上線前要比對新舊網址、標題與內部連結，可參考網站搬家的 SEO 檢查清單。
用Search Console網址檢查確認轉譯結果
- 在 Search Console 上方的檢查搜尋列輸入完整網址，網址要屬於目前開啟的資源。預設顯示的是已編入索引的結果，不是即時狀態。
- 點選「測試線上網址」，對目前的線上版本做即時測試。
- 點選「查看已測試的網頁」，在螢幕截圖分頁確認主要內容是否顯示；螢幕截圖只在成功的即時測試中提供。
- 在「更多資訊」查看已載入的資源與 JavaScript 輸出結果，找出載入失敗的程式檔或 API。
- 修正後再測一次，必要時要求建立索引；提交要求不代表一定會被編入索引。
報表與其他功能的用法，可參考Google Search Console 的功能與企業用法。
常見問題
Google 看得懂 CSR 網站嗎？
Google 能用無頭 Chromium 執行 JavaScript，但網頁要先排入轉譯佇列，等待時間不一定，其他漫遊器也不一定能執行。要被搜尋的頁面，建議讓內容出現在伺服器回傳的 HTML。
SSR 一定比 CSR 好嗎？
不一定。SSR 讓內容直接出現在 HTML，對收錄有利，但伺服器產生頁面需要時間；登入後的後台或工具頁不需被搜尋，用 CSR 也沒問題。依頁面是否要被搜尋來決定。
動態轉譯還能用嗎？
Google 說明動態轉譯是替代方案，不是長期的解決方案，只要提供的內容相似就不會被視為偽裝。新專案建議直接採用伺服器端轉譯、靜態轉譯或 Hydration。
怎麼快速判斷網站是不是用戶端渲染？
在瀏覽器檢視網頁原始碼，看標題以外的主要文字是否出現在原始 HTML。若只有空的容器與程式檔，內容就是由 JavaScript 在瀏覽器產生，屬於用戶端渲染。
改成 SSR 後排名會馬上提升嗎？
渲染方式影響的是 Google 能否順利看到內容，不代表排名會因此提升。改版後要用網址檢查確認內容正確顯示，並追蹤索引狀態與成效報表。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
建議先挑幾個重要頁面，用網址檢查的即時測試確認 Google 看到的內容，並檢視原始碼裡有沒有主要文字與連結。京采的技術 SEO 與網站健檢服務可以逐頁檢查轉譯結果、連結寫法與索引狀態，評估哪些頁面該改為伺服器輸出，並整理改版前後的網址與標題對照；想先確認網站狀況，歡迎與我們聯繫。
