你的網站排在 Google 第一頁，轉換也漂亮，但你去問 ChatGPT、Perplexity 同一個問題，它的答案裡完全沒有你。這不是因為內容寫得差，而是因為這兩件事根本不是同一回事——能在 Google 拿到排名，不保證 AI 引擎讀得到你。多數人以為「Google 爬得動的網站，AI 也爬得動」，這個假設在現在已經是錯的。
差別出在前端渲染方式。CSR、SSR、SSG 這三種架構決定了爬蟲第一眼拿到的是「一份完整的網頁」，還是「一個空殼」。Google 這幾年已經能把空殼補完，但多數 AI 爬蟲不會——它只讀最初送來的 HTML，讀不到就直接換下一個來源。也就是說，同一個架構選擇，會同時牽動你在 SSR SSG SEO 表現上的兩條戰線——搜尋排名，以及能不能被 AI 引用。
這篇就把三種渲染方式攤開來比，從爬蟲實際看到什麼講起，再用一張對照表把 Google 可見度、AI 爬蟲可見度、實作成本一次說清楚，最後給你一個依頁面類型的選法。
渲染方式指的是什麼？為什麼它會決定爬蟲看到的內容
先把一個常被跳過的前提講清楚：渲染（Rendering），就是把 HTML、JavaScript、資料這些程式碼，組合成使用者眼睛看得到的網頁畫面的那個過程。重點不在使用者那端——不管哪種方式，使用者最後都看得到完整畫面——而在於這個組合動作是在哪裡、什麼時候發生。
這件事之所以跟 SEO、跟 AI 引用直接相關，是因為爬蟲跟人不一樣。人的瀏覽器會乖乖把 JavaScript 跑完、等畫面長出來再看；很多爬蟲不會。它向你的伺服器發出請求，伺服器回什麼，它就讀什麼。如果回給它的是一份還沒被 JavaScript 填上內容的空白頁，它看到的就是空白頁。
所以三種架構真正的分野，就在內容是在哪一刻被放進 HTML。CSR 是等到使用者的瀏覽器把 JavaScript 跑完才放；SSR 是伺服器在回應每一次請求時當場放好；SSG 則是在網站建置（Build）的階段就預先放好。誰先把內容塞進那份最初的 HTML，誰就對爬蟲友善。先從最常造成麻煩的 CSR 看起。
CSR 為什麼對搜尋與 AI 都最不友善？
CSR（Client-Side Rendering，客戶端渲染）的問題，在於它把組裝畫面的工作整個丟給使用者的瀏覽器。伺服器一開始只回一份幾乎空白的 HTML，裡頭通常只有一個空的容器標籤，像是 <div id="root"></div>，真正的內容要等瀏覽器載入 JavaScript、向 API 要到資料，才動態渲染出來。
對使用者來說這還行，頂多是首次載入時多轉幾圈。但對爬蟲來說，這就是災難。多數爬蟲是直接拿伺服器回應的那份原始 HTML 來分析的——它拿到的就是那個空殼，裡面沒有標題、沒有內文、沒有結構化資料，只有一個空容器和一堆 JavaScript 檔案的引用。
在 Google 這端，問題還算有解。Google 官方表態過好幾次，Googlebot 能讀懂 CSR 頁面，它會把頁面排進一個額外的渲染佇列，事後再把 JavaScript 跑完、補上內容。Google 對自家渲染能力的信心也越來越足，甚至在最近已經把沿用多年的「JavaScript SEO 警告」從開發者文件裡正式移除。不過實務上觀察，CSR 頁面的檢索效率普遍比較差，這套「兩階段處理」會延遲索引，遇到資源被擋、佇列塞車時還可能漏抓。
真正麻煩的是 AI 這端。Google 願意花多年工程去處理 JavaScript 渲染，AI 爬蟲沒有做這筆投資——它們的任務是「快速抓內容來生成答案」，不是把每個頁面都耐心渲染一遍。對一個純 CSR 的網站來說，AI 爬蟲拿到空殼、讀不到任何實質內容，引用率幾乎等於零。你在 Google 解決掉的 JavaScript 問題，到了 AI 這邊得從頭再來一次。
SSR、SSG 各自怎麼運作？哪一種更快
如果 CSR 是把組裝工作外包給使用者，那 SSR 和 SSG 就是反過來，由伺服器或建置流程先把內容備好。兩者方向一致，差別在「什麼時候備」。
SSR（Server-Side Rendering，伺服器端渲染）是在伺服器端，針對每一次請求當場生成完整的 HTML。使用者一發出請求，伺服器就去資料庫或 API 把資料撈好、組成完整頁面，再把這份「內容都已經填好」的 HTML 回給瀏覽器。爬蟲第一眼拿到的就是完整內容，這也是它對 SEO 與 AI 都友善的原因。代價是伺服器每次請求都要重算一遍，負擔比較重，而且使用者拿到第一個位元組的時間（TTFB）會稍微長一點。
SSG（Static Site Generation，靜態網站生成）走的是另一條路。它在網站建置的階段就把所有頁面預先生成成一份份靜態 HTML 檔，使用者請求時直接把現成的檔案送出去，不必當場運算。因為檔案是現成的、又能塞進 CDN 快取，SSG 的載入速度通常是三者裡最快的，伺服器負擔也最低。
速度上，大致的排序是 SSG 最快、SSR 居中、CSR 最慢看到完整內容。SSG 因為內容在建置時就定型了，最適合不常變動的頁面，例如部落格文章、產品說明、技術文件；SSR 則適合內容會頻繁更新、或需要依使用者個人化的頁面。值得補一句，兩者之間還有一個折衷選項叫 ISR（Incremental Static Regeneration，增量靜態再生），它讓 SSG 的靜態頁能依設定的時間在背景自動重新生成，兼顧靜態的速度與一定程度的內容新鮮度，電商與新聞類網站常用。
多數 AI 爬蟲不執行 JavaScript，這對你意味著什麼
這是整件事的核心事實，也是最多人沒搞清楚的一點——目前主流的 AI 爬蟲，幾乎都不執行 JavaScript。 它們只讀伺服器回的原始 HTML，JavaScript 之後才長出來的內容，它一概看不到。
這不是猜測，而是有大規模數據支撐的。Vercel 與 MERJ 合作分析了超過 5 億次 GPTBot 的抓取行為，結果是「零」——找不到任何執行 JavaScript 的證據。即使 GPTBot 會去下載 JavaScript 檔案（約有 11.5% 的情況會下載），它也只是下載，並不會真的去執行。另一份對 23 個 AI 爬蟲的分析也指出，大約 69% 的 AI 爬蟲無法執行 JavaScript，只能解析原始 HTML。截至目前，主流的 AI 爬蟲——包括 OpenAI 的 GPTBot、Anthropic 的 ClaudeBot、PerplexityBot 等——普遍都不渲染 JavaScript，少數的明顯例外是 Google 的 Gemini，因為它沿用了 Googlebot 那套會執行 JavaScript 的渲染基礎設施。
把這個事實跟前面的架構放在一起，結論就很直接了。一個純 CSR 的頁面，回給 AI 爬蟲的是空殼，於是你的產品描述、比較表格、FAQ 答案——這些最值得被引用的內容——AI 全都讀不到。Google 排第一、轉換又好的頁面，可以同時完全消失在 AI 生成的答案裡，這兩件事是會默默並存的。
順帶一提，這條戰線的流量規模也不算小了。同一份 Vercel 的觀測裡，GPTBot 在一個月內產生了約 5.69 億次請求，Claude 緊接在後約 3.7 億次，兩者合計已經接近 Googlebot 同期請求量的兩成。AI 爬蟲不再是邊角，它正在穩定地抓取整個網路。
三種架構怎麼比較？看 Google 可見度、AI 爬蟲、實作成本三項
把前面拆開講的東西收進一張表，你大概就能一眼看出取捨在哪。這張表比的不只是「SEO 友不友善」，而是把 SEO 拆成 Google 與 AI 兩條獨立的可見度，再加上一欄實作成本——因為對多數團隊來說，後者才是真正會卡住決策的點。
| 渲染方式 | Google 可見度 | AI 爬蟲可見度 | 實作成本 |
|---|---|---|---|
| CSR 客戶端渲染 | 普通（靠額外渲染佇列補，索引慢、偶有漏抓） | 極低（回空殼，引用率幾乎為零） | 低（前端框架預設，最易上手） |
| SSR 伺服器端渲染 | 高（首抓即完整 HTML，索引快） | 高（原始 HTML 就含完整內容） | 中高（需伺服器運算，架構較重） |
| SSG 靜態網站生成 | 高（預生成靜態 HTML，可 CDN 快取） | 高（靜態 HTML 完整可讀） | 中（需建置流程，適合內容穩定的頁） |
有幾個重點值得從表裡拉出來講。第一，CSR 的兩欄可見度是不對稱的：它在 Google 那欄勉強及格，是因為 Google 願意花力氣替它補渲染；但 AI 那欄幾乎是空的，因為 AI 不補。很多人看 CSR 的 SEO「還可以」就放心了，卻沒注意到 AI 這欄整片空白。
第二，SSR 與 SSG 在兩條可見度上幾乎打平，差別主要落在實作成本與內容性質。SSG 成本中等、速度最快，但只適合不常變動的內容；SSR 成本較高、能處理即時與個人化內容。第三，CSR 的低成本是有代價的——省下的工，全部變成日後在 AI 可見度上的損失。如果你的內容根本不靠 AI 曝光，這代價或許划算；但只要你想被引用，這筆帳就不划算。
哪些頁面最該優先換掉 CSR
不是每個頁面都同等重要。最該優先處理的，剛好是「引用價值最高、卻又最常被做成 CSR」的那幾類頁面——這兩件事重疊在一起，就是最大的隱形損失。
值得優先盤點的，是這幾種：
- 產品與功能頁：規格、價格、功能描述如果是靠 JavaScript 才載入，最可能想引用它的 AI 引擎反而讀不到。
- 比較與替代方案頁：比較表是 AI 最愛直接擷取的格式之一，但若整張表是客戶端渲染出來的，對 AI 爬蟲就是隱形的。這類內容偏偏又是購買決策階段最關鍵的。
- 技術文件與說明頁：AI 在回答資訊型與評估型問題時，特別偏好結構清楚的問答式內容；這類頁面若靠 JavaScript 渲染，再怎麼寫得好也發揮不出引用潛力。
- 分類頁與到達頁：這些頁面負責建立主題權威訊號，內容若被客戶端渲染掉，等於把權威訊號一起渲染掉了。
換句話說，越是你拿來說服別人、拿來成交的頁面，越不該讓它的核心內容只活在 JavaScript 跑完之後的畫面裡。一個可靠的判準是：只要這段內容攸關引用、信任或成交，它就該出現在最初那份 HTML 裡。
怎麼判斷 AI 爬蟲讀不讀得到你的內容
在動手改架構之前，先花五分鐘確認你真的有問題，而不是憑感覺瞎改。有幾個不必裝任何工具就能做的檢查。
最快的一招是看原始碼。在瀏覽器打開你最重要的頁面，選「檢視網頁原始碼」（View Source），注意不是「檢查元素」（Inspect）——後者顯示的是 JavaScript 跑完後的畫面，前者才是伺服器回的原始 HTML。在原始碼裡搜尋你的主標題、內文、產品描述，如果這些東西在畫面上看得到、在原始碼裡卻找不到，那就是渲染落差，AI 爬蟲看到的也是少了這些內容的版本。
第二招是把瀏覽器的 JavaScript 關掉再重新載入頁面。如果頁面變成一片空白或掉光了主要內容，那 AI 爬蟲多半也是看到同一個空版本。
第三招是用指令列發一個 cURL 請求去抓那個網址，伺服器回的就是大多數爬蟲第一次抓到的原始 HTML，直接檢查內容完不完整。如果你有在看伺服器紀錄，還可以進一步比對：當 GPTBot、ClaudeBot、PerplexityBot 這些 User-Agent 造訪的頁面，它們抓到的原始 HTML 是不是很單薄。三招裡任何一招發現內容對不上，就代表你有實打實的渲染落差要補。
想同時顧好 Google 與 AI，前端架構該怎麼選
收束成一句可以直接執行的原則：只要這段內容你希望被搜尋到、被引用、或拿去成交，就讓它出現在伺服器最初回的那份 HTML 裡。 至於用哪種方式做到，依頁面性質分配，不必整站綁死同一種。
內容穩定、不太需要即時更新的頁面，例如部落格、技術文件、資源頁，優先用 SSG，速度最快又完全可被爬取。內容會頻繁變動、或需要依使用者個人化的頁面，用 SSR，讓伺服器在回應時就把內容備好。介於兩者之間、想兼顧靜態速度與內容新鮮度的，可以考慮 ISR。
那如果現有網站已經是重度 CSR、短期內難以整個翻掉呢？有兩條折衷路。一是預渲染（Prerendering），它替爬蟲生成靜態 HTML 快照，讓爬蟲拿到完整內容，使用者那端仍維持原本的 JavaScript 體驗，特別適合行銷頁、長青內容這類動態需求不高的頁面。二是混合渲染，把實質內容——標題、內文、產品描述、FAQ、價格——放進最初的 HTML，互動性的增強功能再用 JavaScript 疊上去。
最後補一個常被混淆的點。把內容放進可讀的 HTML 是地基，結構化資料（Schema）是加分項，不是替代品。AI 是先讀頁面上看得到的文字，再參考結構化標註去理解；一個「Schema 做滿、可見內容卻很單薄」的頁面，不會因為標註漂亮就被引用。順序永遠都一樣，先讓內容讀得到，再談怎麼讓它更好被理解。
選架構從來不是選一個「最好的」，而是在 Google 可見度、AI 可見度、實作成本與內容性質之間找平衡。差別只在於，過去這個平衡只要對得起 Google，現在還得對得起那些不幫你跑 JavaScript 的 AI 爬蟲——而它們，正在決定你會不會出現在下一個人問 AI 的那句答案裡。