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

JavaScript SEO：確認 Google 真的看得到你以為它看得到的內容

JavaScript SEO 處理的是同一個問題：搜尋引擎拿到的頁面，到底跟你打開瀏覽器看到的差多少。Google 現在用 evergreen Chromium 執行 JavaScript，React、Vue、Angular 的內容確實有機會被渲染後看到，但「有機會看到」不等於「穩定可索引」。真正會讓你掉流量的，是那些瀏覽器看得到、Googlebot 卻拿到空殼的頁面。Google 官方在 JavaScript SEO 基礎文件裡把流程拆成 Crawling、Rendering、Indexing 三階段 [來源：Google Search Central，瞭解 JavaScript SEO 基礎知識]，只要中間任何一環因為 JS 檔被擋、API 失敗、狀態碼錯誤而中斷，再漂亮的內容都不會被索引。

把這件事放在實際流量版圖裡看會更有感。研究顯示約 96.55% 的頁面從 Google 拿不到任何自然流量 [來源：〈Ahrefs — 96.55% of Content Gets No Traffic From Google〉〈https://ahrefs.com/blog/search-traffic-study/〉〈2023-12-01〉]。如果你的網站內容本來就被 JavaScript 擋在 Googlebot 之外，等於連進入這場競爭的門票都沒拿到，連要不要爭排名都談不上。JavaScript SEO 的價值，就是先把這張門票穩穩拿到手，後續的內容、關鍵字、外部連結經營才有意義。

重點先看：Google 能 render JavaScript 不代表每次穩定看得到；據 Google 官方說明，若原始 HTML 出現 noindex，可能就不會繼續渲染 [來源：Google Search Central，Fix search-related JavaScript problems]。真正該問的問題是「你驗證過搜尋引擎實際拿到什麼了嗎」。

JavaScript SEO 與一般 SEO 的根本差異：內容是否存在於 Googlebot 拿到的 HTML

JavaScript SEO 處理的是一個普通 SEO 預設不存在的問題：內容到底有沒有被搜尋引擎看到。一般 SEO 假設 HTML 裡本來就有內容，所以你只要管標題、連結、關鍵字；JavaScript SEO 卻連「內容存在不存在於 Googlebot 拿到的 HTML」都要重新驗證。當你的商品價格、文章正文、分類列表、結構化資料全都靠 JavaScript 才出現，等於把 SEO 的地基架在一個不一定執行成功的流程上。

這件事適用的情境很具體：網站是 React、Vue、Angular、Next.js、Nuxt 構建的，或是商品、價格、文章正文靠 API 動態載入。用 vibe coding 快速產出的網站風險更高，因為它常常預設純前端渲染，沒有人回頭檢查 SEO。常見的狀況是，畫面很漂亮、互動很順的網站，一打開原始碼只剩一個空的 <div id="app">，標題、內文、連結全要等 JS 跑完才出現。

要先搞懂 Google 處理 JS 網頁的三階段，這也是 JavaScript SEO 所有判斷的基礎。Google 在官方文件裡講得很清楚：搜尋引擎運作對 JS 網頁會走 Crawling（抓 HTML、CSS、JS 等資源）→ Rendering（用 evergreen Chromium 執行 JS，產生渲染後的頁面）→ Indexing（依可取得內容決定是否索引）這條路 [來源：〈Google Search Central，瞭解 JavaScript SEO 基礎知識〉〈https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics〉〈2024〉]。最典型的破綻，就是 Googlebot 抓到的 HTML 只有一個空 div，其他內容全要等 JS 執行。

JavaScript SEO 跟一般 SEO 的差別可以濃縮成一句話：一般 SEO 在「內容已存在」的前提下做優化，JavaScript SEO 連這個前提都要自己驗證。如果你曾經疑惑為什麼改版後內容變更多、流量卻反而下滑，第一個該懷疑的就是這件事，這也是網站搬家改版最容易踩的雷。

能 render 不等於穩定看得到：Google 處理 JavaScript 的真實邊界

多數情況下 Google 確實能看懂 JavaScript，但「能 render」跟「每次都穩定看得到」是兩件事。Google Search 現在用 evergreen Chromium 執行 JS，所以 React、Vue、Angular 渲染出來的內容有機會被看到。重點在「有機會」這三個字：渲染排在抓取之後，會進佇列，只要資源被擋、API 失敗、程式報錯、或內容要互動才載入，渲染流程就會中斷，Google 仍可能拿到不完整的內容。

為什麼說「穩定」才是關鍵？因為渲染不是即時的。Googlebot 先抓原始 HTML，把需要渲染的網址丟進一個佇列，之後才回頭執行 JS。這段時間差裡，任何不穩定的前端流程都會讓內容消失。如果你的 JS 檔被 robots.txt 擋住、商品資料 API 回應太慢或失敗、伺服器回傳錯誤狀態碼，渲染那一刻 Google 就拿不到完整頁面。這跟「Google 會不會 render JS」無關，而是「你給它的資源穩不穩定」的問題，過程中也會吃掉你有限的爬取預算。

渲染佇列還會帶來第二層成本：延遲收錄。一個高度依賴 JS 的網址，從被 Googlebot 抓取、進入渲染佇列、到實際執行渲染並完成索引，可能比純 HTML 頁面晚好幾天甚至好幾週。對新聞、時效性促銷、季節性商品這類「晚收錄就沒流量」的頁面，這個延遲等於直接吃掉最精華的曝光期。對流量大的站，渲染佇列也會把爬取預算消耗在「反覆抓取但拿不到完整內容」的網址上，連帶壓縮其他頁面的收錄機會。

只盯著 Google 其實會漏掉一大半可見度。除了 Google，Bing、社群平台爬蟲、AI 搜尋爬蟲的 JavaScript 處理能力通常更弱。你在社群分享連結時預覽圖抓不到、AI 搜尋引述不到你的內容，很多時候根源就是 JS 渲染依賴。所以「只看 Google」這個判斷標準本身就有偏差。想知道 Google 到底有沒有收錄你的頁面，可以對照Google 網頁收錄查詢的方法。

社群平台爬蟲跟 AI 模型大多不執行 JavaScript，或只執行極有限的腳本。當你在 LINE、Facebook、Threads 分享一個商品頁，平台抓的是原始 HTML 裡的 Open Graph 標籤與預覽圖。如果這些資訊由 JavaScript 動態產生，分享卡片就會出現沒有圖、沒有標題、或顯示空白網址的窘境。同樣的道理，當 AI 搜尋引擎嘗試理解你的內容、決定要不要在你的頁面被引用時，它抓到的若只有空殼，等於自動退出 AI 答案的競爭。把內容放進原始 HTML，等於一次同時照顧 Google、社群爬蟲、AI 模型三種讀者。

Google 官方還給了一個很具體的提醒：如果在原始 HTML 看到 noindex，Google 可能就不會繼續渲染那個頁面 [來源：〈Google Search Central，Fix search-related JavaScript problems〉〈https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript〉〈2024〉]。這代表你不能指望用 JavaScript 在渲染後把 noindex 拿掉。想知道 noindex 跟 robots.txt 為什麼不能並用、或noindex 本身的運作方式，這條線索很值得延伸。

JavaScript SEO 最常踩的 5 個錯誤

會讓 Google 看不到內容的 JavaScript 寫法，最常見的就這五種，而且每一種都會在你以為沒事的時候默默吃掉流量。先把五個錯誤的成因跟影響列在表格裡，後面再各自展開。要回頭檢查反向連結或外部資源是否連得上，熟悉Ahrefs 完整教學會派上用場。

錯誤類型	成因	對 SEO 的影響
使用者看得到、Google 看不到	正文、價格、商品列表全靠 JS 後載入	Googlebot 拿到空殼，內容進不了索引
連結做成 button/onclick	缺標準 <a href>	搜尋引擎難發現新頁面，爬取預算浪費
SPA 全部回傳 200	不存在頁面也回 200	形成 soft 404，Google 難判斷有效性
用 JS 動態改 title/canonical	原始 HTML 與渲染後訊號不一致	訊號衝突，noindex 尤其危險
Lazy Loading 讓內容消失	內容要滑動或點擊才載入	搜尋引擎看不到完整內容

錯誤一：使用者看得到，Google 看不到

這是最典型的破綻。網站在瀏覽器裡看起來完全正常，但測試工具拿到的 HTML 卻不完整。常見原因包括 JavaScript 報錯、API 被擋、內容延遲載入，或重要區塊要使用者互動後才出現。文章頁的正文、商品頁的價格、分類頁的商品列表，只要這些是 JavaScript 後載入，就要逐一確認渲染後 Google 真的看得到。

實務上排查這個錯誤有幾個切入點。先把疑問頁丟進 Google Search Console 的網址檢查，點開「測試實際網址」，看「HTML 回傳內容」是不是包含你要排名的關鍵段落。如果原始碼有、渲染後沒有，通常是 JavaScript 報錯導致元件沒掛載；如果原始碼沒有、渲染後才有，就是典型 JS 後載入，要評估內容對 SEO 的重要性再決定要不要改成伺服器產生。第三種較隱晦的狀況是內容在元件掛載後又被打掉（例如登入狀態檢查、A/B 測試腳本誤判），這時連瀏覽器有時都會閃過再消失，需要用無痕模式搭配網路節流重現。

錯誤二：重要連結不是標準 HTML 連結

搜尋引擎主要透過連結發現新頁面。如果你把商品卡片、文章卡片、分類連結做成 button 或 onclick，沒有標準的 <a href>，Google 比較難循線找到這些頁面。比較保險的做法是：重要頁面之間的內部連結盡量用標準 HTML 連結，這也牽動網站架構與站內站外連結整體設計。

判定一條連結算不算「搜尋引擎看得到」，有一個簡單的二分法：在原始 HTML 裡能不能找到 <a href="/某路徑">。如果只在 JavaScript 事件裡用 router.push 或 window.location 跳轉，對 Googlebot 來說等於沒有這條連結。即使是前端框架，也可以把可點元素包一層 <a>，或用 Link 元件（Next.js、Nuxt 都提供）讓它輸出成標準錨點。分頁、篩選器、載入更多這類操作尤其容易踩雷，建議改成有獨立網址、可被連結的形式。

錯誤三：SPA 頁面全部回傳 200

很多 Single Page Application 會把所有網址都導到同一個前端入口。沒處理好就會出現一個尷尬狀況：網址明明不存在、畫面也顯示「找不到頁面」，HTTP 狀態碼卻還是回傳 200。對搜尋引擎來說，這就形成 soft 404，讓 Google 難判斷這個頁面到底是不是有效內容。不存在的頁面該回 404 或 410，轉址該回 301 或 302，網址結構也要一起想清楚。

SPA 架構裡要正確回傳狀態碼，前端路由必須跟伺服器配合。常見做法是在伺服器層維護一份有效路由清單，命中才回 200 並回傳對應內容，未命中直接回 404 的 HTML（同樣是伺服器產生，而非前端事後才改成「找不到」）。轉址也要在伺服器或邊緣層發出 301／302，而不是靠前端在載入後才 redirect，因為那時 HTTP 狀態碼早就已經是 200 送出去了。如果把 soft 404 放著不管，Google 會慢慢降低對整個網域「網址可信度」的評價，影響的是全站而非單頁。

錯誤四：用 JavaScript 改 title、canonical、robots

Google 可以處理部分 JavaScript 產生的 metadata，但不代表這是最穩的做法。如果原始 HTML 有一組 title、canonical，JS 執行後又改成另一組，就會造成訊號衝突。noindex 特別危險：Google 在原始 HTML 看到 noindex 可能就停止渲染 [來源：Google Search Central，Fix search-related JavaScript problems]。這部分可以對照重複內容的處理原則。

一個常見的出錯模式是開發用 noindex 擋測試環境，正式上線時改成用 JS 在渲染後移除 noindex，卻忽略 Google 在原始 HTML 階段就讀到 noindex 而停止渲染。另一個模式是 canonical 在前端依據查詢參數動態切換，結果原始 HTML 的 canonical 跟渲染後的不一致，Google 收到兩個訊號只能猜，猜錯就把正規網址當成重複頁面。穩當的做法是把 title、canonical、robots、hreflang 這些「索引方向訊號」直接由伺服器寫進 HTML，JavaScript 只負責純展示層的變化。

錯誤五：Lazy Loading 讓內容消失

Lazy loading 本身沒問題，它能改善網站速度與使用者體驗。但如果文章內容、商品列表、評論、圖片或 FAQ 要等使用者滑動、點擊或觸發某個行為才載入，搜尋引擎不一定看得到完整內容。Google 有專門的 lazy loading 指南，建議確保延遲載入的內容仍可被抓取與索引 [來源：Google Search Central，Fix lazy-loaded content]。想顧到延遲載入與效能的平衡，可以看Lazy Loading 延遲載入的實戰做法；圖片還要處理到社群分享時的預覽，這部分延伸到圖片 SEO 優化的整體設定。

要讓延遲載入的內容對搜尋引擎也看得到，關鍵是把「分頁」做成可被連結的獨立網址。商品列表第 2 頁、第 3 頁最好各自有自己的網址（例如 ?page=2 或乾脆用 path），並在前一頁用標準 <a href> 連過去，這樣 Googlebot 即使不滑動也能循線抓到。圖片延遲載入則建議用瀏覽器原生的 loading="lazy"，它對搜尋引擎友善，且不會像舊式 Intersection Observer 寫法那樣在渲染時漏抓。評論、FAQ 這類補充內容如果對長尾關鍵字有幫助，寧可直接放進 HTML，別依賴互動觸發。

CSR、SSR、SSG 哪一種最適合 SEO？一張表看完怎麼選

渲染方式本身不決定 SEO 好壞，真正決定的是「哪些頁面真的需要被 Google 索引」。需要被索引的內容頁與商品頁，優先 SSR 或 SSG；登入後台這種根本不該被索引的，用 CSR 就好。把資源花在會被搜尋的頁面上才划算，這個判斷比「選哪個最潮的框架」重要太多。

渲染方式	內容產生時機	SEO 風險	適合頁型
CSR（Client-Side Rendering）	瀏覽器下載 JS 後由前端產生	高，內容要等 JS 執行	後台系統、高互動 Web App
SSR（Server-Side Rendering）	伺服器先產生完整 HTML 再送出	低，Googlebot 一拿到就有主要內容	文章、商品、分類、Landing Page
SSG（Static Site Generation）	建置時就產生靜態 HTML	最低，速度快且風險低	部落格、文件、教學、公司介紹

展開來看三者各自的特性。CSR 是 React SPA、Vue SPA 常見的做法，互動性高、前端開發彈性大，但搜尋引擎必須等 JavaScript 執行成功才可能看到完整內容，SEO 風險最高。SSR 是伺服器先產生完整 HTML 再送出，Googlebot 一開始就拿得到主要內容、標題、連結，文章頁、商品頁、分類頁、品牌頁、Landing Page 都適合。SSG 則是在建置時就產生靜態 HTML，速度最快、SEO 風險最低，適合部落格、文件、教學、公司介紹；唯一缺點是內容頻繁更新時要搭配重新建置、快取或 ISR，這時可以靠快取設定控制更新節奏，再用Sitemap 產生與提交確保 Google 拿得到最新網址清單。

這些定義直接對照 web.dev 的《Rendering on the Web》[來源：web.dev，Rendering on the Web]。沒有「最高級」的技術，只有「最適合這個頁面」的技術：先判斷頁型再決定渲染策略，比一開始就糾結要 Next.js 還是 Nuxt 更實際，這個選擇也會牽動XML Sitemap的產生方式與網域與網址規劃。

Dynamic Rendering 已經被 Google 列為過渡方案

以前很紅的 Dynamic Rendering 不值得再當主力方案。它的原理是：一般使用者看到前端渲染頁，搜尋引擎爬蟲看到預先渲染好的 HTML，曾是解 SPA SEO 的主流解法。但 Google 官方現在把它定位為「臨時性 workaround」而非推薦的長期解法，更建議改用 server-side rendering、static rendering 或 hydration [來源：Google Search Central，Dynamic Rendering as a workaround]。

原因有三個。第一，Dynamic Rendering 會增加系統複雜度與維護成本，等於要多維護一套預渲染流程。第二，一旦搜尋引擎與使用者看到不同內容，就可能踩到 cloaking 風險，這在黑帽 SEO與白帽之間是條很模糊的線。第三，兩套內容長期難同步，維護一久很容易出現爬蟲版本跟使用者版本對不上的狀況。

過渡期怎麼辦？如果短期內真的無法改 SSR，Dynamic Rendering 可以當權宜之計，但請同時排定遷移計畫，不要把它當永久架構。把力氣放在把公開頁改成 SSR 或 SSG，比維持兩套內容更划算。這也跟年度內容更新時重新檢視技術債的方向一致。

不是工程師也能上手：JavaScript SEO 五步檢查流程

不會寫程式，也能確認 Google 真的看得到你的內容。五個步驟走完一遍，其中第三步是最關鍵的黃金標準，比只看瀏覽器畫面可靠得多。整個流程的核心觀念只有一個：不要相信瀏覽器畫面，要用工具驗證搜尋引擎實際拿到什麼。這套檢查思路屬於技術性 SEO 完全指南的一環。

步驟一：先挑代表頁面

不要一開始就檢查整站，那只會讓你失去焦點。先按頁型各挑 1 到 3 個代表網址：首頁、文章頁、分類頁、商品頁、活動頁、404 頁面。聚焦在高價值頁面，才能快速看出問題。如果你不知道哪些頁面價值高，可以從獲得自然流量的公式反推。

步驟二：檢視網頁原始碼

在網頁上按右鍵，選「檢視網頁原始碼」。你要看的是：標題、內文、連結、canonical、robots meta、結構化資料，是不是一開始就在 HTML 裡。如果只看到一堆 JavaScript 檔案、內容幾乎沒有，就代表這頁高度依賴 JavaScript。想用更快的方式，可以學一下用 F12 開發者工具看原始碼。

一個快速判讀技巧：在原始碼頁面用 Ctrl+F 搜尋你這頁最關鍵的那段文字（例如商品名稱、文章第一段）。找得到代表內容已在 HTML 裡，搜尋引擎有機會直接看到；找不到就要進入下一步用 Search Console 確認渲染後是否存在。注意要搜的是「檢視網頁原始碼」這份檔案，而不是 F12 的 Elements 面板，因為後者顯示的是 JavaScript 執行後的 DOM，會誤判成「內容都在」。

步驟三：用 Google Search Console 網址檢查

這一步是判斷可見度的黃金標準。用 Google Search Console 的網址檢查工具，看 Google 是否能抓取、渲染、索引這個頁面。它會直接告訴你渲染後的內容長怎樣、有沒有被擋、索引狀態如何。如果你還沒裝，先照安裝教學把 GSC 跑起來，再熟悉Search Console 常用功能。

網址檢查結果裡有幾個欄位要特別看。「網址位於 Google 上嗎」告訴你目前收錄狀態；「檢索」回報 Googlebot 實際拿到的內容、發現的連結數、回傳的狀態碼；「網頁索引」會列出 noindex、重複、爬蟲異常等阻擋原因。如果頁面卡在「已檢索但未建立索引」，常見原因就是渲染後內容太薄或被判為重複，這時要回頭檢查 JS 是否完整產出主要內容，而不是再去改 title 或塞關鍵字。

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

頁面如果有 FAQ、Article、Product、Recipe、Review 等結構化資料，用 Rich Results Test 檢查能不能正確解析。Google 可以理解渲染後 DOM 裡的 JavaScript structured data，但商品頁要特別小心 [來源：Google Search Central，Generate structured data with JavaScript]。商品價格、庫存這類快速變動的資訊如果全靠 JS 動態產生，會讓 Shopping 相關抓取變得不穩定。若要一次把標記寫對，可以參考結構化資料 Schema 標記教學。

步驟五：檢查 Core Web Vitals 與 INP

JavaScript 太重會拖垮互動體驗。現在 Core Web Vitals 裡的互動指標是 INP，已正式取代 FID [來源：web.dev，INP became a Core Web Vital]。INP 衡量使用者互動後頁面多久能有下一次畫面反應。塞太多 JS、第三方追蹤碼、動畫或大型套件，都會讓 INP 變差。這部分可以搭配CWV 介紹與網站速度優化全攻略一起看。

Core Web Vitals 不只是技術分數，還會直接反映在轉換與營收上，這也是為什麼 JS 拖垮互動體驗的代價比想像中大。第三方案例顯示，redBus 改善網站的 INP（Interaction to Next Paint）後，銷售增加了 7%；而 Vodafone 在 LCP 改善 31% 後，銷售提升了 8% [來源：web.dev（Google），Why does speed matter? https://web.dev/articles/why-speed-matters 2026]。換句話說，前端 JS 套件把 INP 或 LCP 拖慢，流失的不只是分數，而是實際的訂單與收入，這對 JavaScript 依賴度高的電商與內容站尤其值得警惕。

另一個值得一起看的案例是 Rakuten 24。該站投入改善 Core Web Vitals 後，每位訪客的營收提升了 53.37%，轉換率提升 33.13%；印度經濟日報（The Economic Times）在通過 Core Web Vitals 門檻後，整體跳出率改善了 43% [來源：web.dev（Google），Why does speed matter? https://web.dev/articles/why-speed-matters 2026]。這些數字背後的共同點是：JavaScript 的執行與載入效率直接決定了使用者能不能順利完成任務。對 JS 依賴度高的站，把 JS 切分、延後載入非必要腳本、減少第三方追蹤碼，往往比再寫一篇新內容更能拉動營收。

最該盯緊 JavaScript SEO 的六種網站

你的網站屬於高風險族群嗎？有六種網站最該盯緊 JavaScript SEO，如果你的站同時符合其中兩項以上，建議優先排時間檢查。判斷標準很簡單：內容有多依賴前端流程、流量有沒有出現不明下滑的訊號。

• 純 SPA：用 React、Vue、Angular 製作，內容全靠 JS 渲染。
• API 驅動電商：商品列表、價格、庫存靠 API 載入，抓取失敗等於商品頁空殼。
• JS 動態內容站：文章或分類頁內容由 JavaScript 動態產生。
• Headless CMS 加前端框架：前後端分離放大了 JS 依賴。
• 改版後流量無預警下滑：內容沒大改，流量卻掉，優先懷疑 JS 可見度。
• GSC 顯示「已探索但尚未建立索引」爆量，或索引異常變多。

「已探索但尚未建立索引」這個訊號特別值得注意。它代表 Google 抓到了網址卻沒索引，原因可能就是渲染後沒看到值得索引的內容。可以對照網頁被 Google 索引的確認方法跟索引之後的檢索環節釐清整條鏈路。如果你才剛起步，沒有網站如何開始做 SEO跟SEO 自學懶人包會比直接碰 JS SEO 更有用。

也有低風險的例外。一般 WordPress 文章站，如果主題沒有用大量前端框架，通常不用太緊張。但如果你裝了一堆頁面產生器、互動外掛、前端載入區塊，就等於在原本穩定的 HTML 上疊 JS 依賴，仍然建議至少檢查重要頁面。這類風險可以從挑對WordPress SEO 外掛開始降低；平台選擇本身也會影響這件事，可以參考部落格平台租屋風險的提醒。

渲染策略決策矩陣：依頁面類型與內容更新頻率選擇

前面把 CSR、SSR、SSG 拆開講，但實際專案裡，同一個網站常混合好幾種渲染方式。為了把「哪種頁面該用哪種渲染」這個決策講清楚，這裡用一個二維矩陣來表達。橫軸是內容更新頻率（低、中、高），縱軸是該頁面是否需要被索引（公開需索引、非公開不需索引）。把頁面丟進對應的格子，就能直接讀出建議的渲染策略。

頁面屬性	更新頻率低（文件、公司介紹）	更新頻率中（部落格、活動頁）	更新頻率高（商品、價格、庫存）
公開、需被索引	SSG，建置時產生靜態檔	SSG 加 ISR，或 SSR 帶快取	SSR，搭配邊緣快取與 revalidate
非公開、不需索引	CSR，純前端渲染	CSR，純前端渲染	CSR，純前端渲染

矩陣的用意在於避免一種常見錯誤：用同一種渲染策略套用全站。把後台、個人化儀表板也改成 SSR，會浪費伺服器資源、還可能把不該曝光的資料送進搜尋引擎；相對地，把高頻更新的商品頁做成純 CSR，會讓 Google 拿到空殼、價格與庫存進不了索引。正確的做法是依頁面屬性分區處理，公開頁面集中投資 SSR 或 SSG，後台頁維持 CSR 並加上 noindex 或登入牆。這個分區觀念，跟網站架構規劃時區分「賺錢頁」「支援頁」「後台頁」是同一件事。

JavaScript SEO 進階診斷：當基本檢查抓不到問題

五步檢查流程能解決多數可見度問題，但有些狀況連 Search Console 都顯示「正常」，流量卻還是異常。這時要進入更底層的診斷，檢查的不只是「Google 看得到嗎」，而是「Google 多久才看到、看到時資料是不是最新的」。進階診斷常用的有三條線索：檢查資源可被檢索、檢查渲染行為、檢查快取與時效。

資源層：JS、CSS、API 是不是真的可被檢索

robots.txt 常被誤用來擋整個 /assets/ 或 /static/ 路徑，連帶把渲染需要的 JS 檔也擋掉。Google 一旦拿不到關鍵 JS 檔，等於沒辦法執行渲染，頁面就停留在空殼狀態。檢查方式是用 Search Console 的網址檢查看「檢索」分頁的資源清單，標示為「無法載入」的腳本就是嫌疑犯。另一個常見問題是 JS 檔放在第三方 CDN，而該 CDN 的網域被防火牆或 robots 封鎖，這時要把 CDN 網域加入允許清單。API 也是同樣的道理：商品資料 API 如果回傳 5xx 或被 rate limit，渲染就拿不到內容，需要確認 API 對 Googlebot 的 IP 段穩定可達。

以這類 API 驅動的電商站為例，常見的狀況是商品列表、價格、庫存全部由前端呼叫 API 載入，原始 HTML 只剩空殼。依這類站的典型表現幅度，商品頁從被 Googlebot 抓取到完成渲染索引，往往比純靜態頁延遲約 3 到 14 天，期間促銷期或季節性商品的精華曝光期可能已過。另一種同樣典型的破綻，是開發為了擋測試環境或舊資源，在 robots.txt 寫了 Disallow: /assets/，結果連同正式站渲染所需的 JS bundle 一起封鎖，Google 在「檢索」分頁看到大量「無法載入」的腳本，商品頁長期停留在「已檢索但未建立索引」。實務上常見的限制是：這類問題在 Search Console 的測試性渲染裡不一定重現，因為測試用的是受控環境、API 也較少逾時，等到正式索引時才間歇性漏抓。決策角度上，與其逐一修補每個 API 逾時，更划算的做法是把會被搜尋的公開頁（商品、分類、Landing Page）集中改成 SSR 或 SSG，把價格、庫存這類快速變動欄位的 revalidate 設短，並確認 robots.txt 只擋真正不該被索引的路徑，而不是整個 assets 目錄。

渲染層：用 Google 的 Rendering API 看真實結果

Search Console 的網址檢查顯示的是「測試性渲染」，跟 Google 真正建立索引時用的渲染結果可能有些微落差。要更貼近真實狀況，可以另外用 Rich Results Test 或 Google 的 Mobile-Friendly Test，它們底層用的也是 Chromium 渲染，但呈現方式不同，能交叉比對。對於關鍵頁面，進階做法是在本地用 headless Chromium（例如 Puppeteer）模擬 Googlebot 行為，擷取渲染後的 HTML，確認你要排名的段落確實存在。這個動作能抓到「測試工具看得到、但實際索引時漏掉」的間歇性問題，例如 API 偶爾逾時。

時效層：快取、revalidate 與內容新鮮度

SSR 搭配快取時，要留意快取時間與內容新鮮度的平衡。商品價格、庫存如果被快取太久，Google 拿到的可能是過期版本，影響結構化資料與 Shopping 收錄。設定 revalidate 時，建議把會影響搜尋結果的欄位（價格、庫存、標題）設成較短的有效期，純展示用的內容（描述、評論）可以拉長。監控時可以用 Search Console 的「檢索統計資料」，觀察 Googlebot 對各路徑的抓取頻率，頻率異常下降通常代表內容被判為低更新需求，或反過來說，該路徑的快取策略讓 Google 覺得「不需要常來」，這對時效性頁面是警訊。

把三層串成一份排查順序，會比逐項背誦更實用：先在網址檢查的「檢索」分頁圈出無法載入的 JS、CSS，回頭確認 robots.txt 沒有誤擋渲染所需路徑、商品 API 對 Googlebot IP 段穩定可達；接著用 Rich Results Test 與網址檢查交叉比對渲染結果，關鍵頁面再用 headless Chromium 在本地複現渲染後 HTML；最後核對 SSR 快取時間與價格、庫存這類時效欄位的有效期是否一致。

把這三層檢查做完，等於把「Google 拿到什麼」拆解成「資源給了嗎、渲染執行了嗎、結果新鮮嗎」三個可驗證的問題。任何一層出問題，都會讓前面辛苦寫的內容失去被排名的資格。而當內容可見度穩定之後，連帶會影響外部連結的累積速度。研究顯示，排名第一的頁面每個月會從新的 referring domain 獲得約 5% 到 14.5% 的已跟隨反向連結 [來源：〈Ahrefs — 107 SEO Statistics for 2026〉〈https://ahrefs.com/blog/seo-statistics/〉〈2026〉]。也就是說，可見度穩了，外部權重才會開始正向累積，形成排名往上爬的良性循環。

JavaScript SEO 常見問題與新手檢查清單

常見的一個誤解是：React 或 Vue 是不是天生 SEO 就比較差？Lighthouse 拿到 100 分是不是就沒事？答案都不一定。React 或 Vue 本身不是問題，真正問題是內容怎麼被渲染。用 Next.js 或 Nuxt 正確處理 SSR、SSG、metadata、sitemap，框架站也能有不錯的 SEO 基礎，這跟搜尋意圖、E-E-A-T、Entity SEO 這些內容層策略是並行的。如果你的內容落在健康、財務這類主題，還會進一步受到YMYL 排名規則與品質評估的約束。想把這些策略接上 AI 搜尋，可以參考AI SEO 實戰心法。

Lighthouse 很適合做基本檢查，但它不能取代 Search Console、索引狀態、內容品質、關鍵字策略與實際搜尋結果觀察。它比較像健檢工具，不是排名保證書。JavaScript SEO 也不會直接提升排名，它是排除技術障礙，讓 Google 能完整理解頁面後，內容才有機會競爭排名。背後的邏輯可以對照資訊增益、SERP 元素、Title Tag 寫法。

這份 11 項新手檢查清單，你可以直接照著跑一遍。這比記一堆理論有用，因為 JavaScript SEO 最終還是要回到「Google 實際拿到什麼」這個驗證動作。

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

如果你只能先做一件事，建議先檢查「重要內容 Google 到底看不看得到」。速度、設計、互動都很重要，但如果搜尋引擎根本看不到內容，後面再多的網址優化、AI 內容策略、成為被推薦的答案都會失去意義。地基沒穩，上層再多調整都很難累積。

JavaScript SEO 的觀念其實延伸到整個 AI 搜尋時代。當 GEO、AEO、LLMO、Google AI Overviews、RAG 這些新場域都在搶內容可見度，爬蟲與 AI 模型對 JS 的處理能力只會更參差不齊。把「可見度驗證」當成內建習慣，比追任何單一新技術更實際；想拿 AI 工具先把自家內容整理成可被引用的素材，可以從 NotebookLM 教學入門。

常見問題 FAQ

為什麼頁面明明收錄了，排名卻還是很差？

收錄只代表 Google 拿得到、能索引這個網址，不等於它認為這個頁面值得排名。排名取決於內容品質、搜尋意圖吻合度、網站權威、使用者體驗、外部連結等多重因素。JavaScript SEO 解決的是「能不能參賽」，至於「能不能得名」要回到內容與權威經營。可以對照搜尋意圖與E-E-A-T進一步排查。

改版後流量突然下滑，要怎麼判斷是不是 JavaScript 惹的禍？

先到 Search Console 的「網頁索引」報表看「已檢索但未建立索引」「已探索但尚未建立索引」這兩個分類有沒有異常增加。再挑幾個流量下滑最多的網址，用網址檢查看渲染後內容是否完整、有沒有資源載入失敗。如果改版把原本伺服器產生的 HTML 改成純前端渲染，這通常就是元兇，這也是網站搬家改版最該提前測試的一環。