我是吳承學,做了二十年以上的 SEO。這些年被問最多、也最容易被誤會的一題,就是「明明頁面看起來好好的,為什麼搜尋引擎抓不到內容」。答案幾乎都指向同一個地方:網頁是誰畫出來的、什麼時候畫出來的。這篇我把 CSR、SSR、SSG 三種渲染方式攤開講清楚,並且把我實際稽核時用來判斷的動作、要前端交出的驗收證據,一併寫給你,讓你在跟工程師討論改版時,能提出具體要求,而不是只丟一句「SEO 好像怪怪的」。

1. 為什麼你在瀏覽器看到內容,搜尋引擎卻看不到

很多人第一次聽到「頁面對搜尋引擎是空白的」都很難接受,因為自己用瀏覽器打開明明一切正常。問題在於,你看到的畫面和搜尋引擎讀到的原始碼,常常不是同一份資料。

1.1 檢視原始碼與檢查元素讀的是兩份不同的東西

檢查元素(F12)顯示的是瀏覽器執行完 JavaScript、動態更新後的最終 DOM;檢視原始碼(Ctrl+U)顯示的則是伺服器回傳的第一手 HTML。前者是「使用者最後看到的畫面」,後者才是「搜尋引擎第一眼讀到的東西」。這兩者的落差,就是許多前端渲染網站排名長期起不來的根源。

比較項目 檢視原始碼(Ctrl+U) 檢查元素(F12)
顯示內容 伺服器回傳的原始 HTML 瀏覽器渲染後的最終 DOM
時間點 網頁載入第一瞬間 JavaScript 執行、動態更新之後
看得到 JS 生成的內容嗎 看不到,只有初始內容 看得到,含 API 載入後的資料
看得到 CSS 樣式嗎 沒有樣式 可即時看到排版與變更
SEO 判讀用途 檢查搜尋引擎實際能讀到的 HTML 檢查使用者實際看到的畫面

1.2 view-source 是空白,對搜尋引擎就等於沒內容

Google 這幾年確實會執行 JavaScript,但執行渲染需要額外排隊、耗費資源,實務上容易延後、也容易漏抓。如果你的檢視原始碼裡只剩下一個 <div id="app"></div> 的骨架,主要文字全靠瀏覽器事後補上,那麼在搜尋引擎第一輪抓取時,這頁的可讀內容趨近於零。我不會用「一定抓不到」這種說法,但依我經手過的案例,這類頁面的收錄與排名表現,普遍比初始 HTML 就有完整文字的頁面吃虧。

1.3 我稽核一個陌生網站的第一個動作

接手新客戶時,我不會先開任何付費工具。我做的第一件事,是打開首頁按 Ctrl+U,然後用瀏覽器內建搜尋去找一段畫面上明明看得到的內文,例如標題或第一段文字。找得到,代表這段是伺服器就送出的;找不到,代表它是前端事後畫上去的。這個動作三十秒就能做完,卻能立刻分辨這個網站的體質屬於哪一種,後面所有建議都會從這個判斷長出來。

2. CSR、SSR、SSG 各自畫內容的時機不同

三種渲染方式的差別,可以濃縮成一句話:內容是在哪一端、哪一個時間點被畫出來的。搞懂這件事,你就能判斷一個頁面該不該用某種架構。

2.1 CSR 把畫圖的工作丟給使用者的瀏覽器

CSR 的頁面初始 HTML 幾乎是空的,要等瀏覽器下載並執行 JavaScript,才會動態生出內容,這是 React、Vue 未經額外設定時的預設行為。它對搜尋引擎的可見性最弱,因為內容在初始時不存在,搜尋引擎必須額外渲染才看得到。它適合的場景是會員中心、後台管理、登入頁這類本來就不需要被索引的頁面。

2.2 SSR 在伺服器先畫好再送出

