JavaScript SEO 介紹：Google 爬蟲、渲染與網站收錄教學

JavaScript SEO 是 SEO 裡面很重要、但也很容易被忽略的技術重點。

如果你的網站是用 React、Vue、Angular、Next.js、Nuxt，或是很多內容都靠 JavaScript 載入，那你就不能只看「使用者打開網頁後看不看得到」，還要確認 Google 這類搜尋引擎到底看不看得到。

特別是 vibe coding 的網站，特別容易有這個問題。

很多網站明明畫面很漂亮、互動很順，但 Google 實際看到的可能是一個空白頁、一個 Loading 畫面，或是少了標題、內文、商品資訊與內部連結。

這篇文章會用新手也能理解的方式，介紹 JavaScript SEO 是什麼、Google 怎麼處理 JavaScript、常見錯誤、檢查方法，以及什麼情況該用 SSR、SSG 或 CSR。

---

JavaScript SEO 是什麼？

JavaScript SEO 指的是：當網站內容、連結、標題、圖片、結構化資料或頁面狀態需要透過 JavaScript 才會出現時，我們要確保搜尋引擎仍然能正確抓取、渲染、理解與索引這些內容。

JavaScript SEO 處理的是：搜尋引擎看到的網頁，是否和使用者看到的網頁差不多？

舉例來說，你打開一個商品頁，畫面上有商品名稱、價格、庫存、圖片、評論與購買按鈕。但如果 Googlebot 抓到的 HTML 裡只有一個空的 <div id="app">，其他內容都要等 JavaScript 執行後才出現，那這個頁面就需要特別檢查 JavaScript SEO。

Google 官方文件說明，Google Search 處理 JavaScript 網頁時，大致會經過三個階段：Crawling、Rendering、Indexing。

• Crawling：Googlebot 先抓取網址與 HTML、CSS、JavaScript 等資源。
• Rendering：Google 使用類似現代瀏覽器的方式執行 JavaScript，產生渲染後的頁面。
• Indexing：Google 再根據可取得的內容與訊號，決定如何理解與索引這個頁面。

參考資料（必讀）： 瞭解 JavaScript 搜尋引擎最佳化 (SEO) 基礎知識

---

Google 看得懂 JavaScript 嗎？

答案是：多數情況下，Google 可以看懂 JavaScript，但這不代表你可以完全放心。

Google Search 現在會使用 evergreen Chromium 執行 JavaScript，也就是它不是只能看最原始的 HTML。這代表許多 React、Vue、Angular 或其他前端框架做出來的內容，Google 有機會在渲染後看到。

但問題是：「有機會看到」不等於「一定穩定看到」。

如果你的 JavaScript 檔案被 robots.txt 擋住、API 請求失敗、頁面載入太慢、程式碼報錯、內容需要使用者點擊才載入，或伺服器回應狀態碼不正確，Google 仍然可能看不到重要內容。

所以 JavaScript SEO 的重點不是跟你說「JavaScript 不能用」，而是提醒你：重要內容不要過度依賴不穩定的前端流程。

---

JavaScript SEO 常見的錯誤

以下幾種問題，是新手最常遇到的。

1. 使用者看得到，但 Google 看不到

這是最典型的 JavaScript SEO 問題。

網站在瀏覽器中看起來很正常，但 Google 測試工具看到的內容卻不完整。常見原因包括 JavaScript 錯誤、API 被擋、內容延遲載入，或重要區塊需要使用者互動後才出現。

例如文章頁的正文、商品頁的價格、分類頁的商品列表，如果都是 JavaScript 後載入，就要特別確認 Google 渲染後是否真的看得到。

2. 重要連結不是正常的 HTML 連結

搜尋引擎主要透過連結發現新頁面。

如果你的網站把商品卡片、文章卡片、分類連結做成 button 或 onclick，但沒有正常的 <a href="...">，搜尋引擎可能比較難發現這些頁面。

比較安全的作法是：重要頁面之間的內部連結，盡量使用標準 HTML 連結。

