為什麼我用 Astro 取代 WordPress 架設公司官網

我做 WordPress 開發超過十五年，公司的主要業務也是 WordPress 相關服務。但這次要架自己的公司官網時，我選了 Astro。

這不是在否定 WordPress。它在需要後台管理、會員系統、電商功能的場景下依然無可取代。但對一個以展示為主的形象官網來說，WordPress 帶來的開發體驗讓我覺得沒有很順暢。

WordPress 架官網的三個痛處

後台操作不適合開發者

WordPress 是 CMS，核心設計是讓非技術人員透過後台介面管理內容。選佈景主題、安裝外掛、設定頁面——都要進後台點來點去。

問題在於，很多佈景主題為了相容 Elementor、Divi 這類頁面編輯器，操作邏輯變得很複雜。我以前設計 WordPress 頁面都是自己手寫 PHP，直接寫 template file，不太碰這些拖拉式編輯器。每次打開後台操作那些介面，總覺得不夠直覺。

我承認這是個人偏好。但身為開發者，在編輯器裡寫程式的效率就是比在瀏覽器裡拖拉方塊高很多。

部署流程太長

用 WordPress 架站，部署流程大致是這樣：

1. 租一台雲端主機（AWS、GCP 或其他 VPS）
2. 安裝 Web Server、PHP、MySQL
3. 本地開發完成後，用 SFTP 或 Git 部署到遠端
4. 處理資料庫同步問題
5. 設定 SSL 憑證、DNS

這套流程跑了十幾年，不是不行，就是煩。尤其是資料庫同步——本地和線上的資料庫經常不一致，每次部署都要多花時間處理。

現在我大部分開發工作都在 Claude Code 裡完成，所有操作都在終端機進行。但 WordPress 的部署流程硬是要我跳出終端機，登入雲端主機面板、開資料庫、設定環境變數。這段體驗的斷裂感讓我很不舒服。

形象網站不需要 CMS

回過頭想，公司官網需要什麼？展示服務項目、放幾篇技術文章、列出作品案例、附上聯絡方式。就這樣。

這些內容更新頻率很低，也不需要讓非技術人員進後台編輯。我自己就是唯一的內容管理者，直接改檔案比開後台更快。帶著整套 CMS 架構跑一個幾乎不需要動態功能的網站，有點殺雞用牛刀。

為什麼是 Astro

我以前用過 Jekyll、Hugo 這類靜態網站產生器，對這種「所有內容都是檔案」的開發模式很熟悉。找替代方案的時候，Astro 進入了我的視野。

Astro 的核心概念和那些靜態產生器一樣：網站設定、頁面模板、文章內容全部存在專案資料夾裡，用 Markdown 寫內容，編譯後產出純靜態的 HTML/CSS/JS。不需要伺服器，不需要資料庫。

但它比傳統靜態產生器進化了幾個地方：

• 元件化開發：用 .astro 檔案寫元件，語法接近 HTML，但支援 props、slot 這些現代前端概念
• Content Collections：內建的內容管理機制，定義好 schema 之後，Markdown 文章會自動做型別驗證
• 多框架支援：需要互動功能時，可以混用 React、Vue、Svelte 元件，不需要整個網站綁定某個框架
• Island Architecture：預設產出零 JavaScript 的靜態頁面，只有標記為互動的元件才會載入 JS

部署方式也很單純——編譯完把 dist/ 資料夾丟到任何靜態託管服務就行了。

實際怎麼做的

為什麼買現成主題，不叫 AI 從零設計

一開始我也想過讓 AI 直接生成整個網站的 UI。但實際試了之後發現幾個問題：AI 產出的前端頁面，整體設計風格很難保持一致——每個區塊看起來都還行，拼在一起就是不對勁。色彩、間距、字體比例這些細節，模型的輸出穩定性還不夠。

要做到好看，得搭配 Figma 先出設計稿、再用各種 prompt 技巧反覆調整，折騰下來花的時間比我預期多太多。

後來我想通了：UI 用現成的就好。買一個設計師做好的主題，視覺品質有保證，元件風格一致，我只要改內容和配色。把時間花在內容和功能上，而不是跟 AI 來回磨 CSS，這樣划算得多。

我認為佈景主題的市場在 AI 開發的時代反而更有價值。開發者可以用 AI 快速改程式邏輯、替換內容，但 UI 設計這件事交給專業設計師做好的成品來處理，比叫 AI 從零生成要可控得多。

挑主題、改程式碼

Astro 官方的主題市集有不少免費和付費選擇。我挑的是一位日本設計師做的 Nagi 主題，設計風格乾淨、排版有質感，很適合企業形象網站。買完之後下載整包程式碼，直接丟進 Claude Code 開始改。

改的過程很直覺：跟 Claude 說「這個區塊的標題改成公司名稱」「服務項目改成這四項」，它就會找到對應的元件檔案進行修改。

搬移 WordPress 內容

舊網站有一些作品案例和技術文章要保留。我的做法：

1. 從 WordPress 後台匯出所有文章，拿到一份 XML 檔案
2. 把 XML 丟進 Astro 專案目錄
3. 跟 Claude 說：「參考這份 XML 裡的文章內容，把現有版型的示範文字替換成我的文章」

Claude 自己去解析 XML、比對版型結構、產生對應的 Markdown 檔案。我放著讓它跑，大概半小時，網站的基本架構和文案就完成了。剩下的工作是挑選要放哪些作品、調整文章的分類和順序。

部署到 Cloudflare Pages

選用 Cloudflare Pages 當主機，設定很簡單：

1. 把專案推到 GitHub
2. 在 Cloudflare Dashboard 連結 GitHub repo
3. 指定 build 指令 npm run build，輸出目錄 dist/
4. 設定自訂網域

之後每次 git push，Cloudflare 會自動偵測到新的提交並觸發部署。從推程式碼到網站更新，大概 30 秒。

整個開發流程變成：在終端機裡用 Claude Code 寫程式碼 → git push → 自動部署完成。中間不需要離開終端機，不需要登入任何面板。

現在寫文章的流程

以前用 WordPress 寫文章：開瀏覽器 → 登入後台 → 新增文章 → 在編輯器裡排版 → 按發佈。

現在的流程：在終端機裡跟 Claude 說「幫我寫一篇關於 X 的文章」→ 它產生一個 Markdown 檔案 → git push → 文章上線。

沒有後台、沒有編輯器、沒有發佈按鈕。對我來說，這個流程順暢太多了。

不是每個網站都適合

我要強調，這個選擇有它的前提。Astro 適合的是內容更新頻率低、不需要非技術人員管理後台、以展示為主的網站。

如果客戶需要自己登入後台改文章、管理會員、經營電商——WordPress 還是更好的選擇。這不是技術優劣的問題，是使用場景的問題。

但以形象官網這個場景來說，我認為自己回不去 WordPress 了。之後接到形象網站的需求，我可能會直接請客戶從 Astro 主題市集挑一個喜歡的設計，剩下的開發和內容替換交給 Claude 處理。整個流程從選主題到上線，應該能壓在幾天之內。