為什麼我用 Astro 做個人網站？成本、SEO／GEO 與平台選擇

我一直知道自己需要一個可以長期累積內容的地方，但「開始寫」和「現在就花錢架一個網站」其實是兩個不同的決定。

如果只是想立刻發表文章，我可以選方格子、Medium 或 Blogger；如果想要完整的內容管理後台，也可以租主機架 WordPress。這些方案都比從零建立網站更快，也各有成熟的讀者、工具或生態系。

真正讓我做出選擇的關鍵，是和 AI 討論後發現：我可以用 Astro 建立網站、以 GitHub 保存內容，再透過 GitHub Pages 發布。GitHub Pages 目前可供 GitHub Free 的公開 repository 使用；在還沒有自訂網域時，網站可以先用 github.io 網址，之後想建立品牌網址，主要固定支出就是網域費用。GitHub Pages 使用範圍與限制

更重要的是，這個方法並沒有因此放棄 SEO 與 GEO。網站可以具備和 Blogger、WordPress 接近的搜尋基礎，而且文章是 Markdown 檔案，未來要換主機、換框架或接 CMS，都比把內容綁死在單一平台更容易。

這個網站不只是一個部落格，也同時是我的作品集，以及我練習如何與 AI 協作完成真實專案的第一件作品。

簡單說，我需要的不是一開始就最完整、最昂貴的系統，而是一個成本夠低、搜尋基礎完整、隨時能繼續長大，也能隨時搬走的起點。

真正的前提：品牌才剛開始，我還在探索

大約十年前，我曾經用 WordPress 做過網站。當時即使用最便宜的方案，主機加網域一年也要大約新台幣 5,000 元。

五千元不一定是很高的創業成本，但問題是：我根本還不知道自己會做多久，也還不知道這個品牌最後會長成什麼樣子。

品牌才剛成立，我仍在探索自己的內容、受眾、作品方向與可能的商業模式。如果一開始就購買主機、安裝 WordPress、選佈景主題、處理外掛與安全更新，等於在需求還沒成形前，就先背上一套固定成本和維護責任。

和 AI 把需求拆開後，我才發現目前真正需要付費的東西其實只有「自己的網域」；而且網域也可以等內容方向比較穩定後再買。網站主體先放在 GitHub Pages，就能把早期成本壓到非常低。

這不是為了省下所有費用，而是把錢留到需求真的出現時再花。

我真正要解決的問題

一開始，我問的不是「哪個平台最好」，而是「我希望這個地方未來可以做什麼」。整理之後，我需要的是：

可以持續發表文章，而且內容容易搬移與保存。
可以展示作品，不必把部落格和作品集拆成兩個網站。
視覺能延續我自己的品牌，而不是被平台版型限制。
網站要快、乾淨，並具備基本 SEO、RSS 與社群分享資訊。
日後可以綁定自己的網域，不必重做網站。
我不一定要自己寫程式，但要能透過 AI 協作維護。
在品牌探索期，不要先承擔每年固定的主機費用。
SEO 與 GEO 必須從第一天就能正確建立，而不是之後全部重做。

當需求變成這八點，選擇就不再只是「哪裡寫文章最方便」，而是「我要租用別人的空間，還是建立自己的空間」。

方格子、Medium、WordPress、Blogger 與 Astro 怎麼選？

以下比較不是要分出絕對高下，而是從我這次「個人網站＋部落格＋作品集」的需求出發。

方案	最適合的情境	優點	需要接受的限制
方格子 vocus	想快速寫作、經營華文讀者與訂閱變現	有編輯器、會員、互動、數據與變現工具，不必處理架站	品牌與頁面結構仍在平台框架內，作品集客製彈性較少
Medium	想用簡潔編輯器接觸國際讀者	閱讀體驗成熟，也有 publication 與既有內容網路	客製外觀與追蹤工具受限；自訂網域需要有效會員資格
WordPress 自架	想要傳統後台、外掛與高度擴充	後台成熟，主題與外掛眾多，可做會員、商店或複雜內容網站	需要主機、更新、備份與安全維護；外掛越多，管理成本通常越高
Blogger	想免費、快速建立傳統部落格	Google 帳號即可管理，支援自訂網域、HTTPS、Analytics 與內容匯入匯出	設計與現代開發彈性有限，作品集呈現較難完全客製
Astro＋GitHub Pages	想擁有程式碼、內容與品牌結構	速度快、攻擊面小、可高度客製；文章與作品可用內容集合管理	沒有傳統後台，需要 GitHub、編輯器或 AI 協助更新

方格子官方將自己定位為包含 CMS、會員互動、數據與多元變現工具的創作平台；這對想把心力集中在寫作與社群經營的人很有吸引力。方格子創作者介紹

