本來只是要放一條連結
一開始的任務非常小：為了推進聯盟平台的網站審核，在一篇實際文章中放上一條外接 HDD 的聯盟連結。
頁面需要有正常內容，在商業連結之前清楚揭露「透過此連結購買時，營運者可能取得報酬」，而且連結必須能正常前往商品頁。聯盟連結已建立，文章也已提交到 GitHub。
然後真正的問題出現了。
程式碼存在 GitHub，不代表頁面已經在網路上公開。
平常使用的 GitHub Actions 路徑暫時不可用。接著又考慮過用 Cloudflare Worker 只攔截這個 URL 來做緊急發布，但目前的運作條件同樣無法使用 Worker。
只想放一條聯盟連結，最後卻開起 CI、Worker、Pages、Git integration、Direct Upload 的部署會議。
「聯盟行銷版聖家堂二號館」差點正式動工。
只要先把部署方式拆開來看，事情其實簡單很多。
1. 為什麼一定要先有真正可看的公開頁面
Sovrn Commerce 給內容網站與部落格的 onboarding 指南說明，campaign 要先實作 Commerce 聯盟連結並產生點擊，之後才進入核准審查。[3]
也就是說，流程不是只有「先核准，再放連結」。審查人員需要能看到一個真實的實作範例。
Sovrn 也說明，含有聯盟連結的頁面應清楚揭露可能存在的報酬關係，且 disclosure 應放在聯盟連結或推廣內容之前、容易被讀者看見的位置。[4]
最基本的審查頁其實只需要：
- 申請的網站上真的有文章；
- 文章裡真的有聯盟連結；
- 連結之前有 disclosure；
- 公開 URL 可以正常開啟；
- 實作後可以產生少量確認點擊。
最重要的是：repository 裡有檔案，不等於公開網頁已經存在。
2. GitHub Actions 不能用，不代表 Cloudflare Pages 一定不能用
GitHub Actions 是 GitHub 的 CI/CD 系統，可以執行 build、test 與 deploy。
Cloudflare Pages 另外有自己的 Git integration。Pages 可以直接連接 GitHub 或 GitLab；當連接的 repository 有 push 時，Cloudflare 本身可以負責 build 與 deploy。[1]
流程可以是：
push 到 GitHub → Cloudflare Pages 偵測 commit → Cloudflare build → Cloudflare deploy
這條路不需要 GitHub Actions workflow 才能成立。
因此，「GitHub Actions 暫時不能用」不等於「GitHub 不能自動發布到 Cloudflare」。
如果把 GitHub Actions 想成倉庫內的輸送帶，Cloudflare Git integration 就像物流公司直接來倉庫取貨。
輸送帶停止，不代表取貨車也會停止。
3. 第一件事是確認現有 Pages 專案到底是哪一種
Cloudflare Pages 主要有兩種部署模型。
| 模型 | 起點 | build/deploy 在哪裡 | 適合情境 |
|---|---|---|---|
| Git integration | GitHub/GitLab push | Cloudflare | 以 repository 為準並自動發布 |
| Direct Upload | 預先產生的 build 輸出 | Wrangler 或控制台 | 在本機或其他 CI build 後直接上傳 |
Cloudflare 官方文件指出，用 Git integration 建立的 Pages 專案不能直接改成一般 Direct Upload 專案。已連接 Git 的專案仍可用 Wrangler 手動部署，但既有 Git integration 專案不能使用控制台 drag-and-drop。[1][2]
反過來，Direct Upload 專案也不能直接在原專案上補上 Git integration。若要改成自動 Git 部署，需要建立新的 Pages 專案。[2]
所以第一個問題不是「要用哪一招繞路？」
而是：「目前這個 Pages 專案到底是 Git integration 還是 Direct Upload？」
先回答這題，迷宮就少掉一半。
4. 如果是 Git integration，不需要為了部署去復活 GitHub Actions
如果 GitHub repository 已經正確連到 Cloudflare Pages，最短的路不是 Worker，也不是再找一套 CI。
應該直接檢查 Pages 專案：
- 是否連到正確的 GitHub repository；
- production branch 是否就是實際要發布的 branch；
- 該 branch 的自動 build 是否被停用；
- build command 與 output directory 是否正確；
- push 後 Pages 的 Deployments 是否出現新 deployment；
pages.dev是否已看到新內容；- custom domain 是否也顯示同一版本。
Cloudflare Git integration 本來就能依照連接 repository 的 commit 自動 build 與 deploy。[1]
如果這條線還活著，就沒有必要因為 GitHub Actions 暫時受限而重建整套發布系統。
在挖新的緊急通道以前，先確認正門有沒有開。
5. 如果是 Direct Upload，要部署完整 build 輸出，不是手工丟一頁
Direct Upload 是把預先 build 好的 assets 上傳到 Pages。Cloudflare 對 Direct Upload 專案支援 Wrangler 與控制台 drag-and-drop。[2]
很容易冒出一個想法：「這次只改一篇文章，丟一個 HTML 上去不就好了？」
對靜態站點生成器來說，通常不應這樣做。
部署單位不是那個剛修改的 source file，而是整個 build output。build 可能同時更新 routing、CSS、JavaScript、搜尋索引、metadata、assets 與其他頁面。
比較穩定的流程是：
取得最新 source → 執行專案 build → 確認 output directory → 部署完整輸出 → 驗證實際 URL
Node 類型的靜態網站可能使用 pnpm build 之類的專案命令，並產生 dist 等輸出資料夾。
重點是不要讓 production 變成與 repository 分離的手工平行世界。
6. Worker 不能用，就從設計圖刪掉
用 Worker route 只處理一個緊急 URL，在技術上可以成立。
但如果目前環境無法使用 Worker，就不該把它繼續留在主要備援方案裡。
- GitHub Actions 不能用；
- Worker 路徑也不能用；
- 那就只在現有 Pages Git integration 或合法 Direct Upload 路徑之間選擇。
比起打造十個緊急出口，先找到一扇真的能開的門更快。
不要為了一條聯盟連結，再蓋第二套部署平台。
7. 「已發布」要由實際頁面證明，不是由 commit SHA 證明
寫完 code、完成 commit、build 成功、出現 deployment，都只是中間節點。
真正的完成狀態要在公開 URL 上確認。
對聯盟審查頁來說，至少要確認：
- 公開 URL 在乾淨瀏覽器 session 中可以開啟；
- 最新文章內容已出現；
- disclosure 在聯盟連結之前；
- 商品連結能前往預期目的地；
- 行動裝置版沒有壞；
- 如流程需要，產生少量確認點擊；
- 在 Sovrn 後台看到點擊或審查狀態。
Sovrn 對內容／部落格 campaign 的流程就是先實作連結並產生點擊，再進入審查。[3]
因此真正的起點不是「已經 push 到 GitHub」，而是審查者能在實際網站上看到實作。
8. 規模變大後，不要把聯盟 URL 永久焊死在正文裡
一條連結可以手動處理。
但當文章變成數百、數千篇，如果每篇都要人工決定是否商業化、放哪裡、選什麼商品、對應哪個市場，內容工廠旁邊就會再長出一座廣告工廠。
長期來看，應該把 editorial content 與 commercial metadata 分開。
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
發布流程就能變成：
article → monetization gate → product candidates → affiliate link generation → renderer insertion → performance measurement
正文保持為長期資產；商品 URL、庫存、merchant 與國家 routing 則保持可替換。
聯盟系統最好像接到文章上的商業管線，而不是直接澆進文章地基裡。
9. 結論：CI 不能用時，先找到 Cloudflare 真正的入口，再考慮蓋新城堡
故事從一條 HDD 聯盟連結開始。
連結有了，disclosure 有了，source 也進了 GitHub。
但 CI 路徑不能用，Worker 繞路也不能用。
如果這時再新增一套機制，目標就會從「發布一條連結」變成「建造另一個部署平台」。
真正需要的判斷很少：
- 現有 Pages 如果是 Git integration，就用 Cloudflare native Git build；
- 如果是 Direct Upload，就 build 完整網站並部署完整輸出；
- Worker 不能用就從決策樹刪掉；
- 不要把 Git commit 當成 production 完成；
- 在實際公開 URL 驗證 disclosure、連結、顯示與點擊。
最危險的架構不是選項太少。
而是已經不能使用的選項，永遠留在設計圖上。
