เดิมทีแค่อยากวางลิงก์เดียว
งานเริ่มต้นเล็กมาก: วางลิงก์ Affiliate ของฮาร์ดดิสก์ภายนอกไว้ในบทความจริง เพื่อให้แพลตฟอร์ม Affiliate ตรวจสอบการติดตั้งบนเว็บไซต์ได้
หน้าเว็บต้องมีเนื้อหาที่มีประโยชน์ มีข้อความเปิดเผยเรื่องค่าตอบแทนอยู่ก่อนลิงก์เชิงพาณิชย์ และลิงก์ต้องใช้งานได้จริง สร้างลิงก์แล้ว และบทความก็ถูก commit เข้า GitHub แล้ว
จากนั้นปัญหาจริงจึงปรากฏ
การมีโค้ดอยู่ใน GitHub ไม่ได้แปลว่าหน้านั้นเผยแพร่บนอินเทอร์เน็ตแล้ว
เส้นทางปกติที่ใช้ GitHub Actions ใช้งานไม่ได้ชั่วคราว จึงมีแนวคิดว่าจะให้ Cloudflare Worker ดักเฉพาะ URL นั้นเพื่อเผยแพร่แบบฉุกเฉิน แต่ภายใต้เงื่อนไขการใช้งานปัจจุบัน เส้นทาง Worker ก็ใช้ไม่ได้เช่นกัน
ลิงก์ Affiliate เพียงหนึ่งลิงก์จึงกลายเป็นการประชุมเรื่อง CI, Workers, Pages, Git integration และ Direct Upload
เกือบได้เริ่มสร้าง “ซากราดาฟามีเลียแห่ง Affiliate อาคารหมายเลข 2” แล้ว
แต่เมื่อแยกกลไกการดีพลอยออกจากกัน ปัญหาจะง่ายขึ้นมาก
1. ทำไมต้องมีหน้าจริงที่เปิดได้ก่อน
คู่มือ onboarding ของ Sovrn Commerce สำหรับเว็บไซต์เนื้อหาและบล็อกระบุว่า campaign ต้องติดตั้งลิงก์ Commerce และสร้างคลิกก่อนที่จะเข้าสู่การตรวจสอบเพื่ออนุมัติ.[3]
ดังนั้นกระบวนการไม่ใช่เพียง “อนุมัติก่อน แล้วค่อยวางลิงก์” ผู้ตรวจต้องสามารถเห็นตัวอย่างการใช้งานจริงได้
Sovrn ยังอธิบายว่าหน้าที่มีลิงก์ Affiliate ควรแจ้งความสัมพันธ์ด้านค่าตอบแทนให้ชัดเจน และ disclosure ควรมองเห็นได้ก่อนลิงก์หรือเนื้อหาส่งเสริมการขาย.[4]
หน้าสำหรับการตรวจขั้นพื้นฐานต้องการเพียงว่า:
- มีบทความจริงอยู่บนเว็บไซต์ที่ยื่นสมัคร
- บทความมีลิงก์ Affiliate
- disclosure อยู่ก่อนลิงก์
- URL สาธารณะเปิดได้จริง
- หลังติดตั้งสามารถสร้างคลิกตรวจสอบจำนวนเล็กน้อยได้
จุดสำคัญคือ ไฟล์ใน repository ยังไม่ใช่หน้าเว็บสาธารณะ
2. ใช้ GitHub Actions ไม่ได้ ไม่ได้แปลว่า Cloudflare Pages ใช้ไม่ได้
GitHub Actions คือระบบ CI/CD ของ GitHub สำหรับ run build, test และ deploy
Cloudflare Pages มี Git integration ของตัวเอง สามารถเชื่อม project เข้ากับ GitHub หรือ GitLab โดยตรง และเมื่อมี push ไปยัง repository ที่เชื่อมไว้ Cloudflare สามารถ build และ deploy ได้เอง.[1]
เส้นทางจึงเป็น:
push ไป GitHub → Cloudflare Pages ตรวจพบ commit → Cloudflare build → Cloudflare deploy
เส้นทางนี้ไม่จำเป็นต้องใช้ workflow ของ GitHub Actions
ดังนั้น “ใช้ GitHub Actions ไม่ได้” กับ “เผยแพร่จาก GitHub ไป Cloudflare อัตโนมัติไม่ได้” เป็นคนละเรื่อง
ถ้า GitHub Actions คือสายพานภายในคลังสินค้า Git integration ของ Cloudflare ก็เหมือนรถขนส่งที่เข้ามารับของถึงคลังเอง
สายพานหยุด แต่รถรับของยังมาได้
3. ก่อนอื่นต้องรู้ว่า Pages project ปัจจุบันเป็นแบบไหน
Cloudflare Pages มีรูปแบบ deployment หลักสองแบบ
| รูปแบบ | ตัวกระตุ้น | build/deploy ที่ไหน | เหมาะกับกรณี |
|---|---|---|---|
| Git integration | push GitHub/GitLab | Cloudflare | ใช้ repository เป็นแหล่งจริงและต้องการ deploy อัตโนมัติ |
| Direct Upload | output ที่ build เสร็จแล้ว | Wrangler หรือ dashboard | build ในเครื่องหรือ CI อื่นแล้วอัปโหลดผลลัพธ์ |
เอกสาร Cloudflare ระบุข้อจำกัดสำคัญ: project ที่สร้างด้วย Git integration ไม่สามารถเปลี่ยนเป็น Direct Upload project แบบปกติได้ทันที Project ที่เชื่อม Git ยัง deploy แบบ manual ผ่าน Wrangler ได้ แต่ dashboard drag-and-drop ใช้กับ project Git integration เดิมไม่ได้.[1][2]
ในทางกลับกัน project ที่เริ่มด้วย Direct Upload ก็ไม่สามารถเพิ่ม Git integration ภายหลังใน project เดิมได้ หากต้องการ auto deployment จาก Git ต้องสร้าง Pages project ใหม่.[2]
ดังนั้นคำถามแรกไม่ควรเป็น “จะใช้วิธีอ้อมแบบไหนดี?”
แต่ควรเป็น “Pages project ที่มีอยู่เป็น Git integration หรือ Direct Upload?”
ตอบข้อนี้ได้ เขาวงกตก็หายไปครึ่งหนึ่ง
4. ถ้าเป็น Git integration ไม่จำเป็นต้องชุบชีวิต GitHub Actions
หาก repository เชื่อมกับ Cloudflare Pages ถูกต้องอยู่แล้ว ทางที่สั้นที่สุดไม่ใช่ Worker หรือ CI ตัวใหม่
ให้ตรวจใน Pages project:
- เชื่อมกับ GitHub repository ที่ถูกต้องหรือไม่
- production branch คือ branch ที่ใช้เผยแพร่จริงหรือไม่
- automatic build ของ branch นั้นถูกปิดหรือไม่
- build command และ output directory ตรงกับ project ปัจจุบันหรือไม่
- หลัง push มี deployment ใหม่ในหน้า Deployments หรือไม่
pages.devแสดงเนื้อหาใหม่หรือไม่- custom domain แสดงเวอร์ชันเดียวกันหรือไม่
Git integration ของ Cloudflare ถูกออกแบบมาให้ build และ deploy จาก commit ของ repository ที่เชื่อมอยู่แล้ว.[1]
ถ้าเส้นทางนี้ยังทำงาน ข้อจำกัดชั่วคราวของ GitHub Actions ไม่ได้บังคับให้สร้างสถาปัตยกรรม deployment ใหม่
ก่อนขุดอุโมงค์ฉุกเฉิน ลองดูว่าประตูหลักเปิดอยู่หรือไม่
5. ถ้าเป็น Direct Upload ให้ deploy output ของ build ทั้งชุด ไม่ใช่หน้าเดียว
Direct Upload รับ assets ที่ build มาแล้ว Cloudflare รองรับ Wrangler และ dashboard drag-and-drop สำหรับ Direct Upload project.[2]
ความคิดที่ล่อตาล่อใจคือ “แก้แค่บทความเดียว อัปโหลด HTML เดียวไม่ได้หรือ?”
สำหรับเว็บไซต์ static ที่สร้างจาก build โดยทั่วไปไม่ควรคิดแบบนั้น
หน่วย deployment คือ output ของ build ทั้งไซต์ ไม่ใช่ source file ที่แก้เพียงไฟล์เดียว เพราะ build อาจสร้าง routing, CSS, JavaScript, search index, metadata และ assets อื่นใหม่ด้วย
เส้นทางที่ปลอดภัยกว่าคือ:
ดึง source ล่าสุด → run build ของ project → ตรวจ output directory → deploy output ทั้งชุด → ตรวจ URL จริง
สำหรับ Node project อาจใช้คำสั่งอย่าง pnpm build และได้ directory เช่น dist
เป้าหมายคือไม่ทำให้ production กลายเป็นโลกที่แก้มือแยกออกจาก repository
6. ถ้า Worker ใช้ไม่ได้ ก็ลบออกจากแผน
การใช้ Worker route จัดการ URL ฉุกเฉินเพียงหนึ่ง URL ทำได้ในเชิงเทคนิค
แต่ถ้าสภาพแวดล้อมปัจจุบันใช้ Worker ไม่ได้ การเก็บ Worker เป็นแผนสำรองหลักมีแต่เพิ่มความซับซ้อน
การตัดสินใจจึงเหลือเพียง:
- GitHub Actions ใช้ไม่ได้
- Worker ใช้ไม่ได้
- ใช้ Pages Git integration ที่มีอยู่ หรือ Direct Upload path ที่รองรับ
ทางหนีฉุกเฉินสิบทางไม่ได้ดีกว่าประตูหนึ่งบานที่รู้ว่าเปิดได้เสมอไป
อย่าสร้างระบบ deployment ชุดที่สองเพียงเพื่อเผยแพร่ลิงก์ Affiliate หนึ่งลิงก์
7. คำว่า “เผยแพร่แล้ว” ต้องพิสูจน์ด้วยหน้าจริง ไม่ใช่ commit SHA
เขียน code เสร็จ, commit แล้ว, build ผ่าน, หรือ deployment ถูกสร้าง ล้วนเป็นเพียงจุดระหว่างทาง
การตรวจสุดท้ายต้องทำที่ URL ที่ผู้อ่านจะเห็นจริง
สำหรับหน้า Affiliate review ควรตรวจว่า:
- URL สาธารณะเปิดใน browser session ใหม่ได้
- เห็นเนื้อหาล่าสุด
- disclosure อยู่ก่อนลิงก์ Affiliate
- ลิงก์สินค้าไปยังปลายทางที่คาดไว้
- mobile แสดงผลปกติ
- หากจำเป็น สร้างคลิกตรวจสอบเพียงไม่กี่ครั้ง
- ตรวจ traffic หรือสถานะ review ใน Sovrn
Sovrn อธิบาย flow ของ content/blog ว่าเป็นการติดตั้งลิงก์ สร้างคลิก แล้วจึง review.[3]
ดังนั้นจุดเริ่มจริงไม่ใช่ “อยู่ใน GitHub แล้ว” แต่คือ reviewer เปิดเว็บไซต์จริงแล้วเห็น implementation ได้
8. เมื่อขยายสเกล อย่าฝัง Affiliate URL ลงในเนื้อหาหลักถาวร
ลิงก์เดียวจัดการด้วยมือได้
แต่เมื่อมีบทความหลายร้อยหรือหลายพันชิ้น หากทุกบทความต้องตัดสินใจด้วยมือว่าจะ monetize หรือไม่ วางตรงไหน เลือกสินค้าอะไร และตลาดใด โรงงานเนื้อหาจะมีโรงงานโฆษณาอีกหลังงอกข้าง ๆ
ทางระยะยาวที่ดีกว่าคือแยก editorial content ออกจาก commercial metadata
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
จากนั้น flow อาจเป็น:
article → monetization gate → product candidates → affiliate link generation → renderer insertion → performance measurement
บทความยังเป็นทรัพย์สินระยะยาว ส่วน URL สินค้า stock merchant และ routing ตามประเทศเป็นชิ้นส่วนที่เปลี่ยนได้
ระบบ Affiliate ควรเป็น ท่อการค้าที่ยึดต่อกับบทความ ไม่ใช่คอนกรีตที่เทรวมอยู่ในฐานของบทความ
9. สรุป: เมื่อ CI ใช้ไม่ได้ ให้หาทางเข้าจริงของ Cloudflare ก่อนสร้างปราสาทใหม่
เรื่องทั้งหมดเริ่มจากลิงก์ Affiliate ของ HDD เพียงหนึ่งลิงก์
ลิงก์มีแล้ว disclosure มีแล้ว source ก็อยู่ใน GitHub แล้ว
แต่ CI ปกติใช้ไม่ได้ และทางอ้อมด้วย Worker ก็ใช้ไม่ได้เช่นกัน
หากเพิ่มระบบอีกชุด เป้าหมายจะเปลี่ยนจาก “เผยแพร่หนึ่งลิงก์” เป็น “สร้างแพลตฟอร์ม deployment อีกอัน”
decision tree ที่ใช้จริงมีขนาดเล็ก:
- ถ้า Pages เดิมใช้ Git integration ให้ใช้ native Git build ของ Cloudflare
- ถ้าเป็น Direct Upload ให้ build ทั้งไซต์แล้ว deploy output ทั้งชุดผ่านเส้นทางที่รองรับ
- ถ้า Worker ใช้ไม่ได้ ให้ลบออกจากตัวเลือก
- อย่าเรียก Git commit ว่า production deployment
- ตรวจ disclosure ลิงก์ การแสดงผล และคลิกบน URL สาธารณะจริง
สถาปัตยกรรมที่อันตรายที่สุดไม่ใช่สถาปัตยกรรมที่มีทางเลือกน้อย
แต่คือสถาปัตยกรรมที่เก็บทางเลือกซึ่งใช้ไม่ได้แล้วไว้ในแผนภาพตลอดไป