SSR 是伺服器先把 HTML 內容組好,再連同資料一起送給瀏覽器,前端仍然可以互動。搜尋引擎打開就是完整 HTML,不必等 JavaScript 補畫。它同時能改善首屏出現的時間,對載入速度與 Core Web Vitals 也有幫助。部落格、產品頁、服務頁這類需要被索引、內容又常變動的動態頁,SSR 是相對穩妥的選擇。

2.3 SSG 在部署階段就把頁面畫好放上 CDN

SSG 是在網站部署階段,就先把所有頁面產成靜態 HTML,不需要伺服器即時運算。內容完全靜態、載入快,對搜尋引擎最友善。它適合不常變動的頁面,例如關於我們、教學文章、案例分享。用一句話串起三者:CSR 是到前端才畫出內容,SSR 是伺服器幫你畫好再送出,SSG 是網站一開始就把所有頁面畫好放在 CDN 上。

名稱 全名 內容何時產生 搜尋引擎可見性 適合場景
CSR Client-Side Rendering 使用者瀏覽器執行 JS 後 初始不可見,需額外渲染,容易漏抓 會員中心、後台頁、登入頁等不需索引頁面
SSR Server-Side Rendering 伺服器接到請求時即時產生 搜尋引擎直接讀到完整 HTML 部落格、產品頁、服務頁等需索引的動態頁
SSG Static Site Generation 部署階段一次產好 內容完全靜態,載入快,最友善 關於我們、文章、案例等不常變動頁面

3. 三分鐘判斷一個頁面用哪種渲染

你不需要看程式碼,也能相當準確地判斷一個頁面的渲染方式。我通常用三個彼此交叉驗證的動作,任何一個 PM 或編輯都做得到。

3.1 用檢視原始碼搜尋一段實際內文

按 Ctrl+U 打開原始碼,用瀏覽器搜尋功能找畫面上一段明確的文字。原始碼裡有完整文字,通常是 SSR 或 SSG,搜尋引擎讀得到;原始碼幾乎空白、只剩 <div id="app"> 這類框架,就是 CSR,搜尋引擎在第一輪讀不到。這個方法的好處是它直接檢查搜尋引擎的第一手資料,沒有中間的猜測。

3.2 禁用 JavaScript 後重新載入

在瀏覽器設定裡把 JavaScript 關掉,再重新載入頁面。頁面還有文字,代表內容來自伺服器端渲染;頁面變成一片空白,代表內容完全依賴前端 JavaScript 生成。這一步能補足前一步的判斷,尤其是遇到那種「原始碼有一點內容、但主文不見了」的混合情況時特別有用。

3.3 用渲染測試工具交叉比對差異

如果要更嚴謹,可以用 Google 的渲染測試看它實際抓到的版本是否完整,或用 Screaming Frog 把 Rendering 模式切成 JavaScript 與純 HTML,比較兩份結果的差異。差異愈大,代表這頁對 JavaScript 的依賴愈重,搜尋引擎漏抓的風險就愈高。我在跟工程師開會前,習慣先把這份差異截圖出來,討論時就不會停留在各說各話,而是對著同一份證據談。

4. 頁面是 CSR 時,改架構之外還有哪些選項

發現頁面是 CSR,不代表非得把整個網站砍掉重練。要不要動、動到什麼程度,取決於這頁該不該被索引,以及改動的成本。

4.1 能改成 SSR 就優先改 SSR

如果這頁本來就要被搜尋引擎收錄,例如產品頁或文章頁,最直接的解法就是請工程師把渲染模式改成 SSR,讓主要內容在初始 HTML 就存在。現代前端框架大多有對應的伺服器端渲染方案,不是非得推翻既有技術選型。這通常是投報率最高的一步。

4.2 改不動架構時,用預先渲染產生 HTML 快照

有些老專案受限於既有架構,短期內改不動 SSR。這種情況可以退一步,採用預先渲染,針對搜尋引擎產生一份 HTML 快照,讓爬蟲拿到有內容的版本。它不是最理想的做法,卻是在成本與效果之間相對務實的折衷。我碰過一個電商案子,前端全站 CSR、又不可能立刻重寫,最後就是先上預先渲染把收錄止血,再排程分批改 SSR。

