JavaScript SEO 怎麼做？SPA 網站索引與轉譯檢查

JavaScript SEO 是什麼？為什麼 SPA 網站特別需要注意？

JavaScript SEO 是讓 JavaScript 產生的內容、連結、meta、canonical 與結構化資料，能被搜尋引擎抓取、轉譯、索引與抽取。SPA 網站特別需要注意，因為使用者在瀏覽器中看得到內容，不代表 Google 初始 HTML 或 AI crawler 一定取得得到。

JavaScript SEO 的正確定義

JavaScript SEO 的核心不是「網站不能用 JavaScript」，而是要確認重要 SEO 訊號不會只存在於搜尋系統難以取得的狀態。對搜尋引擎來說，一個頁面至少要能穩定提供主要內容、標準內部連結、title、meta description、canonical、schema 與可理解的 HTML 結構。

如果這些資訊要等瀏覽器執行大量 JavaScript 後才出現，搜尋引擎可能需要額外的轉譯成本；若轉譯失敗、延遲、被資源阻擋，頁面就可能被低估、延後索引，甚至只索引到空殼。

SPA、CSR、SSR 與 SEO 的關係

SPA 常見於 React、Vue、Angular 等前端架構，頁面切換多半依賴 client-side rendering。CSR 可以做出流暢的互動體驗，但若初始 HTML 幾乎沒有正文與連結，SEO 風險就會升高。SSR、SSG 或 Prerendering 的價值，是讓搜尋引擎在抓取時就能取得較完整的 HTML。

使用者看得到，不代表搜尋引擎一定看得到

常見情境是：使用者打開 SPA 後，瀏覽器下載 JavaScript bundle，再透過 API 取得文章、商品或分類資料，所以畫面正常。但查看 view-source 時，HTML 只有 root div 與 script。這時 Googlebot 必須成功抓取資源、排隊轉譯、執行 JS、取得 API 回應，才有機會看到完整內容。

我的判斷很直接：只要頁面承擔自然搜尋流量，就不該把主要正文與內部連結完全交給 CSR。互動可以靠 JS，索引需要的骨架與答案應該先在 HTML 裡。

Googlebot 如何處理 JavaScript：crawl → render → index → rank

Googlebot 處理 JavaScript 通常會經過抓取、轉譯、索引與排名判斷。風險不在於 Google 完全不能讀 JS，而在於 JS 轉譯有成本與時間差，初始 HTML 與 rendered DOM 不一致時，搜尋可見性就可能出問題。

第一步：抓取初始 HTML

Googlebot 先向 URL 發出請求，取得伺服器回傳的初始 HTML。這個階段會看到頁面的狀態碼、canonical、meta robots、title、部分 link 標籤、初始內部連結與可直接讀取的正文。

如果初始 HTML 已經包含主要內容與標準連結，後續轉譯失敗的傷害會小很多。反過來，如果初始 HTML 幾乎沒有內容，Google 需要依賴第二階段轉譯才知道頁面在講什麼。

第二步：轉譯 JavaScript 後讀取 DOM

Google 會把需要轉譯的頁面放入 rendering queue，再以類似瀏覽器的方式執行 JavaScript，讀取 rendered DOM。這一步可能揭露 CSR 產生的正文、路由內容、延後插入的 schema、分頁元件與內部連結。

問題常出現在資源過重、API 被限制、JS 錯誤、內容需要使用者互動才載入，或重要資訊在轉譯後才改寫。Google 能轉譯 JavaScript，不等於每一次、每一頁、每一種前端狀態都能穩定完成。

第三步：判斷內容、連結與結構資料是否可索引

轉譯後，Google 會綜合初始 HTML 與 rendered DOM，判斷頁面主題、內部連結關係、結構化資料、canonical 訊號與內容品質。若 source 與 rendered HTML 差異太大，SEO 需要確認 Google 最終採用的是哪一個版本。