3. SPA 頁面全部回傳 200

很多 Single Page Application 會把所有網址都導到同一個前端入口。

這樣如果沒有處理好，就可能出現一個問題：明明網址不存在，畫面也顯示「找不到頁面」，但 HTTP 狀態碼仍然回傳 200。

對搜尋引擎來說，這可能形成 soft 404，讓 Google 很難判斷這個頁面到底是不是有效內容。

不存在的頁面，應該要真的回傳 404 或 410；轉址頁面也應該正確回傳 301 或 302。

4. 用 JavaScript 改 title、canonical、robots

Google 可以處理部分 JavaScript 產生的 metadata，但不代表這是最穩定的做法。

如果原始 HTML 裡有一組 title、canonical，JavaScript 執行後又改成另一組，就可能造成訊號衝突。

尤其是 noindex 更要小心。Google 官方提醒，如果 Google 在原始 HTML 中看到 noindex，可能就不會繼續渲染頁面，因此不要期待用 JavaScript 事後把 noindex 移除。

如果你想更完整理解 canonical 與 noindex，可以延伸閱讀《SEO Canonical URL 標準網址：利用 rel canonical 解決重複內容》與《noindex 介紹：什麼是 noindex？對於 SEO 有何效果？》。

5. Lazy Loading 讓內容消失

Lazy loading 本身不是壞事，它可以改善網站速度與使用者體驗。

但如果文章內容、商品列表、評論、圖片或 FAQ 要等使用者滑動、點擊或觸發某些行為才載入，搜尋引擎不一定會看到完整內容。

Google 有專門的 lazy loading 指南，建議網站要確保延遲載入的內容仍然可以被 Google 抓取與索引。

參考資料：Google Lazy Loading SEO 指南

---

CSR、SSR、SSG 是什麼？哪一種比較適合 SEO？

談 JavaScript SEO，一定會遇到 CSR、SSR、SSG 這幾個詞。

CSR：Client-Side Rendering

CSR 是由瀏覽器下載 JavaScript 後，再由前端產生頁面內容。

React SPA、Vue SPA 常見的做法就是 CSR。它的好處是互動性高、前端開發彈性大，但對 SEO 來說，風險也比較高。

因為搜尋引擎必須等 JavaScript 執行成功後，才可能看到完整內容。

---

SSR：Server-Side Rendering

SSR 是伺服器先產生完整 HTML，再送給瀏覽器與搜尋引擎。

對 SEO 來說，SSR 通常比較安全，因為 Googlebot 一開始拿到的 HTML 就已經包含主要內容、標題與連結。

如果你做的是文章頁、商品頁、分類頁、品牌頁、Landing Page，通常都會更適合 SSR 或類似策略。

---

SSG：Static Site Generation

SSG 是在網站建置時，就先把頁面產生成靜態 HTML。

這很適合部落格、文件網站、教學文章、公司介紹、比較穩定的內容頁。速度通常很快，SEO 風險也低。

缺點是如果內容更新非常頻繁，就需要搭配重新建置、快取更新或 ISR 這類進階做法。

---

那到底該選哪一種？

如果你是新手，可以先這樣判斷：

• 內容型網站：優先考慮 SSG 或 SSR。
• 電商商品頁：優先考慮 SSR、SSG 或混合式渲染。
• 活動頁、品牌頁：可以用 SSG 或 SSR。
• 登入後的後台系統：SEO 通常不是重點，可以用 CSR。
• 高度互動的 Web App：CSR 可以接受，但公開頁面要另外處理 SEO。

重點不是「哪個技術最高級」，而是「哪個頁面真的需要被 Google 索引」。

參考資料：web.dev：Rendering on the Web

---

---

Dynamic Rendering 還推薦嗎？

以前很多 JavaScript SEO 教學會推薦 Dynamic Rendering，也就是：一般使用者看到前端渲染頁面，但搜尋引擎爬蟲看到預先渲染好的 HTML。

