當工程師說「我們用 React 做一個 SPA 吧」的時候，SEO 團隊往往同時皺起眉頭。JavaScript 框架帶來了流暢的使用者體驗，卻在搜尋引擎爬蟲眼中製造了一道隱形的高牆。這道牆若不處理，可能讓整個網站從 Google 索引中消失——即使你的內容寫得再好。
到了 2026 年，問題又多了一層：你不只要讓 Googlebot 看到內容，還得面對 ChatGPT、Perplexity 這類幾乎不執行 JavaScript 的 AI 搜尋爬蟲。本文從 Google 的渲染機制講起，一路帶到可立即落地的解法。
Googlebot 讀你的網頁，其實分成三個獨立階段
想解決 JavaScript SEO，得先搞清楚 Google 到底怎麼「閱讀」一個頁面。整個流程拆成三段，而問題就藏在它們之間的縫隙裡。
- 爬取（Crawling）：Googlebot 先抓原始 HTML。如果頁面內容全靠 JavaScript 生成，此刻爬蟲看到的只是一個空殼
<div id="app"></div>。 - 渲染（Rendering）：Google 的網頁渲染服務（Web Rendering Service, WRS）用無頭版 Chromium 執行 JavaScript，像瀏覽器一樣補完內容。但這步會被排進渲染佇列（Rendering Queue），延遲可能是幾秒，也可能是幾天。
- 索引（Indexing）：Google 根據渲染後的 HTML 決定哪些內容進入索引，這時才開始做關鍵字匹配與排名計算。
最大的陷阱就在這裡：就算 Google 最終能把頁面渲染出來，「爬取到索引」之間的延遲，可能讓新內容等上好幾天才被收錄。對剛上線的頁面、或需要立刻被看見的重要更新來說，這種等待是無法接受的。
CSR、SSR、SSG、ISR：四種渲染策略該怎麼選？
| 渲染策略 | SEO 友善度 | 首次載入速度 | 適用場景 | 代表框架 |
|---|---|---|---|---|
| CSR（客戶端渲染） | ⚠️ 有風險 | 慢（需等 JS 執行） | 私人儀表板、後台管理 | Create React App、Vite SPA |
| SSR（伺服器端渲染） | ✅ 最佳 | 快（HTML 直接回傳） | 電商、新聞、部落格 | Next.js、Nuxt.js |
| SSG（靜態網站生成） | ✅ 最佳 | 最快（預建 HTML 檔案） | 文件、行銷頁面、部落格 | Next.js、Gatsby、Astro |
| ISR（增量靜態再生） | ✅ 良好 | 快（緩存 + 按需更新） | 資料頻繁更新的大型網站 | Next.js 14+ |
2026 年的主流做法是混合渲染（Hybrid Rendering）：公開且重視 SEO 的頁面（首頁、商品頁、部落格）走 SSR 或 SSG；需要互動但不必被索引的頁面（購物車、帳戶設定）才用 CSR。一個架構同時照顧排名與體驗。這套邏輯和 Core Web Vitals 的優化思路是相通的——更快交付 HTML，LCP 與 FID 也跟著一起變好。
SPA 最容易踩的三個 SEO 地雷
地雷一：所有頁面共用同一組 title 與 meta description
在傳統多頁網站（MPA）裡，每個 HTML 檔案各自帶 <title> 和 <meta>。但 SPA 整站只有一份 HTML，所有「頁面」都是 JavaScript 動態切換出來的。如果不特別處理，每一頁的 title 和 meta description 都會長得一模一樣，Google 既分不出頁面差異，也無法在搜尋結果裡正確呈現。
解法是用專門套件動態更新 meta 標籤：
- React：
react-helmet-async，或 Next.js 的Metadata API - Vue：
@vueuse/head，或 Nuxt.js 的useHead - Angular：搭配 Angular Universal 使用
Meta與Titleservice
地雷二：用 Hash 路由，等於整站只有一頁被索引
早期 SPA 愛用 Hash 路由（像 example.com/#/products/123），讓不同「頁面」共用同一個 URL 前綴。問題是 Googlebot 只認得 example.com/，# 後面的部分完全被忽略——對爬蟲來說，整站實際上只有一頁存在。
解法是改用 HTML5 History API（即 pushState 路由），讓每個 SPA 視圖都擁有獨立的完整 URL，例如 example.com/products/123。React Router v6+、Vue Router 4+ 預設就支援 History 模式，你只需確保後端伺服器能正確處理 SPA fallback 路由。
地雷三：核心內容藏在互動後才載入的元件裡
Lazy loading 是很好的效能工具，但如果把核心 SEO 內容（H1 標題、主要段落、產品描述）塞進「點按鈕或捲動之後才載入」的元件，Googlebot 很可能永遠看不到它們。
原則很簡單：主要 SEO 內容必須出現在初始 HTML 裡（透過 SSR 或預渲染）。FAQ 展開、Tab 切換這類互動元素可以 lazy load，但首屏該顯示的文字和標題不行。同樣的道理也適用於 Schema 結構化資料——Schema 標記要寫進初始 HTML，而不是靠 JavaScript 事後注入。
動態渲染為什麼已經被 Google 判出局？
動態渲染（Dynamic Rendering）曾是 Google 官方點頭的過渡方案：給一般使用者送 CSR 版本，給爬蟲送預先渲染好的靜態 HTML。Rendertron、Puppeteer、Prerender.io 都能做到這件事。
但 Google 已在最新文件中把它標記為「已棄用的暫時方案（Deprecated Workaround）」，並明說長期該轉向 SSR 或 SSG。原因有二：
- 維護兩套渲染邏輯（一套給人、一套給爬蟲）成本高，還有「兩版內容不一致」的隱患。
- 現代框架的 SSR 支援早已成熟，根本不需要再繞這條路。
如果你現在還靠動態渲染撐著，建議盡早排一份遷移計畫，往 Next.js、Nuxt.js 或 Astro 升級。
AI 爬蟲幾乎不跑 JavaScript，這是新的勝負手
就在 Googlebot 越來越擅長處理 JavaScript 的同時，AI 搜尋帶來了一個更棘手的事實：ChatGPT、Perplexity、Claude 的爬蟲幾乎完全不執行 JavaScript。
這代表如果你的 Next.js 網站有任何頁面的核心內容依賴 Client-Side Fetching（例如用 SWR、React Query 從 API 拉資料），那些內容在 AI 搜尋的世界裡等於不存在。在 AEO（答案引擎優化）的年代，這非常致命——AI 沒辦法引用它根本看不到的東西。
| 爬蟲 | JavaScript 支援 | 建議 |
|---|---|---|
| Googlebot | ✅ 支援（有延遲） | SSR/SSG 確保即時索引 |
| Bingbot | ⚠️ 部分支援 | SSR 最安全 |
| GPTBot（ChatGPT） | ❌ 不支援 | 所有內容必須在初始 HTML |
| PerplexityBot | ❌ 不支援 | 所有內容必須在初始 HTML |
| ClaudeBot | ❌ 不支援 | 所有內容必須在初始 HTML |
2026 年的目標已經不只是「讓 Google 看得到」，而是「讓所有重要爬蟲，不執行任何一行 JavaScript，就能讀到你的核心內容」。
React Server Components：目前最乾淨的解法
Next.js 13+ 引入的 React Server Components（RSC），幾乎是為 JavaScript SEO 量身打造的答案。它的核心想法是：把不需要互動的 React 元件放在伺服器執行，只向瀏覽器送出純 HTML，完全不附帶對應的 JavaScript bundle。
這一招同時帶來三個好處：
- SEO 一步到位：所有伺服器元件的內容都進了初始 HTML，Google 和 AI 爬蟲都能立刻讀到。
- 效能顯著提升：JavaScript bundle 體積可降低 50-60%，Core Web Vitals 分數跟著改善。
- 開發更省事：資料獲取能直接在伺服器元件裡完成，省掉一堆繁瑣的 useEffect。
如果你目前用的是 Create React App 或純 Vite SPA，現在就是認真評估遷移到 Next.js App Router 的時機。技術債只會隨著網站規模越長越大。
懷疑網站有 JS SEO 問題？這五個工具先跑一遍
- Google Search Console → URL 檢查工具：輸入任一 URL，點「測試即時 URL」，直接看 Googlebot 渲染後拿到的 HTML 快照與截圖。最直接的診斷方式。
- 「檢視原始碼」對比「開發人員工具 → Elements」：原始碼（Ctrl+U）是爬蟲初始看到的 HTML；Elements 面板是 JS 執行後的 DOM。兩者落差越大，SEO 風險越高。
- curl 測試：
curl -s "https://yoursite.com/page" | grep -i "your-keyword"。如果抓不到關鍵字，代表該內容依賴 JS 渲染，爬蟲很可能看不到。 - Screaming Frog：把爬取模式分別設成「JavaScript」與「純 HTML」，比對兩種模式的索引差異，揪出問題頁面。
- Rich Results Test：驗證 Schema 結構化資料是否被正確辨識，確認它不是由純 CSR 注入的。
上線前對照用：JavaScript SEO 八項實作清單
- 公開頁面確認使用 SSR 或 SSG，而非純 CSR。
- 每頁都有動態設定的
<title>、<meta name="description">與 canonical URL。 - 改用 History API 路由，棄用 Hash 路由。
- 主要文字內容在初始 HTML 中可見，不依賴 scroll 或 click 觸發。
- Schema 標記在伺服器端注入，而非靠 JS 動態插入。
- 避免動態渲染（Rendertron），並排定遷移至 SSR/SSG 的時程。
- 用 Google Search Console URL 檢查工具逐一驗證重要頁面。
- 評估導入 React Server Components 或 Astro 的 Islands 架構。
TOPCLASS 觀點：渲染策略是內容能否被看見的前提
框架選擇沒有絕對的對錯，但用錯了場景，代價往往很高。在 TOPCLASS 的顧問實務裡，我們看過太多用心寫出的內容石沉大海：一個漂亮的 React SPA，因為沒做 SSR，在 Google 眼中只是一張白紙。
2026 年的難處是雙面的——Googlebot 雖然會跑 JS，但有延遲；AI 搜尋爬蟲則根本不跑。換句話說，「讓爬蟲在不執行 JavaScript 的情況下也能讀到核心內容」已經從加分項，變成最低門檻。
我們的建議是：把 JavaScript SEO 直接納入每一次前端架構決策的評估項。選 Next.js 而非純 Vite SPA、選 Server Components 而非純 Client Components，這些決定通常要等三到六個月才會在搜尋流量上現形——而那個差距，有時是天壤之別。