Respuesta rápida
GitHub Pages es nuestra primera opción para documentación, portfolios y páginas de proyectos que ya viven en un repositorio público. Cloudflare Pages encaja mejor en una web de producción que necesita previews automáticas, analítica integrada, cabeceras, redirecciones o funciones.
Para StackClaro elegimos Cloudflare Pages. El sitio tendrá dominio propio, analítica y futura monetización; además, GitHub Pages no está pensado como alojamiento gratuito de un negocio online. GitHub Pages sí funcionó correctamente como publicación estática, pero tuvimos que crear un repositorio público de prueba y adaptar las rutas de Astro.
Cloudflare Pages vs GitHub Pages parece una comparación entre dos alojamientos estáticos gratuitos. Los dos pueden publicar HTML, CSS y JavaScript desde Git, usar un dominio propio y servir la web mediante HTTPS. Sin embargo, parten de ideas distintas.
GitHub Pages convierte un repositorio en una página pública. Cloudflare Pages es una plataforma de despliegue conectada al repositorio, con CDN, previews, analítica y una ruta hacia funciones de servidor. La diferencia importa más que unas décimas en un build.
Qué hemos comparado y qué no
Esta comparativa utiliza tres capas de evidencia:
- Documentación oficial: disponibilidad por plan, límites, dominios, HTTPS, builds, previews, analítica y funciones.
- Prueba reproducible: desplegamos el mismo proyecto Astro utilizado por StackClaro en GitHub Pages y conservamos la instalación de producción en Cloudflare Pages.
- Observaciones propias: registramos obstáculos, tiempos, respuesta HTTP, rutas generadas y facilidad para consultar los logs.
No realizamos una prueba global de latencia, carga o disponibilidad. Los builds se ejecutaron con versiones de Node, estados de caché y commits que no fueron idénticos. Por eso no utilizamos sus tiempos para declarar qué CDN es más rápida.
Nuestra prueba real con Astro
StackClaro es una web Astro estática. Su producción utiliza Cloudflare Pages y el dominio stackclaro.com. Para probar GitHub Pages sin crear contenido duplicado indexable, publicamos una copia temporal con noindex y canonical hacia la web principal.
Primer obstáculo: el repositorio era privado
Nuestro primer intento terminó antes de compilar. GitHub Free solo permite activar Pages desde repositorios públicos. Los repositorios privados requieren GitHub Pro, Team o Enterprise; además, una página publicada desde un repositorio privado continúa siendo pública salvo configuraciones privadas de Enterprise.
No queríamos hacer público el repositorio principal ni pagar un plan solo para la prueba. Creamos stackclaro-github-pages-test como repositorio público independiente. Esta fricción no apareció en Cloudflare Pages, que ya estaba conectado al repositorio privado de producción.
Segundo obstáculo: la ruta base
Un proyecto de GitHub Pages no se sirve necesariamente desde la raíz del dominio. Nuestra dirección quedó así:
https://jontoledo2000.github.io/stackclaro-github-pages-test/Eso significa que una referencia como /favicon.svg apunta al dominio raíz y no al repositorio. En Astro tuvimos que definir una ruta base durante el build de GitHub y adaptar los enlaces internos:
const isGitHubPages = process.env.GITHUB_PAGES === 'true';
const repositoryName = process.env.GITHUB_REPOSITORY?.split('/')[1] || 'stackclaro';
export default defineConfig({
site: 'https://stackclaro.com',
base: isGitHubPages ? `/${repositoryName}` : '/',
output: 'static',
});La configuración condicional mantuvo intacta la producción de Cloudflare. También añadimos PUBLIC_DEPLOYMENT_NOINDEX=true al workflow, desactivamos el sitemap alternativo y conservamos los canonical de stackclaro.com.
Resultados registrados
| Dato observado | Cloudflare Pages | GitHub Pages |
|---|---|---|
| Proyecto | StackClaro, Astro estático | StackClaro, Astro estático |
| Repositorio de la prueba | Privado, conectado a Pages | Público por requisito de GitHub Free |
| Comando | npm run build | npm run build |
| Salida | dist | dist |
| Entorno observado | Node 22.19.0 y npm 10.9.2 | Node 24.20.0 y npm 11.19.0 |
| Astro check | 0 errores, 0 warnings y 0 hints | 0 errores, 0 warnings y 0 hints |
| Páginas indicadas por Astro | 14 | 14 |
| Build interno de Astro | 886 ms | 602 ms |
| Resultado | Producción desplegada | Prueba desplegada |
En GitHub Actions, la instalación de 302 paquetes tardó 6 segundos, el paso completo de build indicó 5 segundos, la subida del artefacto 2 segundos y la publicación del deployment aproximadamente 6,04 segundos. El servidor respondió finalmente:
HTTP/1.1 200 OK
Server: GitHub.com
Cache-Control: max-age=600
Strict-Transport-Security: max-age=31556952El HTML confirmó noindex, follow, canonical hacia https://stackclaro.com/ y recursos bajo /stackclaro-github-pages-test/. Los números describen esta ejecución concreta; no son un benchmark entre redes.
Los logs de GitHub Actions fueron menos directos
GitHub conserva información técnica detallada, pero obtener un registro limpio nos resultó menos sencillo que en Cloudflare Pages, Vercel o Netlify. Tuvimos que entrar en el workflow, distinguir los jobs build y deploy, desplegar pasos individuales y separar la salida de nuestra aplicación de los scripts internos de las acciones.
No es una carencia de datos. Es una diferencia de experiencia: GitHub Actions ofrece mucha profundidad, pero exige conocer su estructura. Para una comprobación rápida, el registro de Cloudflare Pages nos pareció más fácil de leer.
La diferencia fundamental entre GitHub Pages y Cloudflare Pages
GitHub Pages
Publica una web estática asociada a una cuenta, organización o repositorio. Brilla cuando el sitio es una extensión natural del proyecto: documentación, demos, portfolios o páginas de código abierto.
Cloudflare Pages
Trata la web como un proyecto de despliegue. Añade previews por pull request, analítica, reglas de cabeceras y redirecciones, integración con DNS y funciones vinculadas a Workers.
Si solo necesitas publicar archivos estáticos desde un repositorio público, GitHub Pages puede ser suficiente. Si la web es un producto editorial o comercial que evolucionará, Cloudflare ofrece más piezas alrededor del hosting.
Coste y límites gratuitos
Ambos pueden costar 0 € para un sitio estático pequeño, pero sus límites no utilizan las mismas unidades.
| Límite | GitHub Pages | Cloudflare Pages Free |
|---|---|---|
| Disponibilidad gratuita | Repositorios públicos | Repositorios públicos o privados conectados |
| Tamaño del repositorio fuente | 1 GB recomendado | No se expresa con la misma cuota en la documentación de Pages |
| Tamaño del sitio publicado | Máximo 1 GB | Hasta 20.000 archivos |
| Tamaño máximo por asset | No es la unidad principal publicada para Pages | 25 MiB |
| Transferencia | 100 GB/mes como límite flexible | Solicitudes a assets estáticos gratuitas e ilimitadas |
| Builds | 10/hora como límite flexible; no aplica al workflow personalizado | 500/mes y uno simultáneo |
| Tiempo máximo | 10 minutos por deployment | 20 minutos por build |
| Dominios personalizados | Admite dominio propio | 100 por proyecto en Free |
| Previews activas | Sin equivalente automático por PR en la experiencia estándar | Ilimitadas |
| Proyectos | Un sitio de proyecto por repositorio | 100 proyectos por cuenta |
En Cloudflare, 500 builds mensuales equivalen a unos 16,7 builds al día si se repartieran uniformemente. Es un cálculo de StackClaro, no una recomendación de Cloudflare. Las solicitudes estáticas son ilimitadas siempre que no invoquen Pages Functions; las funciones consumen las cuotas de Workers.
En GitHub, el límite de 10 builds por hora no se aplica cuando se construye y publica mediante un workflow personalizado de GitHub Actions, como hicimos nosotros. Los runners estándar son gratuitos en repositorios públicos y para GitHub Pages. En repositorios privados existen cuotas según el plan y posibles costes al superarlas.
GitHub limita el tamaño total y la transferencia. Cloudflare limita principalmente builds, número de archivos y tamaño por asset. No existe una conversión perfecta entre ambos modelos.
Dominio propio, DNS y HTTPS
Las dos plataformas admiten dominios personalizados y HTTPS. GitHub Pages acepta dominios raíz, www y otros subdominios; recomienda verificar el dominio para reducir el riesgo de apropiación y puede redirigir entre el dominio raíz y www cuando ambos registros están correctamente configurados.
Todos los sitios de GitHub Pages configurados correctamente admiten HTTPS. En nuestra URL predeterminada github.io, HTTPS era obligatorio y la respuesta incluyó HSTS.
Cloudflare Pages también permite conectar un dominio propio. Cuando el DNS ya está administrado por Cloudflare, el alta de dominio, certificado, redirecciones y otras reglas queda dentro del mismo panel. Para StackClaro esta centralización fue una ventaja práctica: dominio, DNS, CDN, seguridad y analítica permanecen bajo la misma cuenta.
No movimos stackclaro.com durante la comparación. GitHub Pages utilizó exclusivamente su subdominio temporal.
Builds, automatización y registros
Cloudflare Pages detecta el repositorio, ejecuta el comando configurado y publica la carpeta de salida con cada push a la rama de producción. También permite controlar ramas, variables de entorno y despliegues desde el panel.
GitHub Pages puede publicar archivos estáticos directamente, utilizar Jekyll o delegar el proceso en GitHub Actions. Para Astro usamos el workflow oficial con permisos para leer el repositorio, escribir en Pages y emitir el token de identidad:
permissions:
contents: read
pages: write
id-token: write
steps:
- uses: actions/checkout@v7
- uses: withastro/action@v6
- uses: actions/deploy-pages@v5GitHub Actions ofrece más libertad para construir una canalización a medida. Esa flexibilidad también añade conceptos: workflows, jobs, permisos, artefactos, entornos y acciones versionadas. Cloudflare es menos configurable a ese nivel, pero más directo para el caso habitual de conectar y desplegar.
Previews por rama y pull request
Aquí Cloudflare Pages presenta una diferencia clara. Cada pull request abierto desde el propio repositorio puede recibir una URL de preview única que se actualiza con los nuevos commits. Cloudflare permite mantener un número ilimitado de previews activas y añade por defecto la cabecera X-Robots-Tag: noindex.
GitHub Pages publica un sitio por repositorio. Nuestro workflow generó una única URL y no creó entornos independientes por pull request. Es posible construir automatizaciones adicionales con Actions o recurrir a servicios externos, pero no obtuvimos una función equivalente lista para activar en Pages.
Para documentación con una publicación principal, esto puede ser suficiente. Para un equipo que quiere revisar cada cambio antes de unirlo, las previews automáticas de Cloudflare reducen trabajo.
Analítica y visibilidad del tráfico
Cloudflare Pages ofrece activación con un clic de Cloudflare Web Analytics. En el siguiente despliegue, la plataforma inyecta automáticamente su fragmento de JavaScript. El servicio está disponible en todos los planes y muestra métricas de uso y rendimiento percibido por visitantes.
GitHub Pages no incorpora un panel equivalente de analítica para las visitas del sitio. GitHub ofrece información del repositorio y Actions, pero para medir páginas vistas, fuentes de tráfico o Core Web Vitals hay que integrar una herramienta externa.
En StackClaro activamos Web Analytics desde el panel de Cloudflare. Durante la puesta en marcha aprendimos también que las solicitudes de infraestructura, bots y comprobaciones propias no deben interpretarse automáticamente como personas reales: para decisiones editoriales seguiremos utilizando Search Console y analítica web, no el contador bruto de peticiones del CDN.
Funciones, cabeceras, redirecciones y páginas de error
| Capacidad | GitHub Pages | Cloudflare Pages |
|---|---|---|
| Archivos estáticos | Sí | Sí |
| Página 404 personalizada | Sí | Sí |
| Cabeceras HTTP desde el proyecto | Sin un sistema equivalente a _headers | _headers, hasta 100 reglas |
| Redirecciones desde el proyecto | Requieren soluciones alternativas | _redirects, hasta 2.100 reglas combinadas |
| Funciones de servidor | No | Pages Functions bajo cuotas de Workers |
| Bindings con servicios | No | KV, Durable Objects y otros servicios mediante Workers |
Esta diferencia apareció en nuestra protección SEO. En Cloudflare, Vercel y Netlify pudimos utilizar cabeceras para marcar copias de prueba. En GitHub Pages optamos por una etiqueta HTML:
<meta name="robots" content="noindex, follow">Para una página completamente estática no es un problema. Cuando aparecen formularios, autenticación, APIs o lógica en el edge, GitHub Pages deja de ser una solución completa y necesita servicios adicionales.
La situación de Cloudflare Pages en 2026
Cloudflare Pages sigue funcionando y conserva documentación, límites y funciones propias. Al mismo tiempo, Cloudflare ofrece Workers Static Assets y una guía oficial para migrar desde Pages. No interpretamos eso como que Pages haya dejado de existir, pero sí como una señal para comparar Workers antes de iniciar un proyecto nuevo que dependa de lógica de servidor o de una arquitectura más amplia.
Para StackClaro, que ya está desplegado y funciona como sitio estático, no existe una razón inmediata para migrar. Si comenzáramos hoy una aplicación nueva dentro de Cloudflare, evaluaríamos Pages y Workers Static Assets antes de decidir.
Uso comercial y una futura web con anuncios
La documentación no formula una prohibición expresa contra cualquier blog editorial que muestre publicidad. Por eso no afirmamos que “GitHub Pages prohíba AdSense”. Sí creemos que una publicación cuya finalidad comercial vaya creciendo se encuentra en una zona menos natural para el producto y debería revisar sus condiciones antes de depender de él.
Cloudflare Pages no presenta en su documentación de límites una restricción equivalente. Para StackClaro, que prevé incorporar anuncios cuando exista suficiente contenido y tráfico, Cloudflare ofrece un encaje más claro como infraestructura de producción.
Además, GitHub advierte que Pages no debe utilizarse para transacciones sensibles. Ninguna de estas plataformas debería recibir directamente contraseñas o datos de tarjeta mediante simples páginas estáticas sin una arquitectura segura y servicios apropiados.
Cloudflare Pages o GitHub Pages: cuál elegir
| Escenario | Opción que valoraríamos primero | Motivo |
|---|---|---|
| Documentación de un proyecto open source | GitHub Pages | El sitio y el código permanecen juntos y el repositorio ya es público |
| Portfolio personal sencillo | GitHub Pages | Hosting estático suficiente, HTTPS y dominio propio |
| Demo técnica ligada a un repositorio | GitHub Pages | Una URL de proyecto encaja con el objetivo |
| Blog estático con dominio propio | Cloudflare Pages | Analítica, previews y configuración de producción más completa |
| Publicación que planea monetizarse | Cloudflare Pages | Mejor encaje comercial y assets estáticos sin límite de solicitudes |
| Equipo que revisa pull requests | Cloudflare Pages | Previews automáticas y protegidas contra indexación |
| Sitio que necesita cabeceras o muchas redirecciones | Cloudflare Pages | Archivos _headers y _redirects |
| Proyecto con funciones o servicios de edge | Cloudflare Pages o Workers | GitHub Pages solo sirve contenido estático |
| Repositorio privado con cuenta gratuita | Cloudflare Pages | GitHub Free exige un repositorio público para Pages |
Si también estás comparando plataformas de frontend, hemos probado el mismo proyecto en Vercel vs Cloudflare Pages para Astro y en Vercel vs Netlify.
Nuestra conclusión
GitHub Pages gana cuando publicar la web es una extensión sencilla del repositorio. Cloudflare Pages gana cuando la web necesita comportarse como un proyecto de producción.
GitHub Pages compiló y sirvió StackClaro correctamente. El build interno de Astro tardó 602 ms, HTTPS funcionó y la respuesta pública fue 200 OK. Para conseguirlo tuvimos que crear un repositorio público, añadir un workflow, configurar la ruta base, adaptar enlaces y proteger manualmente la copia frente a indexación.
Cloudflare Pages tiene límites de build más explícitos, pero aporta previews automáticas, analítica, cabeceras, redirecciones, integración con DNS y una vía hacia funciones. Para una documentación pública elegiríamos GitHub Pages sin demasiadas dudas. Para StackClaro mantenemos Cloudflare Pages.
Limitaciones de esta comparativa
- Probamos una web Astro estática pequeña, no una aplicación con alto consumo.
- Los builds no utilizaron la misma versión de Node ni idénticas condiciones de caché.
- No medimos latencia global, disponibilidad prolongada ni Core Web Vitals.
- No conectamos un dominio personalizado a GitHub Pages.
- No ejecutamos Pages Functions ni cargas sobre Workers.
- Los límites y condiciones pueden cambiar después de la fecha de revisión.
Preguntas frecuentes
¿Es gratis GitHub Pages?
Sí, en repositorios públicos con GitHub Free. Para publicar desde repositorios privados se necesita GitHub Pro, Team o Enterprise. Los runners estándar de GitHub Actions son gratuitos para repositorios públicos y para GitHub Pages.
¿Puedo usar un repositorio privado con GitHub Pages?
Sí, con determinados planes de pago. La web publicada seguirá siendo pública aunque el repositorio sea privado, salvo opciones de publicación privada disponibles en GitHub Enterprise.
¿GitHub Pages admite dominio propio y HTTPS?
Sí. Admite dominios raíz y subdominios, y permite aplicar HTTPS. GitHub recomienda verificar el dominio antes de conectarlo para reducir el riesgo de apropiación.
¿Cloudflare Pages tiene tráfico ilimitado?
Las solicitudes a assets estáticos son gratuitas e ilimitadas cuando no invocan Functions. Esto no elimina otros límites: Free permite 500 builds mensuales, 20.000 archivos por sitio y 25 MiB por asset, entre otras cuotas.
¿Cuál es mejor para Astro?
Ambos publicaron correctamente nuestro Astro estático. GitHub Pages requiere prestar atención a site, base y enlaces cuando se utiliza una URL de proyecto. Cloudflare Pages resultó más directo para nuestro sitio de producción.
¿GitHub Pages incluye previews por pull request?
No ofrece un equivalente automático a las URLs de preview de Cloudflare Pages en su flujo estándar. Se pueden construir automatizaciones adicionales con GitHub Actions, pero requieren trabajo propio.
¿Puedo montar una web con anuncios en GitHub Pages?
GitHub no publica una prohibición específica contra todo blog con anuncios, pero sí establece que Pages no debe utilizarse como alojamiento gratuito para operar un negocio online, comercio electrónico o SaaS comercial. Si la finalidad comercial es central, revisaríamos las condiciones y elegiríamos una plataforma orientada a producción.
Fuentes oficiales consultadas
- GitHub: qué es GitHub Pages y disponibilidad por plan
- GitHub: límites y condiciones de uso de Pages
- GitHub: dominios personalizados en Pages
- GitHub: HTTPS y visibilidad de Pages
- GitHub: facturación y uso gratuito de Actions
- Astro: despliegue oficial en GitHub Pages
- Cloudflare: límites de Pages
- Cloudflare: precios de Functions y assets estáticos
- Cloudflare: preview deployments
- Cloudflare: Web Analytics en Pages
- Cloudflare: migración de Pages a Workers Static Assets