4.3 先確認哪些頁面其實不需要被索引

不是每個 CSR 頁面都要救。會員中心、購物車、登入頁、後台這類頁面,本來就不該出現在搜尋結果裡,維持 CSR 完全沒問題,甚至更省事。花力氣之前,先把「需要被索引」和「不需要被索引」的頁面分開,你會發現要處理的範圍往往比想像中小,資源也能集中在真正帶流量的模板上。

5. 上線前我會要求前端交出的驗收證據

渲染問題最怕的是上線後才發現,而那時流量已經掉了。所以我把驗收前移到上線前,並且要求的是可以檢查的證據,而不是一句口頭保證。

5.1 抽樣首頁、列表頁、詳情頁三種模板

一個網站的頁面雖多,但模板通常就那幾種。我會各抽一頁首頁、列表頁、詳情頁,分別用檢視原始碼確認主要內容是否出現在初始 HTML 裡。模板過關,同類頁面大致就能放心;只要有一種模板是空的,就代表整批同類頁面都有風險。

5.2 守住原始碼可見文字這條原則

我把它當成不可退讓的底線:用檢視原始碼應該能看到完整、可讀的文字,而不是圖片或空標籤。特別是價目表、時間表、規格表這類資訊,如果在原始碼裡找不到表格內容,就代表這個區塊只在前端渲染,搜尋引擎讀不到。這類資訊我一律要求用 <table>、<ul>、<dl> 等結構化標籤呈現,不能用 CSS 圖示或圖片替代文字。

5.3 用語意化標籤與結構化資料補強

除了讓文字在初始 HTML 可見,我還會要求關鍵區塊補上結構化資料。以營業或時間資訊為例,加上對應的 JSON-LD,能讓搜尋引擎在無法完整解析 HTML 時,仍舊理解內容的意義,等於多上一道保險。下面是一段文章頁常用的結構化資料骨架:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "頁面標題",
  "datePublished": "2026-01-10",
  "dateModified": "2026-01-12",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/rendering"
  }
}
</script>

6. 常見問題

6.1 Google 已經會執行 JavaScript 了,CSR 還會有 SEO 問題嗎

會執行不等於一定會即時、完整地執行。渲染需要額外資源與排隊時間,實務上容易延後或漏抓。內容如果在初始 HTML 就存在,搜尋引擎第一輪就讀得到,不必賭它後續會不會補渲染。對重要頁面來說,把內容放進初始回應仍是比較穩的做法。

6.2 我不會寫程式,怎麼自己判斷網站是不是 CSR

兩個動作就夠。第一,按 Ctrl+U 檢視原始碼,搜尋畫面上看得到的一段文字,找不到就有 CSR 的嫌疑。第二,把瀏覽器的 JavaScript 關掉重新載入,頁面變空白就幾乎確定是 CSR。這兩步不需要任何工具,也不需要工程背景。

6.3 SSR 和 SSG,我該選哪一個

看內容多久變動一次。經常更新、需要即時資料的頁面適合 SSR;內容相對固定、不常改動的頁面,SSG 通常載入更快、也更省伺服器資源。實務上很多網站是兩者混用,文章與說明頁走 SSG,商品庫存或即時資訊走 SSR。

6.4 頁籤切換的內容,搜尋引擎看得到嗎

如果切換是用 JavaScript 控制的顯示與隱藏,搜尋引擎往往只看得到初始載入時顯示的那一塊,其他隱藏頁籤的內容可能不被索引。想讓每個頁籤都被讀到,要嘛把內容都保留在 HTML 結構裡,要嘛把具獨立價值的內容改成各自的網址。

6.5 全站改 SSR 工程量太大,有沒有折衷做法

有。先把頁面分成需要被索引與不需要被索引兩類,只處理前者;短期改不動架構的,先上預先渲染產生快照止血,再排程分批改成 SSR。這樣既控制了工程風險,也不會讓收錄問題持續擴大。

延伸閱讀