JavaScript SEO：確保 Google 能索引您以 JS 呈現的頁面

索引分成兩波進行

Googlebot 會先擷取您的原始 HTML，並幾乎立即索引該初次回應中已經存在的任何內容。只有在 JavaScript 執行後才出現的內容，會被排入第二波 —— 也就是渲染 —— 這需要動用額外資源，比起初次爬取，延遲時間可能從幾秒到（在爬取資源有限的網站上）長得多不等。若您的內容或內部連結只在第二波之後才存在，等於是仰賴一條較慢、較不確定的路徑才能被索引。

真正會破壞索引的做法

• 主要內容或內部連結只在用戶端擷取後才渲染，初始 HTML 中沒有任何實質內容。
• 內容被鎖在需要使用者操作（點擊、捲動、滑鼠懸停）才會顯示，而 Googlebot 沒有理由執行這些操作。
• 頁面渲染所需的 JS 或 CSS 檔案被 robots.txt 封鎖；參閱robots.txt 與 noindex 的差異，了解封鎖可能如何適得其反。
• 前端路由從未實際改變 HTTP 狀態碼 —— 損壞的路由可能顯示空白或「找不到」訊息，卻仍傳回 200，這會被判定為soft 404。
• 只在無頭瀏覽器環境中才會發生的水合（hydration）或渲染錯誤，一般人工測試中不會被察覺。

如何檢查 Google 實際看到的內容

Search Console 的網址檢查工具有一個「已測試網頁」檢視畫面，會顯示 Google 渲染器執行後的實際 HTML 與截圖 —— 而不只是原始回應。將它與您的原始碼 HTML 進行比對：若關鍵內容或連結在原始回應中缺席、卻在渲染後才出現，代表您完全仰賴渲染佇列，而非速度較快的初次爬取。

真正有幫助的做法

• 對於攸關 SEO 的內容與導覽連結，採用伺服器端渲染（或靜態產生），而非於載入後才在用戶端擷取。
• 內部連結使用真正的 <a href> 元素，而非在非錨點元素上綁定點擊事件 —— Googlebot 會跟隨 href，而不會執行任意的 JavaScript 事件綁定。
• 不要封鎖頁面渲染所依賴的 JS／CSS 套件 —— Google 需要擷取它們才能完整渲染頁面。
• 頁面修正後，不要只是等待下一次渲染排程 —— 直接要求重新建立索引，或透過 IndexNow 推送該網址，讓修正後的版本能依您自己的時程被處理，而非渲染器的排程。