4 種渲染策略 — AI 爬蟲看到的內容差異 SSG SSR Hybrid 純 SPA 建構時預先渲染 每次請求動態渲染 SSR + 用戶端水合 純用戶端 JS AI 看到 AI 看到 AI 看到 AI 看到 完整 HTML ✅ 完整 HTML ✅ 完整 HTML ✅ 空殼 ❌ 代表：Hugo / Astro / Jekyll / Docusaurus 代表：Next.js SSR / Nuxt SSR / Rails 代表：Next.js (default) / Nuxt / SvelteKit 代表：CRA / 純 Vite / 老 Angular 引用率最高 引用率高 引用率視 hydration 引用率近 0 關鍵：GPTBot / ClaudeBot / CCBot 等多數訓練爬蟲不跑 JS

關鍵事實：多數 AI 爬蟲不跑 JavaScript

這個事實多數工程師知道但多數老闆不知道——因此導致大量「我們花百萬做了漂亮的 SPA 但 AI 引用 0」的故事。

下表整理 2026 年主要 AI 爬蟲的 JS 執行能力（依各家公開文件 + 第三方測試的綜合觀察，個別行為可能隨時間變化）：

爬蟲 是否執行 JavaScript 用途
GPTBot（OpenAI 訓練） ❌ 不執行 訓練語料抓取
ChatGPT-User（即時引用） ⚠️ 部分執行（簡單 JS） 對話即時引用
ClaudeBot（Anthropic 訓練） ❌ 不執行 訓練語料抓取
PerplexityBot（Perplexity） ⚠️ 部分執行 搜尋 + 即時引用
Google-Extended（Gemini 訓練） ⚠️ 部分執行（共用 Googlebot） 訓練語料
CCBot（Common Crawl） ❌ 不執行 開放資料集，多家 LLM 採用
Googlebot ✅ 執行（Chrome renderer） Google 搜尋索引
Bingbot ⚠️ 部分執行 Bing + ChatGPT browse

結論：

  • 訓練語料抓取（GPTBot / ClaudeBot / CCBot）幾乎都不執行 JS
  • 即時引用（ChatGPT-User / PerplexityBot）部分執行簡單 JS，但複雜的 React / Vue hydration 多半失敗
  • 只有 Google 自家爬蟲完整執行 JS（這也是為什麼 SEO 圈過去覺得「JS 不影響搜尋」——只就 Google 而言）

怎麼快速驗證你網站屬於哪種

開終端機，跑：

# 模擬 GPTBot 看到的內容
curl -A "Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)" \
     -L https://yoursite.com/ | grep -c "你網站某個關鍵內容"

換掉「你網站某個關鍵內容」為一段你期望出現的文字（例：你的服務名稱、客戶見證關鍵字）。

判斷：

  • 回 1 或更多 → AI 看得到：SSR / SSG / Hybrid
  • 回 0 → AI 看不到：純 SPA 或被擋
  • 回 0 但瀏覽器看得到 → 典型 SPA 殼問題

進階驗證（看完整 HTML 大小）：

curl -s -A "GPTBot/1.0" https://yoursite.com/ | wc -c

判斷：

  • < 5,000 byte 且 <body> 接近空 → 純 SPA
  • 5,000–50,000 byte 含實質內容 → SSR / SSG / Hybrid 之一

  • 100,000 byte → 可能 SSR 但有大量 inline JS / CSS（HTML 容量 dim 會扣分）

4 種渲染策略詳解

策略 1：SSG（Static Site Generation）— 引用率最高

代表：Hugo、Astro、Jekyll、11ty、Docusaurus、Next.js export、Gatsby

運作方式：建構時把每一頁預先 render 成 HTML，部署時是純靜態檔案。

對 AI 爬蟲：完美。AI 拿到的就是完整渲染好的 HTML，不需執行任何 JS。

好處： - 每個 URL 對應一個 .html 檔案 - CDN 快取友善（任何 CDN 都能服務靜態檔） - 載入速度極快 - 無伺服器運算成本

限制： - 內容更新需要重新建構（部署時間幾分鐘到幾小時） - 不適合動態內容多、即時資料的應用

適合：部落格、行銷網站、文件站、產品介紹站、Landing pages

策略 2：SSR（Server-Side Rendering）— 引用率高

代表：Next.js (getServerSideProps)、Nuxt SSR、Rails + ERB、Django、Laravel + Blade

運作方式：每次 HTTP 請求時伺服器即時 render HTML 回傳。

對 AI 爬蟲：完美。每次請求都是完整 HTML。

好處： - 內容即時、無需建構步驟 - 可依使用者個人化（登入狀態 / 地區 / 語系） - 適合電商、社群、儀表板

限制： - 每次請求都需伺服器運算（有營運成本） - TTFB（Time To First Byte）較慢 - CDN 快取需要更精細設計

適合：電商、會員制應用、頻繁更新的內容站

策略 3：Hybrid（SSR + Client Hydration）— 引用率視實作

代表：Next.js (default)、Nuxt、SvelteKit、Remix、Astro Islands

運作方式： 1. 第一次請求：伺服器 render 完整 HTML（AI 看得到） 2. 後續互動：用戶端 React/Vue/Svelte 接管，JS 渲染剩餘內容

對 AI 爬蟲：取決於關鍵內容是否在初始 HTML

好處： - AI 拿到第一份完整 HTML - 使用者互動體驗等同 SPA - 兼顧 SEO 與 UX