為什麼 rendering delay 會影響新頁面與更新頁面

新頁面若初始 HTML 太少，Google 可能先知道 URL 存在，卻還沒完整理解內容。更新頁面也一樣，若核心資訊只在 JS 後才改變，搜尋結果可能暫時反映舊內容。

對新聞、活動、價格、庫存、課程、熱門商品這類時間敏感頁面，rendering delay 不是抽象技術問題，而是會直接影響搜尋結果更新速度與商業判斷。高價值頁面應該降低對轉譯排隊的依賴。

JavaScript SEO 最常見的 8 種可見性問題

JavaScript SEO 的常見問題多半不是單一 bug，而是內容、連結、meta、schema 或效能訊號在 crawl、render、index、rank、convert 某一層斷掉。最有效的排查方式，是把每個症狀對應到影響層級與修復優先級。

重要內容只在 CSR 後出現

若文章正文、商品資訊、分類介紹或 FAQ 只在 client-side rendering 後才出現，搜尋引擎必須成功轉譯才看得到。對需要排名的頁面，主要內容應至少有 HTML-first 版本。

連結不是標準 <a href="">

重要內部連結若只用 button、div、onclick 或前端狀態切換，crawler 不一定能把它視為可爬取連結。SEO 需要的是清楚的 anchor 與 href，讓搜尋引擎理解頁面之間的關係。

title、description、canonical 被 JS 延後改寫

meta tags 可以由框架管理，但不能讓初始 HTML 與 rendered DOM 長期不一致。canonical 若被 JS 延後改寫，或不同狀態輸出不同 canonical，可能造成索引訊號混亂。

結構化資料只在前端產生

Article schema、FAQ schema、Product schema 若只在前端插入，要確認 Google 測試工具與 URL Inspection 都能看到。更穩的做法，是讓核心 schema 隨 HTML 一起輸出。

Lazy loading 讓內容或連結無法被看到

Lazy loading 適合圖片與非首屏資源，但不該讓主要正文、內部連結或產品列表必須等 scroll、click 或特定 viewport 才載入。內容型頁面尤其要避免把關鍵段落藏在互動後。

Infinite scroll 沒有可爬取 URL

Infinite scroll 若沒有分頁 URL、history state 與可爬取路徑，搜尋引擎可能只看到第一批內容。分類頁、列表頁與文章列表應提供可被直接造訪的 URL。

JS bundle 過重造成 Core Web Vitals 壓力

過重的 JS bundle 會增加主執行緒壓力，影響 LCP、INP 與整體互動體驗。這不只是速度問題，也會影響使用者是否能完成查找、比較、加入購物車或送出表單。

AI crawler 無法穩定取得 JS 內容

許多 AI crawler 與 LLM bot 不保證像現代瀏覽器一樣完整執行 JavaScript。若答案、定義、FAQ、表格與作者資訊只在 JS 後出現，就會降低被抽取與引用的機會。

JavaScript SEO 診斷流程：先關閉 JS，再比對 source 與 rendered DOM

JavaScript SEO 診斷應先確認網站是否依賴 JS，再比對初始 HTML 與 rendered DOM，最後用 GSC、crawler 與 log file 驗證 Google 是否真的抓到並索引。這個順序能把「Google 看不到」變成可重現的證據。

Step 1：關閉 JavaScript，看主要內容與連結是否仍存在

第一步很低技術，但很有效。用瀏覽器 DevTools 或外掛關閉 JavaScript，重新整理目標頁面，檢查 H1、主要正文、商品名稱、價格、分類連結、麵包屑、FAQ 與頁尾內鏈是否仍存在。

若關閉 JS 後整頁只剩載入中、空白畫面或少量導覽，代表 SEO 可見性高度依賴轉譯。我的經驗是，這一步通常能最快讓 SEO、工程與行銷主管對問題有共同畫面。

驗收條件：承擔自然搜尋流量的頁面，關閉 JS 後仍應保留主要內容摘要、標準 anchor 連結、title、canonical 與可理解的 HTML 結構。

