JavaScript SEO 深度技術指南，SSR、SSG、Hydration 對排名的影響與 Astro 站實戰

本文重點

• Googlebot 兩波索引會延遲 JS 渲染，產生長達數週的收錄時間差，直接拖垮時效性網頁排名。
• CSR 讓首波索引抓空；SSG 具備極致 TTFB 且最省預算，為目前 SEO 效益最高的策略。
• Hydration 阻塞主執行緒會拖垮 INP 分數，直接降低 Google 網頁體驗指標與排名。
• Astro 預設移除 JS，免除靜態內容 Hydration 負擔，極大化 SEO 渲染效能。

現代前端框架為開發者帶來極大的便利，但也讓 JavaScript SEO 成為技術端最具挑戰性的環節。本文將深入探討 Googlebot 的兩波索引機制，解析 SSR、SSG 等渲染策略與 Hydration 對 Core Web Vitals 的影響，並帶來基於 Astro 與 Cloudflare 的實戰驗證心得。

一、Google 如何處理 JavaScript 與兩波索引的真相

Google 處理 JavaScript 網頁需要經過爬取、渲染、索引三個階段，其中渲染階段因為極度消耗運算資源，會被放入專屬佇列延後處理，這就是技術 SEO 領域常說的兩波索引（two-wave indexing）。

（一）渲染佇列與 Web Rendering Service 的運作

當 Googlebot 首次抓取網頁時，只會提取初始的 HTML 原始碼進行第一波索引。如果頁面依賴 JavaScript 來生成核心內容或內部連結，這些元素在第一波索引中是完全隱形的。此時，Google 會將該 URL 推入渲染佇列（Render Queue），交由 Web Rendering Service (WRS) 處理。WRS 會在擁有足夠資源時，啟動無頭瀏覽器執行 JavaScript，獲取最終的 DOM 結構後才進行第二波索引。這兩波索引之間的時間差，短則數小時，長則可能達數週，對於時效性高的新聞站或電商網站是致命的延遲。詳見 Sitemap 實作與 GSC 提交 了解如何加速網址發現。

（二）2019 後 Googlebot 改用最新版 Chromium 但仍有資源限制

根據 Google: New evergreen Googlebot 2019，Googlebot 已經轉型為 Evergreen 模式，其底層的 Chromium 引擎會持續與最新版瀏覽器同步更新，這意味著它能完美支援 ES6+ 語法與多數現代 Web APIs。然而，這不代表開發者可以肆無忌憚地濫用客戶端腳本。Googlebot 依然受限於嚴格的 CPU 運算時間與抓取預算（Crawl Budget），如果你的 JavaScript 執行時間過長或需要發起過多外部 API 請求，WRS 會直接中斷渲染，導致頁面收錄不完整。

二、渲染策略對 JavaScript SEO 的影響與 CSR、SSR、SSG、ISR 全解析

網站的渲染策略直接決定了搜尋引擎爬蟲獲取內容的速度與完整度，選擇適合的渲染模式是 JavaScript SEO 的核心基礎。

（一）Client-Side Rendering 的 SEO 致命傷

純 CSR（Client-Side Rendering）架構下，伺服器只回傳一個包含 <div id="root"></div> 的空殼 HTML 與 JavaScript 檔案。這對 SEO 極度不友善，因為搜尋引擎在第一波索引時什麼內容都看不到，必須完全依賴 WRS 的第二波索引。此外，CSR 網站的 Meta Tags（如 Title、Description、Canonical）若由客戶端動態注入，在社群平台分享時往往無法正確抓取預覽圖文，嚴重影響外部連結的點擊率。

（二）Server-Side Rendering 的優點與動態渲染風險

採用 SSR（Server-Side Rendering）能在伺服器端預先將資料與組件渲染成完整的 HTML 再回傳給客戶端。根據 Next.js Rendering 文件，SSR 確保了爬蟲在首次請求時就能拿到完整內容，不僅解決了兩波索引的問題，SSR SEO 的表現也通常最為穩定。但 SSR 每次請求都要消耗伺服器運算資源並等待資料庫回應，如果後端 API 效能不佳，會導致 TTFB（Time to First Byte）過長，反而拖垮整體抓取效率。

（三）Static Site Generation 的 SEO 最佳實踐

SSG（Static Site Generation）在建置（Build）階段就將所有頁面預先編譯為靜態 HTML。這是目前已知對 SSG SEO 效益最高的做法，因為它兼具了 SSR 內容即時可見的優勢，同時擁有極致的 TTFB 表現。純靜態檔案可以直接部署在 CDN 邊緣節點上，對 Googlebot 來說抓取成本極低，能有效最大化抓取預算。

（四）Incremental Static Regeneration 的平衡點

