「頁面看起來好好的，為什麼搜尋引擎抓不到內容？」這是我們最常被問、也最容易被誤會的一題。答案幾乎都指向同一個地方：網頁是誰畫出來的、什麼時候畫出來的。你在瀏覽器看到的畫面，和搜尋引擎第一眼讀到的原始碼，常常不是同一份資料。這篇我們把 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，然後用瀏覽器內建搜尋去找一段畫面上明明看得到的內文，例如標題或第一段文字。找得到，代表這段是伺服器就送出的；找不到，代表它是前端事後畫上去的。這個動作三十秒就能做完，卻能立刻分辨這個網站的體質屬於哪一種，後面所有建議都會從這個判斷長出來。一個這麼簡單的檢查，往往就決定了我們接下來要往架構還是往內容去追問題。

1.4 搜尋引擎渲染需要排隊，別把內容賭在那一步

這裡補一個很多人忽略的環節：搜尋引擎抓取和渲染，其實是兩個分開的階段。它先抓到初始 HTML，之後才把需要執行 JavaScript 的頁面排進一個渲染佇列，等有餘裕時才補跑。問題在於這個佇列會排隊，遇到資源吃緊時，渲染可能延後很久，甚至這一輪就被略過。所以初始 HTML 裡有沒有內容，決定的是搜尋引擎能不能第一時間讀到你的頁面，而不是能不能讀到。我們寧可讓內容在第一步就到位，也不想把它押在一個不確定何時執行的第二步上，這是風險管理的基本盤。

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

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

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

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

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	部署階段一次產好	內容完全靜態，載入快，最友善	關於我們、文章、案例等不常變動頁面

2.4 實務上常是混用，不必二選一

要提醒的是，這三種渲染方式並非全站只能擇一。現代框架大多支援同一個網站裡不同頁面用不同方式產生：首頁和文章走 SSG 拿最快的載入，商品頁走 SSR 確保庫存即時又能被索引，會員後台走 CSR 省下不必要的渲染。還有一種常見的折衷，是先用伺服器送出有內容的 HTML，再讓前端接手變成可互動的頁面，兼顧了首輪可見與後續的互動體驗。所以實際規劃時，我們不會問「整站要用哪一種」，而是逐類頁面問「這一類最適合哪一種」。把渲染方式當成可以依頁面特性搭配的工具，而不是一個非此即彼的選擇，你的架構決策會彈性得多。

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

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

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

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

3.2 禁用 JavaScript 後重新載入

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

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

如果要更嚴謹，可以用 Google 的渲染測試看它實際抓到的版本是否完整，或用檢測工具把渲染模式切成 JavaScript 與純 HTML，比較兩份結果的差異。差異愈大，代表這頁對 JavaScript 的依賴愈重，搜尋引擎漏抓的風險就愈高。我們在跟工程師開會前，習慣先把這份差異截圖出來，討論時就不會停留在各說各話，而是對著同一份證據談，省下大量來回。前兩個動作適合快速初判，第三個動作適合要向團隊舉證、或要說服對方投入資源改版時使用；三者搭配，從初步懷疑到提出具體要求，一條龍都有依據。

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

發現頁面是 CSR，不代表非得把整個網站砍掉重練。要不要動、動到什麼程度，取決於這頁該不該被索引，以及改動的成本。先想清楚這兩點，再決定投入多少。我們看過不少團隊一發現是 CSR 就恐慌，以為要全站重寫，結果嚇退了改版的念頭，反而什麼都沒做。實際上選項是有梯度的，從最徹底的改 SSR 到最輕量的預先渲染，中間有很多空間，關鍵是依頁面的重要性挑合適的力道。

4.1 能改成 SSR 就優先改 SSR

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

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

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

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

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

把這三個選項擺在一起看，其實是一道依重要性分配力氣的題目：帶搜尋流量的核心模板值得直接改 SSR，一次把根本問題解掉；受限於舊架構、又不能不被收錄的頁面，用預先渲染先止血；至於本來就不該進搜尋結果的頁面，維持 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。這樣既控制了工程風險，也不會讓收錄問題持續擴大。把它當成一個分階段的計畫，而不是一次性的大改，推動起來會容易得多。

6.6 渲染方式和 Core Web Vitals 有關係嗎

有，而且關係不小。如果首屏內容要等 JavaScript 執行才出現，最大內容的顯示時間就會被拖長，LCP 難看。讓首屏主要文字與圖片在伺服器的初始回應裡就存在，同時改善了搜尋引擎可見性和載入體感，這也是為什麼我們談渲染架構時，常常一路談到效能指標，兩者其實是同一件事的兩面。

6.7 改成 SSR 之後，原本的前端互動會不會壞掉

正常情況下不會。主流框架的伺服器端渲染方案，設計上就是先送出有內容的 HTML，再讓前端接手恢復互動，使用者體驗到的操作幾乎一樣。要注意的是改版過程中的細節，例如某些只能在瀏覽器執行的程式碼要正確處理，否則可能出現畫面閃動或錯誤。這屬於工程實作層面的風險，可以透過分批上線、逐頁驗證來控制，不是改 SSR 本身的必然代價。我們的建議是把它當成一次有計畫的遷移，留足測試時間，而不是趕在一次部署裡全部切換。

6.8 怎麼跟工程師說清楚我要的是初始 HTML 就有內容

最有效的溝通方式不是丟名詞，而是給驗收條件。我們通常直接說：上線前請對首頁、列表頁、詳情頁各抽一頁，按 Ctrl+U 檢視原始碼，主文字要能在裡面被搜尋到，而不是只在 F12 看得到。把這句話寫進驗收清單，比爭論該用哪種框架有用得多，因為它把抽象的需求變成一個能當場檢查、對錯分明的條件。真的有落差時，前端也能拿著同一份原始碼去對照，而不是停在各說各話。