我們是做網站的，自己的官網卻被 AI 讀成一個錯誤訊息。這件事說起來有點尷尬，但也正好是最好的教材。
火曜領航的官網是 Vue 3 做的單頁應用，大約 40 條路由，裡面有公司介紹、實績案例、DENBA 導讀，也有 POS 收銀、QR Code 表單、OCR 辨識這些可以直接操作的 Demo。在瀏覽器裡一切正常；用 GPTBot 的身分去抓，原始 HTML 只剩 77 個字，而且全站每個網址回傳的都是同一份內容，sitemap 也只列了 4 個網址。（利害關係揭露：本文作者 Kevin C Lin 同時擔任 DENBA Taiwan 執行顧問。）
為什麼 Vue 單頁應用容易被搜尋與 AI 漏掉？
單頁應用的原理，是伺服器先送一個幾乎空白的 HTML，再由瀏覽器執行 JavaScript，把每一頁的內容畫出來。Google 會排隊把 JavaScript 跑完再索引，但官方文件也提醒，頁面可能在渲染佇列裡停留一段時間，而且「不是所有機器人都能執行 JavaScript」。很多 AI 爬蟲讀的就是那份空白的 HTML。
所以問題不是 Vue 不好，而是「內容頁」和「應用程式」被做在同一個殼裡，前者需要被讀，後者需要互動，需求剛好相反。
我們評估過的三條路
| 做法 | 優點 | 代價 |
|---|---|---|
| 伺服器端渲染（SSR，例如 Nuxt） | 保留 Vue，每頁直出完整 HTML | 要改寫整個專案、多一套 Node 伺服器要維運 |
| 預先渲染 | 改動小，build 時把頁面存成靜態 HTML | 內容一改就要重新 build，文章多了難管理 |
| 內容頁搬到 CMS | 直出 HTML、外掛補齊結構化資料與 sitemap、非工程師也能發文 | 要搬內容、要分流網址 |
我們選了第三條，但不是整站搬：內容頁進 WordPress，互動應用留在 Vue，網址不變。
混合架構怎麼做？
判斷標準很簡單：這一頁需要被搜尋、被 AI 引用，還是需要讓人操作？
- 進 WordPress：首頁、實績案例、服務項目、研究計畫介紹、技術說明、團隊與導讀頁
- 留在 Vue：POS、QR Code 表單、OCR、條碼掃描、各種 Demo 與互動作品
網址分流交給最前面的 nginx：應用的路徑一條一條列白名單，由原本的 Vue 直接回應；其餘全部轉給 WordPress。有兩個細節是實際盤點時才發現的。第一，路徑前綴要寫精確，只寫 /pos 會把將來 WordPress 裡 /position-… 開頭的網址也吃掉；第二，Vue build 時產生的逐頁靜態檔，切換時要排除，否則會蓋掉 WordPress 的同名頁面。舊網址中重複或已經壞掉的頁面，則在 WordPress 裡做 301 轉址。
搬完之後差多少？
新站還在預覽環境，但爬蟲視角已經能量：首頁可讀字數從 217 字變成 1,640 字，案例總覽頁 1,920 字；每頁都有唯一的 H1，並輸出組織、文章與常見問題的結構化資料。應用的部分完全沒動，使用者點進 Demo 的體驗和原本一樣。
如果你的網站也是 Vue 或 React 做的，而且內容頁不少，可以先用爬蟲視角自查確認問題有多大，再決定要走哪一條路。需要討論架構，歡迎到聯絡頁找我們。
常見問題
Vue 網站一定不利 SEO 嗎？
不一定。Google 會執行 JavaScript 再索引，只是會延遲；真正吃虧的是不執行 JavaScript 的爬蟲。做了伺服器端渲染或預先渲染的 Vue 網站，一樣可以直出完整內容。
什麼情況適合把內容搬到 WordPress？
內容頁多、需要經常新增文章，或希望非工程師也能更新內容時，搬到 CMS 最省力。如果整個網站都是互動功能、幾乎沒有文章，做伺服器端渲染會比較合適。
搬到 WordPress 之後，原本的網址會變嗎？
可以不變。我們用 nginx 依路徑分流，內容頁與應用各自回應原本的網址；少數重複或壞掉的舊網址，再用 301 轉到新頁面。
混合架構會不會比較難維護？
會多一層分流設定，但換來的是各做各的專長：內容在 CMS 裡更新，應用在原本的專案裡開發，兩邊互不影響。
最後更新：