非工程師如何用 Claude Code 打造一個 Headless WordPress + React 網站，並做到 Core Web Vitals 全綠
三個月前，這個網站從 0 開始。今天，文章開始被 Google AI Overviews 引用，每天有 100+ 的自然流量進來——沒有投放廣告，全部來自 SEO。
我不是工程師，有基本的WordPress 架構理解，擁有六年的 SEO經驗包含 Technical SEO, Content SEO，我認為只需要有好的內容，結合最新的技術，提供最好的用戶體驗，就有機會被Google 排名上去。
這篇文章紀錄我是怎麼透過 Claude Code，從零打造出這個 headless WordPress + React 網站的技術架構，以及為什麼每一個技術決策背後都有明確的理由，而不是「因為聽起來很潮」。
為什麼不直接用 WordPress 佈景主題？
大部分人講到 WordPress，想到的是裝一個佈景主題、掛一堆外掛，網站就上線了。這個方法的問題是：佈景主題和外掛跑在同一個地方，會互相拖慢彼此。外掛越多，網站越肥、越慢，而網站速度直接影響 Google 排名和使用者體驗。
所以這個網站採用的是 headless（無頭）架構：
- WordPress 只負責內容：後台維持原本大家熟悉的文章編輯介面，寫文章、傳圖片、分類標籤，體驗跟一般 WordPress 完全一樣。
- 前台是一個獨立的 React 網站：完全不吃 WordPress 的佈景主題，只透過 API（WPGraphQL）去 WordPress 那邊「拿資料」，畫面全部由 React 自己渲染。
這個切分的好處很直接：WordPress 專心做內容管理，React 專心做「快」。兩邊互不拖累。
這個架構是怎麼被打造出來的
我沒有寫過 React、沒有寫過後端。整個網站是我一頁一頁跟 Claude Code 溝通做出來的——但「把設計稿變成畫面」只是過程中最簡單的一步，真正讓這個網站能撐得住持續迭代、不會越改越爛的，是這幾件事：
1. 動工前先做研究：遇到架構層級的決定，不會讓 Claude Code 憑直覺寫，而是先做研究、比較幾種做法的優缺點，確認方向對了再動手。
2. 每一個改動都要經過審查：每次改完不是直接上線，會做程式碼審查，抓出肉眼絕對看不出來的問題。
3. 對外公開的部分要做安全審查：任何會接觸使用者資料、API 金鑰的地方，都會另外做一次安全審查——確保金鑰不會外洩、機密資訊不會被打包進程式碼裡。
這些東西畫面上都看不到，但這才是「demo」跟「真的能撐住一直加新功能、不會壞掉」之間的差別。
為什麼一定要做 SSR（伺服器端渲染）
一般的 React 網站是這樣運作的：瀏覽器先拿到一個幾乎空白的 HTML，然後才在瀏覽器裡執行 JavaScript 把畫面畫出來。這中間會有一段空白時間——對訪客來說是「網頁載入中」，對 Google 來說更嚴重：很多情況下 Google 抓到的就是那個空白頁面。
所以這個網站用 SSR：伺服器先把資料抓好、把完整網頁組好（標題、內文、圖片、結構化資料），才送到瀏覽器。React 再接手讓網頁變成可以互動。結果是 Google 看到的第一眼、訪客看到的第一眼，都是完整的網頁。
大家最容易忽略的一塊：Core Web Vitals
Core Web Vitals 是 Google 拿來衡量「這個網頁用起來體感好不好」的指標，也是排名因素之一。把 SSR 做好大概能拿到 80% 的分數，剩下 20% 是一連串瑣碎但很花時間的修正——這正是 Claude Code 最擅長的地方：丟 Lighthouse 報告給它，它會找出真正的原因，而不是亂猜亂改。
（插入：東京分類頁手機版截圖，說明行動裝置優先的排版設計）
真正的關鍵：每天迭代，而不是做一次就結束
跑一次真實效能測試 → 把數據丟給 Claude Code → 找出真正的問題根源、提出修法 → 我在瀏覽器上實際驗證 → 上線 → 隔天再測。這個循環跑了三個月，才是「用 AI 做出一個真的快、真的能排名的網站」跟「隨便用 AI 生成一個網站」之間最大的差別。
結果
- 頁面秒開、Core Web Vitals 穩定拿到綠燈分數
- 文章開始被 Google AI Overviews 直接引用
- 從 0 流量到每天 100+ 自然流量，沒花一毛廣告費
- 整個過程，我沒有寫過一行 React 或後端程式碼
兩年前，一個沒有工程背景、只有 SEO 經驗的人要獨立做出這樣一個網站，幾乎是不可能的事。現在，這就是我平常做事的方式。