這個做法曾經很常被拿來解決 SPA SEO 問題。

但如今再看，這已經不適合被當成長期主要方案。

Google 官方目前把 Dynamic Rendering 定位為 workaround，也就是臨時性的替代方案，而不是推薦的長期解法。Google 更建議使用 server-side rendering、static rendering 或 hydration 這類方式。

原因很簡單：Dynamic Rendering 會增加系統複雜度、維護成本，也要小心不要讓搜尋引擎與使用者看到完全不同的內容，否則可能變成 cloaking 風險。

參考資料：Google Dynamic Rendering 說明

---

JavaScript SEO 要怎麼檢查？

如果你不是工程師，也可以做一些基本檢查。

步驟一：先選出重要頁面

不要一開始就檢查整個網站。

先挑幾種重要頁型，例如：

• 首頁
• 文章頁
• 分類頁
• 商品頁
• 活動頁
• 404 頁面

每一種頁型各挑 1～3 個網址，就可以先看出很多問題。

---

步驟二：查看原始碼

在網頁上按右鍵，選擇「檢視網頁原始碼」。

你要看的是：重要標題、內文、連結、canonical、robots meta、結構化資料，是不是一開始就在 HTML 裡。

如果你只看到一堆 JavaScript 檔案，內容幾乎都沒有，就代表這個頁面很可能高度依賴 JavaScript。

---

步驟三：用 Google Search Console 檢查

如果你有 Google Search Console 權限，可以使用「網址檢查」工具。

這個工具可以幫你看 Google 是否能抓取與渲染這個頁面，也能檢查頁面是否可索引。

對 JavaScript SEO 來說，這比你只看瀏覽器畫面可靠得多。

---

步驟四：用 Rich Results Test 檢查結構化資料

如果你的頁面有 FAQ、Article、Product、Recipe、Review 等結構化資料，可以用 Rich Results Test 檢查。

Google 官方也說明，Google 可以理解渲染後 DOM 裡的 JavaScript structured data，但商品頁要特別小心。

如果商品價格、庫存這種快速變動資訊全部靠 JavaScript 動態產生，可能會讓 Shopping 相關抓取變得比較不穩定。

參考資料：Google：Generate structured data with JavaScript

---

步驟五：檢查網站速度與互動體驗

JavaScript 太重，也會影響網站速度與互動體驗。

現在 Core Web Vitals 裡的重要互動指標是 INP，而不是以前的 FID。INP 會衡量使用者互動後，頁面多久能有下一次畫面反應。

如果網站塞了太多 JavaScript、第三方追蹤碼、動畫或大型套件，就可能讓 INP 變差。

參考資料：web.dev：INP became a Core Web Vital

---

JavaScript SEO 新手檢查清單

你可以照著下面這份清單檢查：

• 重要頁面是否有獨立、可分享、可抓取的 URL？
• 重要內容是否出現在原始 HTML 或渲染後 HTML 裡？
• 頁面 title、description、canonical 是否正確？
• robots meta 是否有誤放 noindex？
• 重要內部連結是否使用 <a href="...">？
• 不存在的頁面是否真的回傳 404 或 410？
• JavaScript、CSS、API 是否沒有被 robots.txt 或防火牆擋住？
• Lazy loading 的圖片與內容是否能被 Google 測試工具看到？
• 手機版與桌機版的重要內容是否一致？
• 結構化資料是否能通過 Rich Results Test？
• 網站是否因為 JavaScript 太重，影響 LCP、INP 或 CLS？

如果你只能先做一件事，我會建議先檢查「重要內容 Google 到底看不看得到」。

因為速度、設計、互動都很重要，但如果搜尋引擎根本看不到內容，後面很多 SEO 優化都會失去意義。

---

你也可以嘗試使用我們的秒站，設定好重要的 SEO 設定，幫助你輕鬆使用網站做好 SEO、GEO。

---

哪些網站最需要注意 JavaScript SEO？

以下網站特別需要注意：

