本来只是想放一条链接
先说结论：部署 Cloudflare Pages 不一定要用 GitHub Actions。如果你的 Pages 项目已经连接了 GitHub，每次推送代码，Cloudflare 都会自己构建和部署。如果是“直接上传”（Direct Upload）类型，就把整个网站构建好，再用 Wrangler 上传。下面是我绕了一大圈才想明白的过程。
我要做的事其实很小。为了通过一个联盟营销平台的网站审核，我要在一篇真实的文章里放一条移动硬盘的商品链接。链接前面清楚写上：“本页面含有联盟链接，你通过链接购买时，站长可能会获得佣金。”生成链接、插进文章、提交到 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 发现新提交 → 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 集成就是根据所连分支上的提交来构建和部署的。[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. 算不算“已发布”，要看真实页面，而不是看提交记录
运营网站最危险的，就是把中间步骤当成“完成”。
- 代码写好了
- 提交到 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 提交叫作“已发布”；
- 在真实公开网址上确认佣金说明、链接、页面显示和点击。
技术上最危险的，不是选项太少。
而是用不了的选项一直留在设计图上。