Step 2：比對 view-source 與 rendered HTML

view-source 顯示伺服器回傳的初始 HTML；Elements 面板或 crawler 的 rendered HTML 顯示 JavaScript 執行後的 DOM。兩者不必完全相同，但 SEO 需要確認差異是否落在重要訊號上。

如果 title、canonical、robots、schema、H1、正文、內部連結在 source 裡缺席，只在 rendered DOM 出現，就要標成風險。若 source 與 rendered DOM 出現不同 canonical，優先級更高，因為這會干擾索引合併。

Step 3：用 GSC URL Inspection 看 Google 抓到什麼

Google Search Console 的 URL Inspection 可以檢查頁面是否可索引、Google 上次抓取時間、使用者宣告 canonical 與 Google 選定 canonical。對 JS 網站，重點是檢查 Google 渲染後看到的 HTML 與截圖。

若 GSC 顯示頁面可索引，但渲染截圖缺少主要內容，仍然要處理。可索引不等於內容被完整理解，也不等於內部連結與 schema 都被採納。

驗收條件：GSC 中的 live test 應能看到主要內容、關鍵連結、正確 canonical，且沒有被 robots、noindex 或資源阻擋影響。

Step 4：用 crawler 模擬 JS on/off 差異

用 SEO crawler 分別以 JavaScript disabled 與 JavaScript enabled 抓取同一批 URL，對照狀態碼、title、meta description、H1、字數、內部連結數、canonical、schema 與深度層級。

如果 JS on 才找到大量 URL，表示站內連結依賴前端狀態；如果 JS on 與 off 的 canonical 不同，表示索引訊號不穩；如果 JS on 後字數大幅增加，代表主要內容在初始 HTML 缺席。

Step 5：用 log file 判斷 Googlebot 是否穩定抓取

Log file 能回答 crawler 工具回答不了的問題：Googlebot 實際有沒有來、抓哪些 URL、頻率如何、是否集中在少數資源、是否反覆抓 JS 檔卻很少抓深層頁。

若重要分類頁、商品頁、文章頁在 log 裡幾乎沒有 Googlebot 記錄，先處理 crawl path 與內部連結。若 Googlebot 常抓頁面但索引不穩，再回頭檢查 rendered DOM、canonical 與內容品質。

Step 6：依 crawl → render → index → rank → convert 定位問題

最後不要把所有問題都叫做「JS SEO 問題」。SEO 需要把症狀放回 funnel：抓不到是 crawl 問題，轉譯後才出現是 render 風險，canonical 混亂是 index 問題，CWV 差可能影響 rank 與 convert。

CSR、SSR、SSG、Prerendering 怎麼選？

CSR、SSR、SSG、Prerendering 沒有單一最佳答案。JavaScript 網站 SEO 的渲染策略，應依頁面價值、更新頻率、索引需求、內容穩定度與工程成本選擇；高價值公開頁面通常不適合完全依賴 CSR。

CSR：適合登入後功能，不適合承擔主要自然搜尋流量頁

CSR 適合儀表板、會員中心、內部工具、登入後 app 與高度互動功能。這些頁面通常不需要被索引，或內容與使用者權限高度相關。

若首頁、分類頁、商品頁、文章頁、pricing page 完全 CSR，SEO 風險就高。除非已驗證 Google 能穩定讀取，否則不建議讓主要流量頁只靠前端渲染。

SSR：適合高價值 landing page、分類頁、文章頁

SSR 讓伺服器先回傳完整 HTML，搜尋引擎不必等前端完成所有渲染才理解頁面。對商業頁、分類頁、內容頁、產品頁，SSR 常能降低索引延遲與可見性風險。

但 SSR 也帶來工程成本，包括伺服器負載、快取策略、資料取得、部署與錯誤監控。SEO 不該只丟一句「改 SSR」，而要指定哪些頁面需要 SSR，以及驗收什麼訊號。

