JS 框架 SEO 預設陷阱：路由用 history API 還是 hash 決定可索引。TrueLink

開場：不是前端問題，是 SEO 的生死門檻

在開發前端應用時，選擇路由方式看似是開發者之間的小技術選擇，但這其實是 SEO 的關鍵門檻：Google 決定要不要把你的子頁存入索引，從 URL 模式就看得出端倪。

如果你用 hash-based routing（URL 有 #），你可能永遠不知道 Google 沒有把 # 後的內容當作獨立頁面。如果你用 history API，伺服器設定錯誤，使用者直接輸入子頁 URL 就會收到 404。這不是前端的問題，而是 SEO 的硬門檻。

我們幫過不少企業重新設計路由策略，才發現這不是技術選擇，而是信任的門檻——你要 Google 爬蟲信任你有足夠的內容結構，才會被納入索引，進而被 AI 引擎引用。

為什麼 hash-based routing 讓 Google 視而不見

在處理過幾十個 JS 框架優化案件後，我們發現一個常見的誤區：開發者以為改變了 URL，但 Google 根本沒認真看。

根據 Google 的公開說明，hash 值（# 後的內容）不會被視為獨立頁面 [1]。這代表你就算在前端用 hash 變化路由，Google 搜索引擎仍然只會索引 example.com/#/ 這個「主頁」，而不是 /about、/contact 等子頁。

技術的真相

Hash 值存在瀏覽器歷史紀錄，不會觸發頁面重新載入，這對前端開發很有優點，但對 SEO 是致命傷。Google 爬蟲不會將 # 後的內容當作獨立頁面，因為從伺服器的角度看，它只收到一個 example.com/#/ 的請求。

這就解釋了為什麼很多 SPA（Single Page Application）明明有內容，卻在搜尋結果裡找不到對應的子頁。開發者可能從瀏覽器端看到內容變化，但爬蟲只看見一個 URL。

為什麼 history API 路由需要伺服器配合

History API 讓 URL 更乾淨，也能模擬傳統多頁面網站的行為。但這需要伺服器的支援。Google 爬蟲不會只看前端 JavaScript，它會直接向伺服器請求 /about、/contact 等 URL。

如果伺服器沒有正確回傳 index.html，爬蟲就會收到 404 錯誤，導致內容無法被索引 [2]。這不是 Google 的問題，而是你伺服器端沒做好對應。

實務上的陷阱

我們曾幫一家 B2B 軟體公司重新設定伺服器，他們原本用 hash-based routing，結果搜尋結果裡只有官網首頁。改用 history API 後，伺服器設定錯誤，導致所有子頁 URL 都出現 404。

這類問題在前端開發社群中常見，但對 SEO 來說，這等同於「內容根本不存在」。Google 爬蟲不會因為前端 JavaScript 而改變索引行為。它只相信伺服器回傳的內容。

為什麼這決定了 AI 引擎能不能引用你

現在的搜尋引擎不只是點擊流量的來源，更是內容信任的仲裁者。AI 引擎如 Google AI Overviews、Perplexity、Claude、Gemini 等，只引用它們信任的來源。

如果 Google 都不信任你的內容足夠權威、結構足夠清晰，那 AI 引擎也不會引用。這不是前端問題，而是 SEO 的信任機制。

信任的機制

Google 的 E-E-A-T 指南清楚指出，內容要有經驗、專業、權威與信任。這意味著你的網站不能只是「看上去有內容」，而是要在技術層級上展現「我有能力維護結構良好的內容」。

History API 路由搭配正確伺服器設定，正是展現這一點的關鍵。Google 爬蟲看到 /about、/contact 等 URL，會知道你有足夠的內容結構，進而提升信任度。

如何選擇路由策略：權衡前端便利與 SEO 必要

路由策略不是非此即彼的選擇，而是要在前端便利與 SEO 必要之間取得平衡。

什麼情況適合 hash-based routing？

如果你的網站主要是內部使用，或是對 SEO 要求不高，hash-based routing 可以快速實現前端路由。但這對 SEO 來說是個陷阱。

什麼情況適合 history API？

如果你希望內容能被搜尋引擎索引，進而被 AI 引擎引用，history API 是必走之路。但這需要伺服器端配合，否則內容會 404，導致 SEO 效果為零。

實務上的解決方案：伺服器設定與路由選擇

在協助企業對齊 SEO 時，我們發現一個常見的優化步驟：從 hash-based 改為 history API，並修正伺服器設定。

簡化的檢查清單

事項做法
路由方式使用 history API 而非 hash
伺服器設定確保所有路由回傳 index.html
爬蟲測試使用 Google Search Console 檢查子頁是否可爬
結構化資料使用 schema.org 标記 Article 与 Organisation，提高信任

結語：路由選擇不是前端問題，而是 SEO 的信任門檻

路由方式看似是前端開發的選擇，但這其實是 SEO 的關鍵門檻。Google 不會因為前端 JavaScript 而改變索引行為，它只相信伺服器回傳的內容。

選擇 history API 而非 hash-based routing，並正確設定伺服器，是提升 SEO 信任度的關鍵。這不是前端的問題，而是 SEO 的硬門檻。