JavaScript SEO 的核心問題不是你用了 React、Vue、Next.js、Nuxt 或 headless CMS，而是搜尋系統最後看見的頁面裡，是否真的有可索引的主內容、內部連結、標題、摘要、canonical、圖片來源與結構化資料。對台灣中小企業來說，最務實的做法是先用 Search Console 的 URL Inspection、瀏覽器檢視原始 HTML 與 rendered HTML 對照，再決定要用 server-side rendering、static rendering、pre-rendering，或只修補少數 lazy-loading 與路由問題。只要關鍵內容要等使用者點擊、滾動或 API 延遲才出現，SEO、AEO 與 GEO 都會失去穩定證據。
JavaScript SEO 先問：搜尋看見的是內容，還是空殼？
Google 的 JavaScript SEO 文件把處理流程拆成 crawling、rendering、indexing 三個階段，並提醒部分 JavaScript 網站的初始 HTML 可能只是 app shell，實際內容要等執行 JavaScript 後才產生。這代表行銷頁、產品頁、服務頁、案例頁和知識庫頁面不能只用「瀏覽器看起來正常」當作 SEO 驗收標準；你要驗收的是搜尋系統取得與渲染後的 HTML 是否包含可被理解、可被連結、可被引用的內容。
Google 也說 server-side 或 pre-rendering 仍然是好主意，因為它讓使用者與爬蟲都能更快取得內容，而且不是所有搜尋或 AI 系統都會執行 JavaScript。對資源有限的 SME 來說，這句話的實務意義很直接：不要為了追流行框架犧牲可見度，尤其是首頁、服務頁、品類頁、熱門商品頁、FAQ 與轉換頁。
什麼情況最需要 JavaScript SEO？
如果你的網站是傳統 WordPress、Ghost、Shopify 或純 HTML，且伺服器回傳的 HTML 已含完整文章與連結，風險通常較低。真正需要 JavaScript SEO 的場景，是品牌網站改成 SPA、前端用 React 或 Vue 重新做官網、產品列表用 API 動態載入、案例牆要滾動才出現、分頁或篩選只改變前端狀態、metadata 由前端路由補上，或 headless CMS 的頁面完全依賴 client-side rendering。
| 網站情境 | 主要 SEO 風險 | 優先處理方式 |
|---|---|---|
| 首頁與服務頁用 SPA 載入 | 初始 HTML 沒有主標題、服務說明與內部連結 | 改用 SSR、SSG 或預渲染重要頁面 |
| 產品列表或文章列表無限滾動 | 搜尋無法穩定發現每一組內容與分頁 URL | 建立可持久連結的分頁 URL 並保留內部連結 |
| 圖片、影片或 FAQ lazy loading | 內容要等互動才載入，rendered HTML 缺少證據 | 讓內容進入 viewport 即載入，不依賴點擊 |
| canonical 與 title 由前端改寫 | 原始 HTML 與渲染後訊號不一致 | 在 HTML 先提供穩定 canonical 與 metadata |
| 錯誤頁只顯示前端狀態 | 不存在的頁面回傳 200，容易變成 soft 404 | 讓伺服器回傳有意義的 404、401、301 或 noindex |
CSR、SSR、SSG、pre-rendering 與 dynamic rendering 怎麼選？
不是所有 JavaScript 網站都要重做。台灣中小企業可以把決策拆成「頁面商業價值」與「內容變動頻率」兩個維度。高價值又低變動的頁面，例如公司介紹、核心服務頁、價格說明、案例頁與常青文章，最適合 static rendering 或 pre-rendering。高價值且常更新的頁面，例如商品詳情、庫存頁、課程活動頁，可以用 server-side rendering 或混合式 rendering。登入後工具、會員中心、後台報表等不靠搜尋獲客的頁面，client-side rendering 通常可以接受。
Google 的 dynamic rendering 文件已明確把它定位為 workaround，不是長期解法，並建議優先使用 server-side rendering、static rendering 或 hydration。這一點對 SME 很重要：如果廠商提議「做一套給爬蟲看的頁面」來處理所有 SEO 問題，要追問維護成本、內容一致性、快取更新、偵測 crawler 的錯誤風險，以及使用者看到的內容是否與搜尋看到的內容一致。Dynamic rendering 只適合少數短期救火情境，不應成為新網站的預設架構。
台灣中小企業的一次性 JavaScript SEO 檢查 SOP
1. 先列出需要搜尋獲客的 URL
不要從技術架構開始，先從商業頁面開始。列出首頁、服務頁、產品分類、熱門商品、案例文章、FAQ、地區頁、活動頁、下載頁與聯絡頁。每一個 URL 都標註目標關鍵字、搜尋意圖、轉換目的、是否需要被 AI 搜尋引用，以及是否有替代頁面。這份清單會決定你該花多少工程資源處理 JavaScript SEO。
2. 對照原始 HTML 與 rendered HTML
用瀏覽器檢視原始碼看伺服器第一時間回傳什麼，再用開發者工具或測試工具看 JavaScript 執行後的 DOM。對每個重要 URL 檢查五件事：H1 是否存在、主要段落是否存在、內部連結是否是可爬的 a href、title 與 meta description 是否正確、canonical 是否穩定。若原始 HTML 幾乎沒有內容，但 rendered HTML 有完整內容，至少要再進 Search Console 做 live test，確認 Googlebot 也能取得相同結果。
3. 用 URL Inspection 驗證 Google 端看到的結果
Search Console 的 URL Inspection 可以顯示 live URL 是否可能被索引、是否允許爬取、是否允許索引、Google 取得的 user agent、page fetch 狀態與 user-declared canonical。Google 文件也提醒，live test 的「URL can be indexed」不是保證，因為它不會檢查所有品質、人工處置或 canonical 選擇等條件。因此，URL Inspection 是必要證據，但不是唯一證據；它要和 Search Console Performance、Page indexing、sitemap、伺服器 log 與內容品質一起看。
4. 修正 lazy loading 與無限滾動
Google 的 lazy-loading 文件指出，相關內容應在進入 viewport 時載入，不應依賴使用者點擊或滾動動作本身，因為 Google Search 不會像真人一樣與頁面互動。對內容型網站來說，首屏主內容、FAQ、產品重點、價格摘要、圖片 src、影片 src、作者與更新資訊都不應被錯誤地藏在互動後面。若使用無限滾動，每個內容區塊應有持久且唯一的 URL，並用內部連結讓搜尋可以發現。
5. 讓 metadata 與 canonical 在 HTML 中穩定
Google 文件允許用 JavaScript 設定 title、meta description 或 canonical，但也提醒 canonical 最好放在 HTML，且不應讓 JavaScript 把原本指定的 canonical 改成不同值。實務上，SME 網站最常見的錯誤是模板預設 title 被前端晚一步覆蓋、每個產品頁都先回傳同一份 metadata，或 canonical 在原始 HTML 與 rendered HTML 不一致。這類問題會讓搜尋結果摘要、重複頁判斷與 AI 引用線索變得不穩。
6. 把錯誤頁、缺貨頁與下架頁做成搜尋看得懂的狀態
在 client-side routing 的 SPA 中，不存在的 URL 很容易仍回傳 200，再由前端顯示「找不到」。Google 的 JavaScript SEO 文件把這類問題連到 soft 404 風險，建議讓錯誤頁導向伺服器回傳 404 的 URL，或在錯誤頁加上 noindex。對電商、課程、活動與預約頁來說，下架、缺貨、售完、改版與合併頁面要有明確的 404、410、301、canonical 或 noindex 策略。
AEO 與 GEO：讓答案引擎可以引用你的頁面
AEO 不是只加 FAQ，GEO 也不是只寫長文。答案引擎需要能從頁面抓到清楚主張、適用情境、資料來源、限制條件與更新時間。如果這些內容在初始 HTML 或 rendered HTML 中不穩定，AI 搜尋就算能看到頁面，也很難可靠引用。Google 的 AI features 文件也說，不需要為 AI features 建立新的 AI 文字檔或特殊 schema；更務實的做法是確保網站可被搜尋系統爬取、內容品質足夠，並用 Search Console 觀察整體 Search traffic。
因此，JavaScript SEO 的 GEO 檢查要加上四個欄位：頁面是否明確說明「誰適用、誰不適用」；重要主張是否連到官方或第一手來源；更新日期是否與內容一致；FAQ、表格、流程與案例是否以 HTML 文字呈現，而不是只藏在圖片、canvas 或互動元件中。這些不是為機器寫垃圾內容，而是讓人的決策資料也能被搜尋和答案系統準確理解。
適用與不適用情境
適用：正在重做官網、改 headless CMS、採用 React/Vue/Next/Nuxt、商品與文章列表用 API 載入、SEO 流量突然下滑、Search Console 顯示已檢索但未索引、或 AI 搜尋引用不到品牌核心頁面的中小企業。
不適用：完全不需要自然搜尋曝光的內部系統、登入後 SaaS 後台、一次性活動報名後台、只透過廣告投放導流且不期待長期索引的頁面。這些頁面仍要照顧速度與可用性，但不一定需要投入完整 JavaScript SEO 改造。
限制：JavaScript SEO 只能解決「搜尋是否看得到與理解得到」的技術問題，不能替代內容策略、品牌信任、頁面體驗、反向連結、產品競爭力或本地商家聲譽。即使 URL Inspection 顯示可索引，也不代表一定會排名或被 AI 摘要引用。
常見錯誤與修正優先級
- 錯誤一：只測 Lighthouse，不測 rendered HTML。速度分數有用，但它不能代表搜尋是否讀到完整內容。
- 錯誤二：所有路由都回傳同一份空殼 HTML。至少讓商業價值最高的頁面有 SSR、SSG 或預渲染版本。
- 錯誤三：篩選、分頁、無限滾動沒有可連結 URL。搜尋和使用者都需要穩定 URL 才能保存、分享與重新進入。
- 錯誤四：FAQ、案例與價格藏在點擊後才載入。如果是搜尋意圖的核心答案，應以可見且可渲染的 HTML 呈現。
- 錯誤五：把 dynamic rendering 當長期架構。它增加維護複雜度，且 Google 已把它定位為 workaround。
更新鮮度與證據
本文於 2026-05-08 依可公開查證來源整理。主要參考包括 Google Search Central 的 JavaScript SEO basics、dynamic rendering as a workaround、lazy-loaded content guidance，Search Console Help 的 URL Inspection tool，以及 Google Search Central 的 AI features and your website。台灣中小企業脈絡則參考經濟部中小及新創企業署對 2025 中小企業白皮書發布 與數位轉型政策方向的說明。
結論：先讓重要頁面可被穩定讀取，再談排名與 AI 引用
JavaScript SEO 最值得做的第一步，是挑出最有商業價值的 20 到 50 個 URL，檢查原始 HTML、rendered HTML、URL Inspection、metadata、canonical、內部連結與 lazy-loading。若核心內容只存在前端執行後的狀態，就把高價值頁面改成 SSR、SSG 或預渲染；若只有部分元件出問題，就先修圖片、FAQ、分頁、錯誤頁與 canonical。台灣中小企業不需要把整個網站工程化到過度複雜，但需要確保最重要的內容能被搜尋系統穩定看到、理解、索引，才有機會進一步取得 SEO 排名、AEO 答案曝光與 GEO 引用。
FAQ
JavaScript SEO 一定要改成 SSR 嗎？
不一定。高價值且需要搜尋曝光的頁面優先考慮 SSR、SSG 或預渲染；會員後台、工具介面或不需要索引的頁面可以保留 client-side rendering。
React 或 Vue 網站是不是天生不利 SEO？
不是。問題不在框架，而在核心內容、內部連結、metadata、canonical 與狀態碼是否能被搜尋系統在爬取和渲染後穩定讀取。
URL Inspection 顯示可索引就代表沒問題嗎？
不代表。Search Console live test 可以檢查許多可用性訊號，但 Google 文件也提醒它不會檢查所有品質、人工處置、canonical 選擇或最終排名因素。
Lazy loading 會傷害 SEO 嗎？
正確實作通常不會。重點是相關內容進入 viewport 時要能載入，並且不要依賴使用者點擊或互動才讓搜尋看見核心內容。
JavaScript SEO 和 AI 搜尋引用有什麼關係？
AI 搜尋和答案引擎需要可讀、可驗證、可引用的頁面內容。如果重要主張、FAQ、來源與更新時間不在可渲染 HTML 中，GEO 可引用性會下降。