對於擁有百萬級頁面的大型電商或內容平台，每次修改內容都要重新 Build 整個 SSG 網站是不切實際的。ISR 結合了 SSG 的速度與 SSR 的動態更新能力，允許網站在背景針對特定頁面進行重新生成。這確保了爬蟲始終能抓到最新的靜態 HTML，同時將伺服器負載降到最低，是目前大型 Next.js 專案最常採用的 SEO 平衡策略。

三、Hydration 對 SEO 與 Core Web Vitals 的雙重影響

Hydration（水合）是前端框架將靜態 HTML 轉換為具備互動性應用的過程，這個過程會大量佔用主執行緒，直接衝擊 Core Web Vitals 指標，進而間接影響 SEO 表現。

（一）Hydration 為什麼會對 INP 造成負面影響

當瀏覽器下載完由 SSR 或 SSG 生成的 HTML 後，頁面看起來已經載入完成，但實際上 JavaScript 還在背景進行 Hydration，綁定所有的事件監聽器。根據 web.dev INP 與 web.dev Core Web Vitals，如果 Hydration 過程耗時過長，會導致主執行緒阻塞（Long Tasks）。當使用者在此時點擊按鈕或展開選單，瀏覽器將無法立即回應，這會造成極差的 INP（Interaction to Next Paint）分數，進而影響 Google 演算法中的網頁體驗評分。hydration SEO 的關鍵就在於降低這段「恐怖谷（Uncanny Valley）」時間。

（二）Partial Hydration 與 Selective Hydration 及 Resumability 的差異

為了解決全域 Hydration 帶來的效能瓶頸，現代框架演化出多種解法。React 18 引入了 Selective Hydration，透過 Suspense 讓高優先級的組件（如使用者正在互動的區塊）優先水合；Qwik 則提出了 Resumability，徹底消滅 Hydration，直接從伺服器端序列化狀態並在客戶端精準喚醒。這些技術都能大幅降低 JavaScript 執行時間，對 SEO 的爬取與渲染效能有顯著提升。

（三）Astro 的 Island Architecture 為什麼對 SEO 特別友善

根據 Astro Islands 架構文件，Astro 預設會移除所有客戶端 JavaScript，將整個頁面視為純靜態 HTML。只有在開發者明確標記為互動區塊（如 <Carousel client:visible />）時，才會載入該區塊所需的腳本。這種 island architecture 確保了文章主體、導覽列等 SEO 核心內容完全不需要 Hydration，大幅減輕了主執行緒負擔，這也是為什麼 Astro SEO 在各項效能測試中經常名列前茅的原因。

四、seo.albertfnm.com 的 Astro 6 加 Cloudflare Workers Builds 實戰拆解

Albert’s SEO Note 採用 Astro 框架結合 Cloudflare 邊緣運算進行部署，透過高度靜態化與局部動態渲染，在各項指標與收錄表現上皆取得實質成果。

（一）為什麼選擇 Astro 作為 SEO 內容站框架

根據 Astro 官方文件，Astro 是一個專為內容驅動（Content-driven）網站設計的 Web 框架。對於 SEO 部落格而言，90% 的頁面元素（標題、內文、圖片）都是靜態的，不需要 React 或 Vue 沉重的 Runtime。Astro 允許我們以 Markdown/MDX 撰寫內容，並在建置時輸出極度乾淨的 HTML，這完全契合 SEO 三大支柱中強調的技術底層最佳化原則。

（二）prerender 加 island 在 Lighthouse 與 GSC 的實測表現

在實作上，我們大量使用了 prerender SEO 策略。針對所有文章頁面開啟預先渲染，並透過 client:idle 與 client:visible 精準控制互動組件的載入時機。在 Lighthouse 實測中，Mobile 效能輕鬆達到 98-100 分，INP 與 LCP 皆遠低於標準值。在 Google Search Console 中，新文章發布後通常能在數小時內完成第一波索引並取得正確排名，完全避開了 WRS 渲染延遲的問題。

（三）Cloudflare Workers Builds 與純靜態部署的 SEO 差異

傳統靜態託管（如 GitHub Pages）只能提供純 SSG 支援，而根據 Cloudflare Workers Builds，我們能在邊緣節點（Edge）執行伺服器端邏輯。這意味著我們可以在不犧牲 TTFB 的前提下，針對特定請求（如處理重新導向、動態注入地理位置相關的 Meta Tags）進行 Edge SSR，這為未來的進階 SEO 操作保留了極大的彈性。

五、JavaScript SEO 的 12 個技術自審項目

確保 JavaScript 網站能被正確索引，需要從 HTML 原始碼、連結結構到資源載入方式進行全面盤點，以下是進階技術 SEO 必備的檢查清單。

（一）關鍵內容是否在 HTML 中即時可見

在瀏覽器中對網頁點擊右鍵選擇「檢視網頁原始碼」（而非「檢查」），確認文章標題、主文、重要圖片與結構化資料是否直接存在於原始碼中。如果原始碼中找不到這些內容，代表爬蟲在第一波索引時也看不到。

