En teoría, solo había que publicar un enlace
La tarea original era pequeña: colocar en un artículo real un enlace de afiliado a un disco duro externo para avanzar en la revisión de una plataforma de afiliación.
La página debía incluir contenido útil, una declaración clara sobre la posible compensación antes del enlace comercial y un destino que funcionara. El enlace se creó y el artículo se guardó en GitHub.
Entonces apareció el problema real.
Que el código exista en GitHub no significa que la página esté publicada en Internet.
La ruta habitual mediante GitHub Actions no estaba disponible. También se consideró interceptar únicamente esa URL con un Cloudflare Worker, pero esa vía tampoco era utilizable bajo las restricciones operativas actuales.
Un solo enlace acabó generando una reunión sobre CI, Workers, Pages, Git integration y Direct Upload.
Estábamos a punto de inaugurar la Sagrada Familia del afiliado, edificio número dos.
La solución se vuelve mucho más simple cuando se separan correctamente los mecanismos de despliegue.
1. Por qué era necesario tener primero una página pública real
La guía de incorporación de Sovrn Commerce para sitios de contenido y blogs indica que las campañas deben implementar los enlaces de Commerce y generar clics antes de que la campaña sea revisada para su aprobación.[3]
No es únicamente “primero aprobación y después enlaces”. El equipo de revisión necesita poder ver una implementación real.
Sovrn también explica que las páginas con enlaces de afiliado deben informar claramente de la relación económica y que la declaración debe ser visible antes del enlace o de la promoción.[4]
Para una página básica de revisión, los requisitos son sencillos:
- existe un artículo real en el sitio enviado;
- el artículo contiene el enlace de afiliado;
- la declaración aparece antes del enlace;
- la URL pública se puede abrir;
- después de implementarlo se pueden generar unos pocos clics de verificación.
La distinción importante es esta: un archivo dentro de un repositorio todavía no es una página pública.
2. Que GitHub Actions no esté disponible no significa que Cloudflare Pages también lo esté
GitHub Actions es el sistema CI/CD de GitHub para ejecutar build, pruebas y despliegues.
Cloudflare Pages tiene además su propia integración Git. Un proyecto de Pages puede conectarse directamente a GitHub o GitLab y Cloudflare puede compilar y desplegar automáticamente cuando hay un push en el repositorio conectado.[1]
El flujo puede ser:
push a GitHub → Cloudflare Pages detecta el commit → Cloudflare compila → Cloudflare despliega
Ese flujo no requiere un workflow de GitHub Actions.
Por tanto, “no podemos usar GitHub Actions” no es lo mismo que “GitHub ya no puede publicar automáticamente en Cloudflare”.
Si GitHub Actions es la cinta transportadora interna, la integración Git de Cloudflare es el transportista que viene directamente al almacén a recoger el paquete.
La cinta puede estar parada y el transportista seguir funcionando.
3. Primero hay que identificar qué tipo de proyecto Pages existe
Cloudflare Pages tiene dos modelos principales de despliegue.
| Modelo | Disparador | Dónde se compila/despliega | Cuándo conviene |
|---|---|---|---|
| Git integration | push a GitHub/GitLab | Cloudflare | cuando el repositorio es la fuente de verdad y se desea despliegue automático |
| Direct Upload | salida ya compilada | Wrangler o panel | cuando se compila localmente o en otro CI y se suben los archivos resultantes |
Cloudflare documenta una limitación importante: un proyecto creado con Git integration no se puede convertir simplemente en un proyecto Direct Upload normal. Los proyectos conectados a Git pueden recibir despliegues manuales mediante Wrangler, pero el drag-and-drop del panel no está disponible para esos proyectos Git ya existentes.[1][2]
El sentido contrario también tiene una limitación: un proyecto creado como Direct Upload no puede recibir Git integration posteriormente dentro del mismo proyecto. Para pasar a despliegue Git automático hay que crear un nuevo proyecto Pages.[2]
Por eso la primera pregunta no debería ser “¿qué truco de despliegue pruebo?”
Debe ser: “¿El proyecto Pages actual es Git-integrated o Direct Upload?”
Responderla elimina media parte del laberinto.
4. Si es Git integration, no hace falta resucitar GitHub Actions
Si el repositorio ya está conectado correctamente a Cloudflare Pages, la vía más corta no es un Worker ni otro servicio de CI.
Hay que revisar en Pages:
- que esté conectado el repositorio correcto;
- que la production branch sea realmente la rama que se publica;
- que los builds automáticos de esa rama no estén desactivados;
- que build command y output directory coincidan con el proyecto actual;
- que tras un push aparezca un nuevo deployment en Pages;
- que
pages.devmuestre el contenido nuevo; - que el custom domain muestre la misma versión.
La Git integration de Cloudflare está diseñada precisamente para compilar y desplegar desde los commits del repositorio conectado.[1]
Si esa vía funciona, una restricción temporal de GitHub Actions no obliga a reconstruir toda la arquitectura de despliegue.
Antes de excavar otro túnel de emergencia, conviene comprobar si la puerta principal ya está abierta.
5. Si es Direct Upload, se publica la salida completa del build, no una página suelta
Direct Upload recibe assets que ya han sido compilados. Cloudflare admite Wrangler y drag-and-drop en el panel para proyectos Direct Upload.[2]
Es tentador pensar: “solo cambié un artículo, ¿por qué no subir un HTML?”
En un sitio generado estáticamente, normalmente no es la idea correcta.
La unidad de despliegue no es el archivo fuente que cambió, sino la salida completa del build. El build también puede regenerar routing, CSS, JavaScript, índices de búsqueda, metadata y otros assets.
Un flujo más seguro es:
obtener el source más reciente → ejecutar el build del proyecto → comprobar el output directory → desplegar la salida completa → verificar la URL real
En un proyecto Node, el comando puede ser algo como pnpm build y la salida puede estar en una carpeta como dist.
El objetivo es evitar que producción se convierta en un universo manual distinto del repositorio.
6. Si Worker no está disponible, se elimina del diseño
Usar una route de Worker para resolver una única URL urgente puede ser técnicamente válido.
Pero si el entorno actual no permite usar Workers, mantenerlos como plan principal de emergencia solo aumenta la complejidad.
La decisión se reduce a:
- GitHub Actions no disponible;
- Worker no disponible;
- usar la Git integration existente de Pages o el camino válido de Direct Upload.
Diez salidas de emergencia no son necesariamente mejores que una puerta que sabemos que funciona.
No hace falta construir una segunda plataforma de despliegue para publicar un solo enlace de afiliado.
7. “Publicado” se demuestra en la página real, no con un SHA
Escribir el código, hacer commit, completar el build o crear un deployment son hitos intermedios.
La comprobación final ocurre en la URL que verá el lector.
Para una página de revisión de afiliación conviene verificar:
- la URL pública abre en una sesión limpia;
- aparece el contenido más reciente;
- la declaración está antes del enlace de afiliado;
- el enlace llega al destino esperado;
- la versión móvil funciona;
- si hace falta, se generan unos pocos clics de comprobación;
- Sovrn registra el tráfico o cambia el estado de revisión.
Sovrn describe el flujo de contenido/blog como implementación, generación de clics y posterior revisión.[3]
Por eso el punto de partida real no es “el código ya está en GitHub”, sino “el revisor puede ver la implementación en el sitio público”.
8. A escala, es mejor no incrustar URLs de afiliado directamente en el texto editorial
Un enlace manual no es un problema.
Con cientos o miles de artículos sí lo es. Si cada página exige decidir manualmente si se monetiza, dónde va el bloque, qué producto se muestra y para qué mercado, el sistema de contenido acaba construyendo una segunda fábrica para los anuncios.
Es más robusto separar el contenido editorial de los metadatos comerciales.
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
El flujo puede convertirse en:
article → monetization gate → product candidates → affiliate link generation → renderer insertion → performance measurement
El artículo permanece como activo duradero. URLs de producto, stock, merchant y routing por país se vuelven piezas sustituibles.
El sistema de afiliación debería parecerse a tuberías comerciales conectadas al artículo, no al hormigón de sus cimientos.
9. Conclusión: si CI falla, primero encuentra la entrada real de Cloudflare
Todo empezó con un solo enlace de afiliado a un HDD.
El enlace existía. La declaración existía. El source estaba en GitHub.
Después la ruta habitual de CI dejó de estar disponible y la vía Worker tampoco podía utilizarse.
Añadir otra capa habría cambiado el objetivo de “publicar un enlace” a “construir otra plataforma de despliegue”.
El árbol de decisión útil es pequeño:
- si Pages ya usa Git integration, utilizar el build Git nativo de Cloudflare;
- si es Direct Upload, compilar el sitio completo y desplegar la salida completa por la vía compatible;
- si Workers no están disponibles, eliminarlos de las opciones;
- no confundir un Git commit con un despliegue de producción;
- verificar disclosure, enlace, renderizado y clics en la URL pública real.
La arquitectura más peligrosa no es la que tiene pocas opciones.
Es la que conserva para siempre opciones que ya no se pueden utilizar.
