本來只是要放一條連結
先講結論：部署 Cloudflare Pages 不一定要用 GitHub Actions。如果你的 Pages 專案已經串好 GitHub，每次推送程式碼，Cloudflare 都會自己建置、自己部署。如果是「直接上傳」（Direct Upload）類型，就把整個網站建置好，再用 Wrangler 上傳。以下是我繞了一大圈才搞懂的過程。
我要做的事其實很小。為了通過聯盟行銷平台的網站審核，要在一篇真的文章裡放一條外接硬碟的商品連結。連結前面清楚寫上：「本頁含有聯盟連結，透過連結購買時，站長可能會獲得佣金。」做好連結、放進文章、commit 到 GitHub。
這些都做完了。
結果程式碼一進 GitHub，一個誤會就跑出來了。
程式碼在 GitHub 上，不代表網頁已經在網路上公開。
平常用的 GitHub Actions 這次不能用。有人提議：那就用 Cloudflare Worker 把這一頁單獨攔下來回傳。可是在這次的使用條件下，這條路也行不通。
明明只是想放一條連結，結果變成一場部署會議：「CI 咧？Worker 咧？Pages 是串 Git 的，還是直接上傳的？」
聯盟行銷版「聖家堂二號館」就這樣動工了。
不過，只要把各個機制拆開來看，事情馬上就變簡單了。
1. 為什麼一定要先有公開的頁面
Sovrn Commerce 給內容網站和部落格的新手說明是這樣：先在申請的網站上放好 Commerce 連結，讓它產生一些點擊，之後才進入審核。[3]
也就是說，不是「審核過了再放連結」，而是先讓審核方看得到真的放好的連結。
Sovrn 也要求：每個有聯盟連結的頁面，都要清楚告訴讀者你可能從中拿到佣金，而且這段說明要放在連結或推廣內容之前、讀者先看得到的地方。[4]
這次需要的不是什麼豪華的比價網站。條件很單純：
- 申請的網站上真的有這篇文章；
- 文章裡有聯盟連結；
- 連結前面有佣金說明；
- 任何人都能用公開網址打開；
- 放好之後，可以產生幾次確認用的點擊。
這裡的重點是倒數第二條：GitHub 儲存庫裡有檔案，不等於它已經是公開網頁。
2. GitHub Actions 停了，Cloudflare Pages 不一定跟著停
GitHub Actions 是 GitHub 內建的自動化功能（CI/CD），在 GitHub 上跑建置、測試和部署。
而 Cloudflare Pages 有自己的 Git 整合，可以直接串 GitHub 或 GitLab。只要你推送到串好的儲存庫，Cloudflare 就會自己建置、自己部署。[1]
流程是這樣：
推送到 GitHub → Cloudflare Pages 偵測到新的 commit → Cloudflare 建置 → Cloudflare 部署
這條路上完全沒有 GitHub Actions。
這點很重要。「GitHub Actions 不能用」跟「沒辦法從 GitHub 自動發布到 Cloudflare」是兩回事。它們本來就是不同的東西。
打個比方：GitHub Actions 是自家倉庫裡的輸送帶，Cloudflare 的 Git 整合則是物流司機自己上門收件。
輸送帶停了，收件的車照樣會來。
3. 第一件事：搞清楚你的 Pages 專案是哪一種
在 Cloudflare Pages 上，沒弄清楚這點就動手，很快就會迷路。
發布方式主要有兩種：
| 類型 | 由什麼觸發 | 誰來建置和部署 | 適合什麼情況 |
|---|---|---|---|
| Git 整合（Git integration） | 推送到 GitHub / GitLab | Cloudflare | 以儲存庫為準，想自動發布 |
| 直接上傳（Direct Upload） | 事先建置好的檔案 | Wrangler 或主控台 | 在自己電腦或其他 CI 建置好，再直接上傳 |
Cloudflare 官方文件寫明：用 Git 整合建立的 Pages 專案，之後不能改成一般的直接上傳專案。已經串 Git 的專案還是可以用 Wrangler 手動部署，但不能在主控台用拖放上傳。[1][2]
反過來也一樣：一開始就是直接上傳的專案，之後不能在同一個專案加上 Git 整合。想改成 Git 自動部署，就要另外建一個新的 Pages 專案。[2]
所以第一個問題不是「要怎麼部署？」
而是：「我現在的 Pages 專案，是 Git 整合還是直接上傳？」
搞清楚這點，一半的選項就自動刪掉了。
4. 如果是 Git 整合，不用為了發布把 GitHub Actions 救回來
如果 GitHub 儲存庫和 Cloudflare Pages 已經正確串好，最快的路不是 Worker，也不是換一套新的 CI。
到 Cloudflare Pages 檢查這幾項：
- 串的是正確的 GitHub 儲存庫；
- 正式環境分支（production branch）就是你真正要發布的分支；
- 正式環境分支的自動建置沒有被暫停；
- 建置指令和輸出資料夾跟現在的專案對得上；
- 推送後，Pages 的 Deployments 頁面有出現新的部署；
- 在
pages.dev網址上看得到新內容； - 最後在你自己的網域上也看得到同樣的新內容。
Cloudflare 的 Git 整合本來就是依照所串分支上的 commit 來建置和部署。[1]
所以就算 GitHub Actions 暫時不能用，只要 Cloudflare 自己的建置還活著，網站照樣能更新。
這時該做的不是再蓋一套複雜系統，而是確認 Cloudflare 原本的「收件口」是不是開著。
5. 如果是直接上傳，要上傳整套建置結果，不是只丟一頁
直接上傳，就是把做好的一整套靜態檔案交給 Cloudflare Pages。官方文件介紹的流程是：先建置好檔案，再用 Wrangler 或主控台上傳。[2]
這時很容易冒出一個危險的念頭：
「我只改了一篇文章，只上傳這一個 HTML 不就好了？」
如果你的靜態網站是整個一起建置的，最好不要這樣做。
因為部署的單位不是「Git 裡改到的那一個檔案」，而是當下整個網站的建置結果。頁面列表、CSS、JavaScript、搜尋索引、圖片、網址導向規則等，常常會一起重新產生。只手動塞一頁進去，線上網站就跟儲存庫對不起來了。
用直接上傳的話，基本流程是：
拉最新的程式碼 → 執行專案的建置指令 → 檢查輸出資料夾 → 上傳全部輸出 → 打開線上網址確認
例如用 Node 做的靜態網站，就執行專案自己的建置指令（像 pnpm build），再上傳產生的 dist 這類資料夾。
重點是別讓線上網站變成「有人手動改過一個檔案、沒人說得清楚的平行世界」。
6. Worker 這條退路不能用，就直接刪掉
想緊急公開一頁時，用 Worker 攔截特定路徑，這個想法本身是可行的。
但像這次一樣，使用條件不允許用 Worker，那繞著它規劃就沒有意義。
「搞不好能用」的路留在設計圖上越多，之後維護就越麻煩。
- GitHub Actions 不能用
- Worker 也不能用
- 那就在 Cloudflare Pages 的 Git 整合和直接上傳之間二選一
就這樣。
與其做十個緊急出口，不如先找到現在開著的那扇大門。
不要為了一條聯盟連結，再蓋一整套部署系統。
這是這次最大的教訓。
7. 算不算「已發布」，要看實際頁面，不是看 commit 紀錄
經營網站最危險的，就是把中間步驟當成「完成」。
- 程式碼寫好了
- commit 到 GitHub 了
- 建置通過了
- Cloudflare 上出現部署了
這些都重要，但讀者看到的只有最後那個網址。
像這次的聯盟審核頁面，最後要確認：
- 用無痕視窗也能打開公開網址；
- 顯示的是最新的文章內容；
- 佣金說明出現在連結前面；
- 商品連結會跳到正確的頁面；
- 手機上顯示正常；
- 需要的話，產生幾次確認點擊；
- 到 Sovrn 後台查看點擊統計和審核狀態。
Sovrn 對內容／部落格類活動的說明是：先放連結，產生點擊，再審核。[3]
所以不是「放進 GitHub 了，等審核吧」，而是審核方能在線上網址看到真的連結，才算站上起跑線。
8. 之後別把聯盟連結寫死在文章內文裡
這一條連結手動放沒問題。
但文章一旦有幾百、幾千篇，每次都要人來決定「這篇要不要放廣告？放哪？放什麼商品？給哪個國家看？」，內容工廠旁邊就會再長出一座廣告工廠。
下一步，最好把文章內文和變現資訊分開管理。
例如文章裡只放這樣一小段設定：
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
發布時再照這個順序處理：
文章 → 判斷要不要變現 → 挑選商品 → 產生聯盟連結 → 產生頁面時插入 → 統計成效
內文當成長期資產保留；商品網址、庫存、商家、依國家分流，都做成可以隨時替換的零件。
這樣一來，連結失效或換商品時，就不用把 12 種語言的內文全部翻出來改。
聯盟連結不是文章本身。
把它當成之後再接到文章上的「銷售管線」，長期經營會穩很多。
9. 結論：CI 掛了，先別蓋新城堡，先找 Cloudflare 的入口
這次的經過很有代表性。
一開始只是：「為了審核，放一條外接硬碟連結吧。」
連結做好了，佣金說明寫好了，程式碼也進了 GitHub。
可是到了正式上線這一步，GitHub Actions 不能用；想用 Worker 繞過去，這條路也不通。
這時候如果再加新系統，目標就會從「公開一條連結」默默變成「擴建部署系統」。
說到底，要判斷的只有這些：
- 現有 Pages 是 Git 整合，就用 Cloudflare 自己的建置；
- 是直接上傳，就建置整個網站，再上傳正式的建置結果；
- Worker 不能用，就從選項裡刪掉；
- 別把 GitHub 的 commit 叫做「已發布」；
- 在真的公開網址上確認佣金說明、連結、頁面顯示和點擊。
技術上最危險的，不是選項太少。
而是不能用的選項一直留在設計圖上。