（二）內部連結是否使用 anchor 元素而非 onClick

根據 Google JavaScript SEO Basics，Googlebot 只能抓取帶有 href 屬性的 <a> 標籤。如果你的網站導覽列或分頁按鈕是使用 <div onClick="navigate()"> 或 <button> 實作，爬蟲將無法跟隨這些連結，這會嚴重破壞網站的爬取深度與權重傳遞。詳見 內部連結與主題集群 了解內部連結佈局。

（三）Lazy-loaded 內容是否能被爬蟲渲染

延遲載入（Lazy Loading）能提升效能，但如果實作不當會導致圖片或內容不被索引。必須確保使用的是原生 loading="lazy" 屬性，或是在使用 IntersectionObserver 時，確保爬蟲的 Viewport 夠大或能正確觸發載入機制。

（四）剩餘 9 個自審項目一次盤點

除了上述三點，完整的 JavaScript SEO 檢查還應包含：

1. robots.txt 是否意外封鎖了重要的 .js 或 API 路徑。
2. 網址是否使用 Clean URL（避免使用 # Hash Routing）。
3. 錯誤頁面（404）是否回傳了正確的 HTTP 狀態碼，而非僅在客戶端渲染 404 畫面但回傳 200。
4. Canonical Tag 是否在伺服器端就已正確設定，避免 JS 注入導致衝突。
5. <title> 與 <meta description> 是否在初始 HTML 中就存在。
6. 分頁（Pagination）是否具有實體 URL（如 ?page=2）。
7. 無限捲動（Infinite Scroll）是否支援 History API 推送實體網址。
8. 結構化資料（Schema.org JSON-LD）是否在 DOM 載入時即時可用。
9. 網站是否能在關閉 JavaScript 的情況下維持基本瀏覽功能。

六、JavaScript SEO 的偵錯與驗證工具

驗證 JavaScript SEO 最準確的方式，是直接使用 Google 提供的官方工具來模擬 Googlebot 的渲染視角。

（一）從 Google Search Console 網址檢查工具查看已渲染 HTML

GSC 的「網址檢查（URL Inspection）」是唯一能真實反映 Googlebot 視角的工具。輸入網址並點擊「測試即時網址」後，點擊「查看測試的網頁」，切換到「HTML」頁籤，這裡顯示的 DOM 樹就是 WRS 執行 JavaScript 後最終拿到的內容。這是抓漏 CSR 渲染失敗的最強利器。

（二）利用 Mobile-Friendly Test 與 Rich Results Test 檢視渲染快照

雖然 Mobile-Friendly Test 已退役，但其核心渲染引擎已整合至 Rich Results Test（複合式搜尋結果測試）。除了檢查結構化資料，你可以透過該工具的「查看網頁」功能，檢視 Googlebot 渲染網頁後的螢幕快照（Screenshot）與 JavaScript 錯誤日誌。如果快照出現大片空白或載入中的 Spinner，代表你的渲染超時了。

（三）使用 Chrome DevTools 關閉 JavaScript 進行模擬

在 Chrome 開發者工具中按下 Cmd+Shift+P，輸入 Disable JavaScript 並重新整理網頁。這是最快速的本地端除錯方式，能讓你瞬間看出網站在第一波索引時的真實模樣。如果關閉 JS 後網站變為一片空白，你就必須重新評估渲染策略。

七、FAQ

（一）Q1: Googlebot 執行 JavaScript 的超時限制是多久？

Google 從未公開確切的超時秒數，但業界測試與普遍共識大約落在 5 秒左右。如果你的頁面依賴的 API 回應過慢，或者 JavaScript 執行時間超過這個閾值，WRS 就會直接截斷渲染，將當下的半成品 DOM 存入索引。

（二）Q2: 如果我的網站完全依賴 CSR，還能做 SEO 嗎？

可以，但極度不建議。CSR 網站必須依賴兩波索引，這會導致新內容被收錄的時間大幅延遲。此外，高度依賴客戶端運算會增加爬蟲的抓取成本，對於頁面數量龐大的網站而言，會嚴重浪費抓取預算。

（三）Q3: Googlebot 會點擊按鈕來觸發 JavaScript 嗎？

不會。Googlebot 不會執行任何使用者互動行為，例如滾動滑鼠、點擊按鈕、展開手風琴選單（Accordion）或填寫表單。所有需要互動才能載入的內容，對 Googlebot 來說都是不存在的。

（四）Q4: 什麼是動態渲染（Dynamic Rendering）？Google 還推薦嗎？

動態渲染是指伺服器透過 User-Agent 判斷請求來源，如果是普通使用者則派發 CSR 應用，如果是搜尋引擎爬蟲則派發透過 Puppeteer 等工具預先渲染好的靜態 HTML。Google 目前已將動態渲染降級為「臨時性的權宜之計（Workaround）」，並強烈建議開發者轉向 SSR、SSG 或 ISR 等更現代的架構。