陷阱： - 如果關鍵內容（產品列表、文章正文、FAQ）是 client-side fetch + render，AI 還是看不到 - Hydration mismatch 可能讓 AI 看到的版本與真人看到的不一致 - M3-18 修的就是這類問題：geoweb.tw 早期 <article id="seo-content"> 預先渲染但 SPA hydrate 時被 empty() 清掉，AI 第二次重訪時看到空殼

適合：絕大多數 modern web 應用，但必須做 SEO 內容檢查（用 curl 驗證關鍵內容在初始 HTML）

策略 4：純 SPA（Single Page Application）— 引用率近 0

代表：Create React App、純 Vite + React、舊 Angular（無 Universal）、純 Vue CLI

運作方式： 1. 第一次請求：伺服器只回傳一個近乎空的 <div id="app"></div> HTML 殼 2. JS bundle 載入後 → fetch API → render 內容

對 AI 爬蟲：致命。AI 拿到的就是空殼，看不到任何內容。

典型 curl 結果：

<!DOCTYPE html>
<html>
<head>
  <title>Your Site</title>
</head>
<body>
  <div id="root"></div>
  <script src="/static/js/main.abc123.js"></script>
</body>
</html>

這就是 AI 看到的全部。沒有產品介紹、沒有部落格內容、沒有任何文字資訊。

為什麼還有人用純 SPA：

  • 開發者經驗熟悉、容易上手
  • 部署簡單（純靜態檔案 → CDN）
  • 早期 React/Vue tutorial 都教這個
  • 誤以為 Google 能完全 render JS = 沒問題（實際上 Google 也有限制）

修法：

不能直接「升級到 SSR」（往往要重寫整個架構），但有三條路：

修法 A：用 prerender service

服務（Prerender.io、Rendertron）依 User-Agent 偵測爬蟲，動態 render 後回傳 HTML。

  • 優點：不需重寫
  • 缺點：付費服務、可能被 AI 廠商視為 cloaking

修法 B：遷移到 Next.js / Nuxt

把現有 React/Vue 程式碼漸進遷移到 SSR 框架。

  • 優點：架構長期正確
  • 缺點：工程量大（中型專案 1–3 個月）

修法 C：在 SPA 殼內預先渲染關鍵內容

在 index.html 內手動嵌入關鍵 SEO 內容（首頁的服務介紹、FAQ、客戶見證）作為 <noscript> 或預設可見的 <article>，SPA hydrate 後再決定要不要隱藏。

  • 優點：最小修改、立即見效
  • 缺點：手動維護、可能 desync
  • 範例：geoweb.tw 自家就用這招（M3-18），<article id="seo-content"> 與 <div id="app-root"> 並列，CSS 控制可見性

一個常見的工程誤判

「Googlebot 都能 render JS 了，AI 應該也可以吧？」

這個推論錯在三個地方：

  1. Googlebot 的 JS 執行有 timeout（通常 5 秒）。如果你的 hydration 超過 5 秒，內容還是看不到
  2. 訓練爬蟲（GPTBot / ClaudeBot / CCBot）跟 Googlebot 是不同基礎設施，他們沒拿到 Chrome renderer
  3. 即時引用爬蟲（ChatGPT-User / PerplexityBot）有 latency budget（使用者等不及），通常只跑簡單 JS

結論：「Googlebot OK」不能推論到 AI 爬蟲 OK。要分開驗證。

量測：你網站每個關鍵頁的「無 JS 可見內容」

跑下面這個 shell 腳本檢查多個頁面：

#!/bin/bash
URLS=(
  "https://yoursite.com/"
  "https://yoursite.com/products"
  "https://yoursite.com/about"
  "https://yoursite.com/blog"
  "https://yoursite.com/contact"
)

for url in "${URLS[@]}"; do
  size=$(curl -s -A "GPTBot/1.0" "$url" | wc -c)
  echo "$url  →  ${size} bytes"
done

健康指標：每頁 ≥ 10,000 bytes 且含實質文字內容。

如果有任何頁 < 5,000 bytes，那一頁對 AI 等於不存在。

一個容易被忽略的策略：llms.txt

無論你用哪種渲染策略，可以建立 /llms.txt 作為純文字 fallback：

# Your Company

Your Company 是 [一句話介紹], 專注於 [服務領域].

## 主要服務

- 服務 A: [簡短描述]
- 服務 B: [簡短描述]

## 聯絡

Email: [email protected]
Website: https://yoursite.com/

這個檔案 AI 爬蟲特別喜歡（已成事實標準），即便你的主站是 JS-heavy SPA，至少 /llms.txt 給 AI 一個可靠的事實源。

詳細規範見前篇：GPTBot / ClaudeBot / PerplexityBot — 8 大 AI 爬蟲規則差異與最佳設定

第一步：用 curl 驗證你網站對 AI 的能見度

跑本文「快速驗證」段的 curl 指令，看你網站對 GPTBot 是 SSR/SSG/Hybrid/純 SPA 哪一種。

如果是純 SPA：你的 GEO 投資 ROI 會接近 0，無論寫多少內容都白做。先解決渲染問題。

👉 跑 GeoWeb 健檢看完整 12 維度評估 — 健檢的「HTML 容量」與「語意結構」維度會反映出 SPA 殼問題。

渲染策略遷移是工程級專案（中型專案 1–3 個月），不適合邊做邊摸。框架選型、漸進遷移計畫、效能基準對比、AI 爬蟲驗證、跨團隊（前端 / 後端 / DevOps / SEO）協調——這些每一項決策錯一次都可能讓網站好幾個月不能服務。GEO 託管包含工程顧問評估，避免企業自己摸坑：[email protected]

GEO 深度系列。前一篇：「整站跨頁一致性 — 為什麼模板雷同會被 AI 降權」