Medium 的 publication 具有首頁版面、電子報與協作功能，但即使連接自訂網域，網站仍在 Medium 平台內；官方也說明自訂網域需要有效的 Medium 會員資格，而且不能自行加入 Google Analytics 或其他程式碼。Medium 自訂網域說明

WordPress 的強項是成熟後台、主題與龐大的外掛系統，官方也強調它能透過外掛、自訂內容類型與 API 擴充。WordPress 功能介紹但對我現在的需求來說，資料庫、主機和外掛維護不是最想投入的地方。

Blogger 則依然是低門檻的選擇：官方後台可以管理網址、搜尋引擎可見性、HTTPS、Analytics 與文章 feed，也能連接自訂網域。Blogger 設定說明

最後，Astro 本來就是以內容型網站為核心，預設減少傳送到瀏覽器的 JavaScript，並提供內容集合來整理與驗證 Markdown 資料。為什麼選 Astro？對一個以文章和作品為主的網站，這個取向剛好吻合。

SEO 與 GEO，才是我最後選擇的關鍵

成本低只解決「能不能開始」，SEO 與 GEO 才決定這個網站值不值得長期累積。

我不想做一個只有自己知道網址的作品集。我希望未來有人搜尋澳洲打工度假、菲律賓語言學校、個人成長或網站製作時，有機會找到我的文章；生成式 AI 在整理相關問題時，也能正確理解文章是誰寫的、主題是什麼、什麼時候更新，以及每一段在回答什麼問題。

Astro 不會自動保證排名，WordPress 和 Blogger 也不會。真正接近的是「可以建立的搜尋基礎」：

每篇文章有獨立且穩定的網址。
可以設定 SEO title、description、作者、發布日期與更新日期。
自動產生 canonical URL、sitemap 與 RSS。
可以加入 Open Graph 與 BlogPosting 結構化資料。
頁面速度快，主要內容直接存在 HTML 裡。
文章能用明確標題、目錄、表格、FAQ 與官方來源幫助搜尋引擎和生成式 AI 理解。

換句話說，這個做法能提供接近 WordPress SEO 外掛或 Blogger 內建搜尋功能的基礎，但我不需要為了取得這些基礎先維護整套動態後台。

同時，文章原始內容是 Markdown。日後要移到 WordPress、其他靜態網站、Headless CMS 或新的 AI 工作流程時，核心內容仍在自己手上。這種可搬移性也是我把 SEO／GEO 當成長期資產時，很重要的一部分。

真正的決策條件	Astro＋GitHub Pages 的做法	為什麼符合我現在的階段
固定成本	公開網站先使用 `github.io`；自訂品牌網址才購買網域	品牌還在探索，不先背每年主機費
SEO／GEO	自訂 meta、結構化資料、sitemap、RSS、目錄與內容結構	搜尋基礎從第一天建立，不用等換平台再重做
內容搬移	文章以 Markdown 保存，版本在 GitHub	未來可以換主機、框架或 CMS
功能擴充	需要時再加入 CMS、分析工具、後端或商店	確認需求後再花錢，不為尚未使用的功能付費

為什麼我最後沒有直接選平台？

平台最大的優點，是一註冊就能開始；最大的代價，則是我的內容會活在平台設計好的關係裡。

這不代表使用平台就不擁有內容，而是網址、讀者路徑、頁面結構、推薦機制與視覺呈現，多少都要配合平台規則。對純寫作而言，這個交換往往非常合理；但我還希望同一個地方能承載作品、個人介紹與之後尚未決定的功能。

所以我的選擇不是拒絕方格子或 Medium。未來我仍然可以把文章摘要或精選內容同步到其他平台，把它們當成接觸讀者的入口；完整內容與作品檔案則以自己的網站作為主要版本。

這樣的策略比較像：平台負責分發，個人網站負責累積。

為什麼不是 WordPress？

WordPress 很適合需要多人登入、頻繁發文、會員系統、留言、電子商務或大量外掛功能的網站。它的後台讓不碰程式的人也能管理內容，這是明確優勢。

但我目前只有一位作者，品牌也還在探索，主要內容是文章與作品。為了這些需求每年先支付主機費，再維護資料庫、佈景主題和外掛，對我來說比較像是先買了一套大型工具，再只使用其中一小部分。

Astro 產生的是預先建好的靜態頁面。讀者打開網站時，不需要等待伺服器查詢資料庫再組合內容；網站也沒有公開登入後台，因此少了一部分需要長期防護的入口。代價是我不能像 WordPress 一樣登入 /wp-admin 後直接發文。