• 使用 React、Vue、Angular 製作的 SPA 網站。
• 商品列表、價格、庫存靠 API 載入的電商網站。
• 文章內容或分類頁內容由 JavaScript 動態產生的內容網站。
• 使用 Headless CMS，加上 Next.js、Nuxt 或其他前端框架的網站。
• 改版後流量突然下滑，但內容本身沒有大改的網站。
• Google Search Console 顯示「已探索但尚未建立索引」或索引異常變多的網站。

如果你的網站只是一般 WordPress 文章站，且主題沒有大量前端框架，通常不用太緊張。

但如果你使用很多頁面產生器、互動外掛、前端載入區塊，仍然建議至少檢查重要頁面是否能被 Google 正確看到。

---

---

小結：JavaScript SEO 的重點不是怕 JavaScript，而是確認搜尋引擎看得到

JavaScript SEO 最重要的觀念是：不要只相信瀏覽器畫面。

你要確認的是，搜尋引擎是否能抓到網址、取得資源、執行必要的 JavaScript、看到主要內容、理解頁面訊號，最後把頁面正確放進索引。

新手不需要一開始就懂所有前端框架，也不用馬上研究很複雜的伺服器渲染架構。

你可以先從三件事開始：

• 檢查重要頁面原始 HTML 是否有主要內容。
• 用 Google Search Console 看 Google 渲染後是否看得到內容。
• 確認重要連結、status code、canonical、robots、structured data 沒有出錯。

如果這三件事都做對，JavaScript SEO 的基礎就已經比很多網站穩了。

後續再依照網站類型，決定要不要導入 SSR、SSG、改善 Core Web Vitals，或進一步做大型技術 SEO 檢查。

JavaScript 不是 SEO 的敵人，真正的敵人是：你以為搜尋引擎看得到，但它其實看不到。

---

JavaScript SEO 常見問題

React 網站 SEO 一定很差嗎？

不一定。

React 本身不是 SEO 問題，真正的問題是你的 React 網站怎麼渲染內容。

如果是純 CSR，又沒有處理 metadata、內部連結、HTTP status、structured data，那就容易出問題。

但如果使用 Next.js 這類框架，並正確處理 SSR、SSG、metadata 與 sitemap，React 網站也可以有不錯的 SEO 基礎。

Vue 網站可以做 SEO 嗎？

可以。

和 React 一樣，重點不是 Vue 本身，而是內容是否能被搜尋引擎看到。若使用 Nuxt 這類框架，通常會比純 SPA 更容易處理 SEO。

只要 Google 能 render JavaScript，就不用管 JavaScript SEO 嗎？

不是。

Google 能 render JavaScript，不代表每一次都能即時、完整、穩定處理你的網站。

更不用說其他搜尋引擎、社群平台爬蟲、AI 搜尋爬蟲，不一定都有同樣的 JavaScript 處理能力。

Lighthouse SEO 分數 100，就代表 SEO 沒問題嗎？

不代表。

Lighthouse 很適合做基本檢查，但它不能完全取代 Search Console、索引狀態、內容品質、關鍵字策略、內部連結與實際搜尋結果觀察。

它比較像健檢工具，不是排名保證書。

JavaScript SEO 會直接提升排名嗎？

通常不是這樣理解。

JavaScript SEO 比較像是排除技術障礙，讓搜尋引擎可以正確看到你的內容。當 Google 能更完整理解你的頁面後，你的內容才有機會參與排名競爭。

但排名仍然會受到內容品質、搜尋意圖、網站權威、內部連結、外部連結、使用者體驗等因素影響。

---

參考資料

• Google Search Central：Understand JavaScript SEO Basics
• Google Search Central：Fix search-related JavaScript problems
• Google Search Central：Dynamic Rendering as a workaround
• Google Search Central：Generate Structured Data with JavaScript
• Google Search Central：Fix lazy-loaded content
• web.dev：Rendering on the Web
• web.dev：Interaction to Next Paint is officially a Core Web Vital