SSG：適合內容穩定的文章、文件、行銷頁

SSG 適合部落格文章、知識庫、文件、案例頁、穩定的行銷 landing page。預先產生 HTML 的好處是穩定、速度快、容易快取，對 crawler 與 AI bot 都友善。

如果內容更新頻率高，可以搭配 incremental regeneration 或建置流程。關鍵是不要讓已公開、需要排名的內容等到客戶端才組裝。

Prerendering：適合短期補救或特定 bot 需求

Prerendering 可以把特定 URL 先轉成靜態 HTML，讓搜尋引擎抓取時取得完整內容。它常用於既有 SPA 的過渡期，或工程團隊短期無法全面改 SSR 時。

Prerendering 的風險是維護成本與內容同步。如果快取過舊，搜尋引擎看到的內容可能與使用者看到的不一致。因此它比較像補救方案，不應成為所有大型網站的唯一長期架構。

Hybrid rendering：大型網站常見的折衷方案

大型網站通常不會全站用同一種渲染策略。公開 SEO 頁面使用 SSR 或 SSG，登入後 app 用 CSR，部分高互動元件再由客戶端補強，是比較務實的做法。

不同網站型態的 JavaScript SEO 修復優先級

JavaScript SEO 修復不該平均分配資源。優先順序應依「頁面價值 × 索引需求 × 受 JS 影響程度」排序，先修會影響營收、名單、自然搜尋入口與 AI 引用的公開頁面。

電商：分類頁、商品頁、篩選 URL、內部連結

電商網站最優先檢查分類頁與商品頁。分類頁承擔大量非品牌搜尋需求，商品頁承擔轉換，兩者都需要穩定的正文、商品列表、內部連結、canonical 與結構化資料。

篩選 URL 要特別小心。若所有篩選結果都只在前端狀態內，不提供可控 URL，搜尋引擎很難理解分類架構；若所有篩選組合都可索引，又可能造成重複與 crawl budget 壓力。

SaaS：pricing、feature、use case、docs

SaaS 網站的高價值頁面通常是 pricing、feature、use case、comparison、docs 與 integration 頁。這些頁面常由前端框架建立，但不應讓核心價值主張、方案資訊與文件內容只在 JS 後出現。

我的判斷是，SaaS 的公開行銷頁與登入後產品介面要切清楚。前者要 HTML-first，後者可以更重互動；混在一起會讓 SEO 與工程都難驗收。

內容站：文章正文、作者頁、內鏈、schema

內容站的重點是正文可見、作者資訊清楚、內部連結可爬取、Article schema 穩定。若文章是 CSR 後才載入，AI crawler 與搜尋引擎都可能只看到模板。

作者頁與分類頁也要檢查。它們常被忽略，但對 E-E-A-T、主題群聚與內鏈分配有實際影響。

SPA 工具站：公開 landing page 與登入後 app 要切開

SPA 工具站常把首頁、功能頁與 app 介面放在同一套前端路由裡。SEO 修復時，公開 landing page、模板頁、教學頁、pricing page 應優先改成可索引 HTML；登入後工具可維持 CSR。

這種切分比全站重寫更務實，也比較容易排進 sprint。工程師知道改哪幾種路由，SEO 也能清楚驗收。

不建議在本文展開完整產業 SEO 策略

產業策略會牽涉關鍵字、內容地圖、轉換漏斗與競品分析，這些不屬於 JavaScript SEO 的核心範圍。此處只處理前端渲染如何影響可爬取性、索引與可見性。

前端框架 JavaScript SEO 對照：Next.js、Nuxt、React、Vue、Angular、Astro

前端框架本身不是排名因素，真正影響 JavaScript SEO 的是它最後輸出的 HTML、內部連結、meta、schema 與效能。Next.js、Nuxt、Astro、React、Vue、Angular 都能做 SEO，差別在預設風險與實作成本。