我接受這個取捨，因為現在可以讓 AI 成為我的內容協作者：我提供想法、素材與判斷，AI 幫我整理文章檔案、檢查格式、更新網站並發布。這個工作方式對我而言，比維護一個傳統後台更接近真正的需求。

這個網站是怎麼完成的？

以下是這次實際採用的流程，也是一份可以重做的簡化教學。

1. 從 Astro 官方 Blog template 開始

先使用官方部落格範本建立基本專案。它已經包含文章頁、內容處理與基本元件，比從空白資料夾開始更穩定。

2. 把文章與作品分成兩個內容集合

文章放在 content/posts/，作品放在 content/works/。每一篇內容都使用 Markdown，並在檔案開頭提供標題、摘要、日期與標籤。

Astro 的 content collections 會依照預先定義的格式驗證資料。如果漏掉必要欄位，網站會在發布前提出錯誤，而不是讓不完整內容直接上線。Astro Content Collections 文件

3. 建立首頁、Blog、Works 與 About

首頁顯示最新文章；Blog 是完整文章列表；Works 使用三欄響應式卡片；About 則預留為獨立頁面。這些區塊彼此分開，未來更新其中一頁，不需要回頭重做整個結構。

4. 建立品牌視覺

網站採用深紫黑底、淡紫主色與米白文字，字體使用 Noto Sans TC。刻意保持簡潔，讓文章和作品成為畫面主體。

5. 補上 SEO 與 GEO 基礎

每篇文章的 frontmatter 會自動產生標題、摘要、作者、日期、標籤、canonical URL、Open Graph 與 Article 結構化資料。網站也會自動產生 sitemap 與 RSS。

GEO（Generative Engine Optimization）不是塞入更多關鍵字，而是讓內容更容易被搜尋系統與生成式 AI 正確理解。因此文章會提供：

開頭直接回答核心問題。
清楚的標題階層。
可比較的表格。
有順序的實作步驟。
明確的結論與常見問題。
可追溯的官方來源。

6. 用 GitHub 保存並自動發布

網站原始碼與內容保存在 GitHub。每次更新 main 分支後，GitHub Actions 會自動檢查並建置，再由 GitHub Pages 發布。GitHub Pages 也支援日後改用自己的網域。GitHub Pages 自訂網域文件

7. 讓 AI 成為內容工作流程的一部分

之後新增文章時，我不一定要自己處理每個技術步驟。我可以先說明主題、觀點、素材和不希望出現的內容，再讓 AI：

整理文章架構與初稿。
補齊 SEO 標題、摘要、標籤與結構。
將內容放進正確集合。
建置檢查。
發布並確認公開網址。

不過，AI 不會替我決定「我是誰」。最終的觀點、經驗與是否發布，仍然要由我負責。

沒有後台，流量要去哪裡看？

這個網站目前沒有傳統後台，也還沒有安裝完整的訪客分析工具。GitHub Actions 顯示的是網站有沒有成功發布，不是有多少人閱讀；GitHub repository 的 Traffic 也主要是程式碼專案的瀏覽與 clone，不應當成網站閱讀數據。

我之後應該把流量分成兩個問題來看。

第一個工具：Google Search Console

Search Console 用來回答「別人如何從 Google 找到我」。Google 官方的成效報表可以查看：

Google 搜尋曝光次數。
實際點擊次數。
點閱率（CTR）。
平均搜尋位置。
哪些搜尋字詞帶來曝光或流量。
哪些文章在 Google 表現最好。

官方說明：Google Search Console 成效報表

設定流程是：

到 Google Search Console 新增網站資源。
驗證自己擁有這個網站；使用自訂網域後，建議用 DNS 驗證。
提交網站的 sitemap：https://merle1022.github.io/sitemap-index.xml。
等 Google 收錄後，到「成效 → 搜尋結果」查看關鍵字、曝光、點擊與熱門頁面。
每月看一次趨勢，不需要每天被數字影響。

對 SEO 與 GEO 而言，我會先看「曝光」有沒有開始增加，再看哪些問題真的讓讀者點進文章，而不是只追求某一個關鍵字的單日排名。

第二個工具：Google Analytics 4（GA4）

GA4 用來回答「讀者進站以後做了什麼」。它可以看整體訪客、流量來源、熱門頁面、使用裝置，以及讀者如何進入網站。Google 官方將 Acquisition 報表用來分析使用者或工作階段從哪裡來，Engagement／Pages 則能看讀者造訪哪些內容。GA4 流量來源說明

未來設定方式是：

建立 GA4 資源。
取得格式類似 G-XXXXXXXXXX 的 Measurement ID。
把 ID 交給 AI 加入網站共用版型。
發布後，到 GA4 的「Reports → Acquisition」看流量來源，到「Engagement → Pages and screens」看熱門文章。

