Se suponía que era solo un enlace
Respuesta corta: no necesitas GitHub Actions para publicar en Cloudflare Pages. Si tu proyecto de Pages está conectado a GitHub, Cloudflare compila y publica solo cada vez que haces push. Si es un proyecto de Direct Upload (subida directa), compilas el sitio completo y subes el resultado con Wrangler. Así lo aprendí, dando muchas vueltas.
La tarea era mínima. Para pasar la revisión de un programa de afiliados, tenía que poner un solo enlace a un disco duro externo en un artículo real. Antes del enlace iba un aviso claro: "Esta página contiene enlaces de afiliado y el dueño del sitio puede recibir una comisión si compras". Creé el enlace, lo metí en el artículo e hice commit en GitHub.
Listo, pensé.
Pero en cuanto el código llegó a GitHub, salió a la luz una confusión.
Que el código esté en GitHub no significa que la página esté publicada en internet.
GitHub Actions, que usaba normalmente, no estaba disponible. Alguien propuso interceptar solo esa URL con un Cloudflare Worker y servirla desde ahí. Pero con las condiciones de uso de esta vez, ese camino tampoco se podía usar.
Yo solo quería poner un enlace, y de pronto estaba en una reunión de despliegue: "¿Y el CI? ¿Y el Worker? ¿Pages está conectado a Git o es Direct Upload?".
Así empezó la obra de la Sagrada Familia de los afiliados, edificio n.º 2.
Pero si separas cada pieza, el problema se vuelve mucho más sencillo.
1. Por qué hacía falta primero una página pública
Sovrn Commerce les indica a los sitios de contenido y blogs que primero pongan enlaces de Commerce en el sitio y generen algunos clics. Solo después la campaña pasa a revisión.[3]
O sea, no es "te aprueban y luego pones los enlaces". El revisor tiene que poder ver primero un ejemplo real funcionando.
Sovrn también pide avisar claramente a los lectores, en cada página con enlaces de afiliado, que puedes ganar dinero con ellos. Ese aviso debe verse antes del enlace o de la promoción.[4]
Para esto no hace falta un sitio de comparación de productos lleno de lujo. La lista es corta:
- existe un artículo real en el sitio con el que te registraste;
- ese artículo tiene el enlace de afiliado;
- el aviso aparece antes del enlace;
- cualquiera puede abrir la página desde su URL pública;
- después de publicarla, puedes generar algunos clics de prueba.
Lo importante aquí es el penúltimo punto: un archivo en un repositorio de GitHub todavía no es una página pública.
2. Que GitHub Actions no funcione no significa que Cloudflare Pages tampoco
GitHub Actions es la herramienta de automatización (CI/CD) de GitHub. Ejecuta compilaciones, pruebas y despliegues dentro de GitHub.
Cloudflare Pages, en cambio, tiene su propia integración con Git. Conectas el proyecto de Pages directamente a GitHub o GitLab, y cada vez que haces push a ese repositorio, Cloudflare compila y publica por su cuenta.[1]
El flujo queda así:
push a GitHub → Cloudflare Pages detecta el commit → Cloudflare compila → Cloudflare publica
En esa cadena no aparece ningún flujo de GitHub Actions.
Este es el punto clave. "No podemos usar GitHub Actions" no es lo mismo que "GitHub no puede publicar en Cloudflare". Son dos cosas distintas.
Piénsalo así: GitHub Actions es la cinta transportadora dentro de tu propio almacén. La integración con Git de Cloudflare es una paquetería que viene y recoge el paquete ella misma.
La cinta puede estar parada y la paquetería igual pasa a recoger.
3. Primero, averigua qué tipo de proyecto de Pages tienes
Si te saltas este paso, Cloudflare Pages se convierte rápido en un laberinto.
Hay dos formas principales de publicar:
| Tipo | Qué lo inicia | Quién compila y publica | Ideal para |
|---|---|---|---|
| Integración con Git (Git integration) | un push a GitHub / GitLab | Cloudflare | el repositorio es la versión oficial y quieres publicar en automático |
| Direct Upload (subida directa) | archivos ya compilados | Wrangler o el panel | compilas en tu computadora o en otro CI y subes el resultado |
La documentación oficial de Cloudflare deja claro un detalle: un proyecto creado con integración con Git no se puede cambiar después a un proyecto normal de Direct Upload. Aun así, puedes hacer un despliegue manual con Wrangler en un proyecto conectado a Git, pero no puedes usar la opción de arrastrar y soltar del panel.[1][2]
Al revés pasa lo mismo. A un proyecto que empezó como Direct Upload no se le puede agregar después la integración con Git. Si quieres despliegues automáticos desde Git, necesitas un proyecto de Pages nuevo.[2]
Por eso la primera pregunta no es "¿cómo despliego esto?".
Es esta: "¿Mi proyecto de Pages actual es de integración con Git o de Direct Upload?"
Con esa respuesta, la mitad de las opciones desaparecen.
4. Si es integración con Git, no necesitas revivir GitHub Actions
Si tu repositorio de GitHub ya está bien conectado a Cloudflare Pages, el camino más corto no es un Worker ni un CI nuevo.
Revisa esto en tu proyecto de Pages:
- está conectado al repositorio de GitHub correcto;
- la rama de producción es la rama que de verdad quieres publicar;
- las compilaciones automáticas de la rama de producción no están pausadas;
- el comando de compilación y la carpeta de salida coinciden con tu proyecto actual;
- después de un push, aparece un despliegue nuevo en la pantalla Deployments de Pages;
- el contenido nuevo se ve en tu dirección
pages.dev; - al final, tu dominio propio muestra ese mismo contenido nuevo.
La integración con Git de Cloudflare compila y publica a partir de los commits de la rama conectada.[1]
Así que, aunque GitHub Actions no funcione por un tiempo, puedes seguir publicando mientras la compilación propia de Cloudflare esté viva.
Lo que toca aquí no es montar otro sistema complicado. Es revisar si la puerta de recogida de Cloudflare ya está abierta.
5. Si es Direct Upload, sube la compilación completa, no una sola página
Direct Upload significa entregarle a Cloudflare Pages un conjunto terminado de archivos estáticos. La documentación oficial explica cómo subir archivos ya compilados con Wrangler o desde el panel.[2]
Aquí aparece un atajo peligroso:
"Solo cambié un artículo. ¿Por qué no subo solo ese HTML?"
Si tu sitio estático se compila completo, mejor evítalo.
Lo que despliegas no es "el archivo que cambió en Git", sino el resultado completo de la compilación del sitio en ese momento. Una compilación suele regenerar también listas de páginas, CSS, JavaScript, índices de búsqueda, imágenes y reglas de rutas. Si metes una página a mano, el sitio en vivo deja de coincidir con tu repositorio.
Con Direct Upload, el flujo básico es:
bajar la versión más reciente → ejecutar el comando de compilación del proyecto → revisar la carpeta de salida → desplegar todo el resultado → comprobar la URL en vivo
Por ejemplo, en un sitio estático hecho con Node, ejecutas el comando propio del proyecto, como pnpm build, y subes la carpeta que genera, como dist.
Lo importante es que el sitio en producción no se convierta en un mundo paralelo misterioso que alguien editó a mano.
6. Si no puedes usar un Worker, quítalo del plan
Si necesitas publicar una página con urgencia, interceptar esa ruta con un Worker puede funcionar en teoría.
Pero si las condiciones de uso no permiten Workers, como en este caso, no tiene sentido armar el plan alrededor de uno.
Cada camino de "a lo mejor se puede" que dejas en el plano hace todo más difícil de mantener.
- GitHub Actions: no disponible
- Worker: no disponible
- Entonces elige uno: integración con Git de Cloudflare Pages o Direct Upload
Y ya.
Encontrar la única puerta principal que está abierta es más rápido que construir diez salidas de emergencia.
No construyas un segundo sistema de despliegue solo para publicar un enlace de afiliado.
Esa fue la mayor lección de todo esto.
7. "Publicado" se comprueba en la página real, no con el hash de un commit
Un error clásico al manejar un sitio web es llamar "terminado" a un paso intermedio.
- escribiste el código
- hiciste commit en GitHub
- la compilación pasó
- apareció un despliegue en Cloudflare
Todo eso importa, pero los lectores solo ven la URL final.
Para una página de revisión de afiliados como esta, la revisión final es:
- la URL pública abre en una ventana de incógnito;
- se ve la versión más reciente del artículo;
- el aviso de afiliado aparece antes del enlace;
- el enlace del producto lleva a donde debe;
- la página se ve bien en el celular;
- si hace falta, generas algunos clics de prueba;
- revisas en tu cuenta de Sovrn el conteo de clics y el estado de la revisión.
Sovrn describe el flujo de las campañas de contenido y blogs así: poner los enlaces, generar clics y luego revisión.[3]
Así que "ya está en GitHub, a esperar la revisión" no sirve. Solo estás en la línea de salida cuando el revisor puede verlo funcionando en la URL en vivo.
8. Más adelante, no metas las URL de afiliado fijas en el texto del artículo
Un enlace puesto a mano está bien.
Pero cuando tienes cientos o miles de artículos, si una persona tiene que decidir cada vez "¿Este artículo lleva anuncios? ¿Dónde? ¿Qué producto? ¿Para qué país?", junto a tu fábrica de contenido crece otra fábrica de anuncios.
El siguiente paso es separar el texto del artículo de los datos para monetizar.
Por ejemplo, cada artículo solo lleva un pequeño bloque de ajustes como este:
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
Y al publicar, todo fluye así:
artículo → revisión de monetización → selección de productos → creación del enlace de afiliado → inserción al generar la página → medición de resultados
El artículo queda como un activo a largo plazo. Las URL de productos, el inventario, las tiendas y el reparto por país pasan a ser piezas que puedes cambiar.
Así no tienes que revisar el texto en los 12 idiomas cada vez que se rompe un enlace o cambia un producto.
El enlace de afiliado no es el artículo.
Trátalo como una tubería de ventas que conectas al artículo después. A largo plazo aguanta mucho mejor.
9. Conclusión: si falla el CI, busca la entrada real de Cloudflare antes de construir otro castillo
Toda esta historia dice mucho.
Empezó con: "Pongamos un enlace a un disco duro para la revisión".
El enlace estaba hecho. El aviso, escrito. Todo estaba en GitHub.
Pero a la hora de publicarlo, GitHub Actions no se podía usar. Intentar rodearlo con un Worker tampoco funcionó.
Si en ese momento agregas otro sistema más, el objetivo cambia sin que te des cuenta: de "publicar un enlace" a "ampliar la plataforma de despliegue".
Al final, solo necesitas estas decisiones:
- si tu proyecto de Pages usa integración con Git, deja que compile Cloudflare;
- si es Direct Upload, compila el sitio completo y despliega el resultado oficial;
- si no puedes usar Workers, táchalos de la lista;
- nunca llames "publicado" a un commit en GitHub;
- revisa el aviso, el enlace, cómo se ve la página y los clics en la URL pública real.
Lo más riesgoso no es tener pocas opciones.
Es dejar para siempre en el plano opciones que no puedes usar.
La salida de este laberinto resultó bastante simple.
Primero, mira cómo está configurado tu proyecto de Cloudflare Pages.
Con eso bastaba.