Next.js / Nuxt：適合 SSR、SSG、混合渲染

Next.js 與 Nuxt 對 SEO 友善的原因，不是框架名稱本身，而是它們支援 SSR、SSG 與混合渲染。對公開行銷頁、文章頁、分類頁，這類框架比較容易輸出可索引 HTML。

仍要檢查每個路由的實際輸出。若開發時所有資料都在 client component 或前端 API 後才載入，仍可能回到 CSR 的問題。

React / Vue SPA：需特別處理初始 HTML 與路由

純 React SPA 或 Vue SPA 常見問題是初始 HTML 太薄、路由不是真實 URL、內部連結靠 click event、meta 由前端延後改寫。這些都可以修，但需要明確的 SEO 驗收。

如果既有 SPA 已經有流量壓力，可以先挑高價值路由做 SSR、SSG 或 Prerendering，不一定要一次重構全站。

Angular：大型 app 要注意 rendering 與 bundle 成本

Angular 常用於大型應用，SEO 要特別看 rendering 策略、路由、bundle 大小與互動效能。若公開頁需要自然搜尋流量，應評估 Angular Universal 或其他伺服器端輸出方案。

大型 app 的問題通常不只索引，也包括 Core Web Vitals。JS 成本太高時，使用者會先感受到互動延遲，排名與轉換才跟著受影響。

Astro / SvelteKit：內容型與混合型網站的低 JS 選項

Astro 對內容型網站有明顯優勢，因為預設傾向輸出較少 JavaScript。SvelteKit 則能處理 SSR、SSG 與互動需求，適合內容與工具混合的網站。

AI 搜尋與 LLM bot 時代，JavaScript SEO 為什麼更重要？

AI 搜尋讓 JavaScript SEO 更重要，因為 AI crawler 與 LLM bot 不一定會完整執行 JavaScript。想被 AI Overviews、ChatGPT、Perplexity 或其他答案系統抽取，重要答案、FAQ、表格與 schema 應該 HTML-first。

AI crawler 不一定會執行 JavaScript

傳統搜尋引擎至少有較成熟的 rendering 系統，但 AI crawler 的行為差異更大。有些 crawler 偏向抓取靜態 HTML，有些會讀 sitemap、robots、頁面文字與結構化資料，但不保證像使用者瀏覽器一樣等待前端狀態完成。

這使得 JavaScript 網站 SEO 不再只關乎 Google。若內容只在前端執行後產生，AI 系統可能抓到不完整頁面，進而降低引用與摘要的機會。

重要答案、FAQ、schema 應在初始 HTML 可取得

定義、比較表、步驟、FAQ、產品規格、作者資訊與結構化資料，應盡量在初始 HTML 就能取得。這些元素最容易被搜尋引擎與 AI 系統抽取，也最能建立頁面主題。

如果 FAQ 要等使用者展開手風琴才從 API 載入，或 schema 只在瀏覽器端插入，對 AI 可見性並不穩。互動設計可以保留，但基礎內容不應依賴互動才存在。

Passage extraction 需要清楚的 heading、段落與表格

AI 搜尋常以段落、標題、清單與表格理解頁面。清楚的 H2、H3、短段落、語意明確的表格，比大量前端動畫或複雜元件更有利於 passage extraction。

這也是我不建議把重要內容塞在過度客製的前端元件裡的原因。畫面看起來漂亮，但 HTML 結構若不清楚，搜尋與 AI 系統就不容易判斷哪一段可以引用。

JavaScript SEO 與 GEO 的交集

GEO 關心的是內容能否被 AI 系統理解、驗證、抽取與引用；JavaScript SEO 關心的是內容能否被抓取、轉譯與索引。兩者交集在於 HTML-first、清楚 heading、可抽取 passage、穩定 schema 與可驗證作者訊號。