Search Console 與 GA4 並不重複：前者看 Google 搜尋表現，後者看進站後的行為。如果只先做一個，我會先設定 Search Console，因為 SEO／GEO 是這個網站最核心的目標。

什麼情況下，我需要搬離 GitHub Pages 或升級系統？

現在使用 Astro＋GitHub Pages，是因為需求以公開文章與作品為主。未來出現以下情況時，就值得重新評估：

需要會員登入、付費牆或個人化內容：這些功能需要後端、資料庫與權限管理。
需要直接經營購物車、付款或大量商業交易：GitHub Pages 不適合處理敏感交易，真正的商店應使用專門電商或後端服務。
多人需要每天從後台編輯與審稿：這時可以接 Headless CMS，或改用 WordPress 等成熟 CMS。
需要留言、站內搜尋、預約或即時資料：可以先接第三方服務；需求變複雜後再移到支援伺服器功能的平台。
流量或媒體檔案明顯成長：圖片、影片、下載檔與頻寬需求變大時，可改用 Cloudflare Pages、Netlify、Vercel、物件儲存或其他託管方案。
聯盟行銷或商業模式成為主要業務：如果網站不再只是內容與作品，而是高度商業化的服務，就應重新檢查託管條款、分析工具、隱私政策與轉換追蹤需求。

好消息是，升級不代表重寫所有文章。只要內容、網址規劃與結構化資料保持乾淨，Markdown 可以搬到其他主機，Astro 也能繼續使用或接上新的 CMS。

這個做法的缺點是什麼？

這套方法並不是沒有代價。

沒有像 WordPress 一樣的視覺化文章後台。
每次修改都需要重新建置，雖然通常只需要幾十秒。
複雜留言、會員或購物功能，之後需要額外服務。
如果完全不使用 AI，也不熟悉 GitHub，手動工作流程會比平台編輯器多幾步。
流量分析需要另外設定 Search Console 或 GA4，不會自動出現在 GitHub Pages 後台。

但這些缺點對我目前的內容規模還可以接受。更重要的是，文章是普通 Markdown 檔案，網站程式碼也保存在自己的 GitHub repository。即使未來換工具，內容仍然容易取出與搬移。

這個網站本身，就是第一件作品

以前我可能會把「建立作品集」理解成：先完成幾個作品，最後再找一個地方放上去。

這一次順序反過來了。從釐清需求、比較平台、決定架構、建立品牌視覺、整理內容，到把網站真正發布，每一個選擇本身就是作品的一部分。

所以第一篇文章記錄的是「我為什麼做這個網站」，第一個作品則是「我如何把這個網站做出來」。兩者不是重複，而是同一個過程的兩種觀看方式：文章呈現思考，作品呈現結果。

常見問題

使用 Astro 寫部落格需要會寫程式嗎？

自己從零建立與維護時，需要基本的前端與 Git 知識；如果已經有穩定模板並透過 AI 協作，日常新增文章主要是在提供內容、圖片與修改意見。

為什麼不只在方格子或 Medium 發文？

它們適合接觸既有讀者與降低發表門檻，但我還需要作品集、個人品牌與更完整的頁面控制。未來仍可將平台當成分發管道，而不是唯一存放地。

GitHub Pages 是永久免費的嗎？

目前 GitHub Free 的公開 repository 可以使用 GitHub Pages，但服務政策未來仍可能調整。自訂網域需要另外購買，網站內容則可以隨時搬到其他靜態網站託管服務。GitHub Pages 使用範圍與限制

現在可以在哪裡看網站流量？

目前還沒有完整流量儀表板。下一步應先串接 Google Search Console 查看搜尋曝光、關鍵字與點擊；需要了解整體訪客和熱門頁面時，再加入 GA4。

以後可以加入真正的後台嗎？

可以。Astro 能串接 CMS 或遠端內容來源；等發文頻率、協作者數量或預覽需求增加後，再加入後台會比一開始就承擔完整系統更合理。

結語：先建立一個可以持續變好的地方

我選擇 Astro 與 GitHub Pages，不是因為它在所有情況下都勝過方格子、Medium、WordPress 或 Blogger，而是因為它最符合我現在的階段：品牌仍在探索，所以先降低固定成本；SEO 與 GEO 從第一天就要完整；內容與網址必須掌握在自己手上；等真正需要會員、商店、多人後台或更複雜服務時，再把錢花在已經確認的需求上。

這個網站目前仍然很簡單，但它已經是一個真正上線、可以持續累積的起點。接下來要做的，不是反覆更換平台，而是把值得留下的文章與作品，一件一件放進來。