Awalnya cuma ingin memasang satu tautan
Tugas awalnya kecil: memasang satu tautan afiliasi hard disk eksternal di artikel nyata agar proses peninjauan situs oleh platform afiliasi bisa berjalan.
Halaman perlu berisi konten yang berguna, disclosure yang jelas sebelum tautan komersial, dan tautan yang benar-benar bekerja. Tautannya sudah dibuat dan artikel sudah di-commit ke GitHub.
Lalu masalah sebenarnya muncul.
Kode yang ada di GitHub belum berarti halaman tersebut sudah tayang di internet.
Jalur yang biasa menggunakan GitHub Actions sedang tidak tersedia. Sempat muncul ide untuk mengambil alih satu URL saja melalui Cloudflare Worker, tetapi jalur Worker juga tidak dapat digunakan dalam kondisi operasional saat ini.
Satu tautan afiliasi akhirnya berubah menjadi rapat tentang CI, Workers, Pages, Git integration, dan Direct Upload.
Hampir saja kita membangun Sagrada Família Afiliasi Gedung Nomor 2.
Begitu mekanisme deployment dipisahkan dengan benar, masalahnya jauh lebih sederhana.
1. Mengapa halaman publik harus tersedia lebih dulu
Panduan onboarding Sovrn Commerce untuk situs konten dan blog menjelaskan bahwa campaign perlu memasang tautan Commerce dan menghasilkan klik sebelum campaign ditinjau untuk persetujuan.[3]
Jadi alurnya bukan sekadar “disetujui dulu, baru pasang tautan”. Tim peninjau perlu bisa melihat contoh implementasi nyata.
Sovrn juga menjelaskan bahwa halaman yang memuat tautan afiliasi perlu menyampaikan hubungan kompensasi secara jelas, dan disclosure sebaiknya terlihat sebelum tautan atau promosi afiliasi.[4]
Untuk halaman peninjauan dasar, kebutuhannya sederhana:
- artikel nyata ada di situs yang diajukan;
- artikel memiliki tautan afiliasi;
- disclosure muncul sebelum tautan;
- URL publik benar-benar bisa dibuka;
- setelah implementasi, beberapa klik verifikasi dapat dihasilkan.
Perbedaan terpenting: file di repository belum sama dengan halaman publik.
2. GitHub Actions tidak tersedia bukan berarti Cloudflare Pages ikut tidak tersedia
GitHub Actions adalah sistem CI/CD GitHub untuk menjalankan build, test, dan deployment.
Cloudflare Pages juga memiliki Git integration sendiri. Project Pages dapat terhubung langsung ke GitHub atau GitLab, lalu Cloudflare dapat melakukan build dan deployment setiap kali ada push ke repository yang terhubung.[1]
Alurnya bisa seperti ini:
push ke GitHub → Cloudflare Pages mendeteksi commit → Cloudflare build → Cloudflare deploy
Jalur tersebut tidak membutuhkan workflow GitHub Actions.
Karena itu, “GitHub Actions tidak bisa dipakai” tidak sama dengan “GitHub tidak bisa lagi menerbitkan ke Cloudflare secara otomatis”.
GitHub Actions ibarat ban berjalan internal. Git integration Cloudflare seperti jasa pengiriman yang datang langsung ke gudang untuk mengambil barang.
Ban berjalan bisa berhenti sementara mobil pengangkut tetap datang.
3. Pertama-tama tentukan jenis project Pages yang sudah ada
Ada dua model utama deployment di Cloudflare Pages.
| Model | Pemicu | Lokasi build/deploy | Cocok untuk |
|---|---|---|---|
| Git integration | push GitHub/GitLab | Cloudflare | repository menjadi sumber utama dan deployment otomatis diinginkan |
| Direct Upload | hasil build yang sudah jadi | Wrangler atau dashboard | build dilakukan lokal atau di CI lain, lalu hasilnya diunggah |
Dokumentasi Cloudflare menyebut batasan penting: project yang dibuat dengan Git integration tidak dapat begitu saja diubah menjadi project Direct Upload biasa. Project Git-integrated masih dapat menerima deployment manual melalui Wrangler, tetapi dashboard drag-and-drop tidak tersedia untuk project Git-integrated yang sudah ada.[1][2]
Sebaliknya, project yang dimulai sebagai Direct Upload tidak dapat ditambahkan Git integration pada project yang sama. Untuk berpindah ke deployment Git otomatis, perlu membuat project Pages baru.[2]
Maka pertanyaan pertama bukan “trik deployment apa yang harus dicoba?”
Pertanyaannya adalah: “Project Pages yang ada ini Git integration atau Direct Upload?”
Menjawab ini langsung menghapus setengah labirin.
4. Jika Git integration, tidak perlu menghidupkan kembali GitHub Actions
Jika repository sudah terhubung dengan benar ke Cloudflare Pages, jalur terpendek bukan Worker atau layanan CI baru.
Periksa langsung project Pages:
- repository GitHub yang benar sudah terhubung;
- production branch adalah branch yang memang digunakan untuk publikasi;
- automatic build untuk branch tersebut tidak dinonaktifkan;
- build command dan output directory sesuai project saat ini;
- setelah push, deployment baru muncul di layar Deployments;
- konten baru terlihat di
pages.dev; - custom domain menampilkan versi yang sama.
Git integration Cloudflare memang dirancang untuk build dan deploy berdasarkan commit dari repository yang terhubung.[1]
Jika jalur ini hidup, keterbatasan sementara GitHub Actions tidak menuntut arsitektur deployment baru.
Sebelum menggali terowongan darurat baru, cek apakah pintu utama sebenarnya masih terbuka.
5. Jika Direct Upload, deploy hasil build lengkap, bukan satu halaman buatan tangan
Direct Upload menerima assets yang sudah dibuild. Cloudflare mendukung Wrangler dan dashboard drag-and-drop untuk project Direct Upload.[2]
Pikiran yang menggoda adalah: “Saya cuma mengubah satu artikel. Kenapa tidak upload satu HTML saja?”
Untuk situs statis yang dihasilkan dari build, itu biasanya model yang salah.
Unit deployment adalah seluruh output build, bukan hanya source file yang berubah. Proses build juga bisa menghasilkan ulang routing, CSS, JavaScript, indeks pencarian, metadata, dan asset lainnya.
Alur yang lebih aman:
ambil source terbaru → jalankan build project → periksa output directory → deploy seluruh output → verifikasi URL nyata
Pada project Node, build bisa berupa pnpm build dan hasilnya dapat berada di directory seperti dist.
Tujuannya adalah mencegah production berubah menjadi dunia manual yang berbeda dari repository.
6. Jika Worker tidak tersedia, hapus dari rancangan
Menangani satu URL darurat menggunakan Worker route secara teknis bisa valid.
Namun jika Worker memang tidak tersedia di lingkungan saat ini, mempertahankannya sebagai rencana cadangan utama hanya menambah kompleksitas.
Keputusan dapat diperkecil menjadi:
- GitHub Actions tidak tersedia;
- Worker tidak tersedia;
- gunakan Git integration Pages yang ada atau jalur Direct Upload yang valid.
Sepuluh pintu darurat tidak selalu lebih baik daripada satu pintu yang benar-benar bisa dibuka.
Jangan membangun platform deployment kedua hanya untuk menerbitkan satu tautan afiliasi.
7. Status “published” harus dibuktikan di halaman nyata, bukan melalui SHA
Menulis kode, commit, build sukses, dan deployment tercipta semuanya adalah tahap antara.
Pemeriksaan akhir harus dilakukan pada URL yang akan dilihat pembaca.
Untuk halaman review afiliasi, periksa:
- URL publik terbuka dalam browser session yang bersih;
- isi artikel terbaru terlihat;
- disclosure muncul sebelum tautan afiliasi;
- tautan produk menuju tujuan yang benar;
- tampilan mobile tidak rusak;
- bila perlu, hasilkan beberapa klik verifikasi;
- periksa trafik atau status review di Sovrn.
Sovrn menjelaskan alur onboarding content/blog sebagai implementasi, generasi klik, lalu review.[3]
Jadi titik awal sebenarnya bukan “sudah di GitHub”. Titik awalnya adalah implementasi live yang bisa dilihat oleh reviewer.
8. Saat skala membesar, jangan tanam URL afiliasi langsung ke badan editorial
Satu tautan manual tidak masalah.
Ratusan atau ribuan artikel adalah cerita lain. Jika setiap artikel membutuhkan keputusan manual tentang monetisasi, posisi, produk, dan pasar, content factory akan menumbuhkan pabrik iklan kedua di sampingnya.
Lebih baik pisahkan editorial content dari commercial metadata.
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
Alur publikasi dapat menjadi:
article → monetization gate → product candidates → affiliate link generation → renderer insertion → performance measurement
Artikel tetap menjadi aset jangka panjang. URL produk, stok, merchant, dan routing negara menjadi komponen yang dapat diganti.
Sistem afiliasi sebaiknya menjadi pipa komersial yang terhubung ke artikel, bukan beton yang dituang ke fondasi artikelnya.
9. Kesimpulan: saat CI tidak tersedia, temukan dulu pintu Cloudflare yang sebenarnya
Cerita ini dimulai dari satu tautan afiliasi HDD.
Tautannya ada. Disclosure ada. Source sudah masuk GitHub.
Lalu jalur CI normal tidak tersedia dan jalur Worker juga tidak dapat digunakan.
Menambah mekanisme lain akan mengubah tujuan dari “menerbitkan satu tautan” menjadi “membangun platform deployment baru”.
Pohon keputusan yang berguna sebenarnya kecil:
- jika Pages yang ada memakai Git integration, gunakan native Git build Cloudflare;
- jika Direct Upload, build seluruh situs dan deploy seluruh output melalui jalur yang didukung;
- jika Worker tidak tersedia, hapus dari opsi;
- jangan samakan Git commit dengan deployment production;
- verifikasi disclosure, tautan, render, dan klik pada URL publik yang nyata.
Arsitektur paling berbahaya bukan arsitektur dengan terlalu sedikit pilihan.
Yang berbahaya adalah pilihan yang sudah tidak dapat digunakan tetapi tetap dibiarkan selamanya di diagram.