可引用段落的標準很務實：單段能回答一個問題，有明確主詞，不依賴前後文才看懂，旁邊有相關 heading，必要時用表格整理條件與差異。這些內容不應只在 JS 後產生。

JavaScript SEO 上線前檢查表：SEO 與工程如何協作？

JavaScript SEO 應以可重現證據與驗收條件交付。SEO 開 issue 時要附 URL、source/rendered 差異、GSC 或 crawler 證據；工程修復後，要用 PR、上線前與上線後三層檢查表驗收。

開發 PR 檢查：HTML、連結、meta、schema

PR 階段的重點，是避免 SEO 問題被帶進主分支。工程師不需要猜 SEO 意圖，檢查表應明確列出「哪個訊號要在 HTML 裡」、「哪種連結要用 anchor」、「哪個 meta 不能被錯誤改寫」。

上線前檢查：GSC、crawler、rendered DOM

上線前要用 staging 或 preview URL 檢查 rendered DOM、crawler 結果與 schema。若網站不能讓 GSC 檢查 staging，至少要在正式上線後立即做 live test，並保留 rollback 條件。

上線前最該抓的是差異：source 和 rendered DOM 是否出現不同 canonical，JS on/off 是否造成大量內部連結消失，schema 是否重複，title 是否被共用模板覆蓋。

上線後檢查：索引、排名、log、CWV

上線後不要只看頁面能不能打開。SEO 需要追蹤 GSC indexing、coverage、crawl stats、log file、核心關鍵字排名、自然搜尋進站頁與 Core Web Vitals。

JavaScript SEO 修復不會保證排名立即上升。較合理的驗收是：Google 能抓到、能轉譯、索引版本正確、重要頁面進入可競爭狀態，後續再觀察排名與轉換。

什麼問題要進 sprint，什麼可以排低優先級

會影響重要頁面索引、canonical、內部連結、主要內容可見性的問題，應進 sprint。只影響低價值頁、登入後介面、非索引頁或輕微互動體驗的問題，可以排低優先級。

判斷標準不要只看技術難度，而要看頁面價值。pricing page 的 canonical 錯誤，比部落格側邊欄小元件延遲載入更急。

JavaScript SEO 常見迷思

JavaScript SEO 的迷思多半來自過度簡化。Google 可以處理許多 JS，不代表所有 JS 都安全；SPA 可以做 SEO，不代表預設就沒風險；SSR 有價值，也不代表每個頁面都必須 SSR。

迷思 1：Google 可以渲染 JS，所以不用管

現實是 Google 能渲染許多 JavaScript，但轉譯有成本、時間差與失敗條件。SEO 判斷不該停在「能不能渲染」，而要確認 Google 是否穩定看到主要內容、連結、meta、canonical 與 schema。

迷思 2：SPA 一定不利 SEO

SPA 不一定不利 SEO。問題在於公開頁面是否只輸出空殼 HTML、內部連結是否可爬取、meta 是否穩定、重要內容是否能被索引。SPA 若搭配 SSR、SSG、Prerendering 或混合渲染，也能承擔自然搜尋流量。

迷思 3：SSR 一定比 CSR 好

SSR 對 SEO 頁面通常更穩，但不是所有頁面都需要 SSR。登入後 app、個人化 dashboard、內部工具用 CSR 很合理。好的決策是把公開索引頁與登入後功能頁分開處理。

迷思 4：小網站不用做 JavaScript SEO

小網站更不能浪費搜尋引擎的理解成本。若只有十幾個高價值頁面，卻因為 CSR 讓 Google 或 AI crawler 看不到主要內容，損失會很直接。小網站的修復範圍通常較小，反而應該早點把 HTML 基礎做好。

不討論與 JavaScript 無關的排名迷思

反向連結、品牌聲量、內容深度、搜尋意圖與競爭度都會影響排名，但不屬於這裡的核心問題。JavaScript SEO 要先回答一件事：重要內容與訊號是否能被穩定抓取、轉譯、索引與抽取。