GitHub Pages sirve una web estática directamente desde un repositorio, sin contratar alojamiento y con HTTPS incluido. Publicar lleva diez minutos; lo que suele atascar viene después, cuando toca apuntar un dominio propio o cuando el sitio crece y aparecen límites que nadie había mirado. Aquí está el recorrido completo, con los registros DNS exactos y las cifras que documenta GitHub.
Del repositorio vacío a la web publicada
El nombre del repositorio decide la dirección. Si se llama tu-usuario.github.io, el sitio queda en la raíz de ese dominio. Con cualquier otro nombre, la web cuelga de tu-usuario.github.io/nombre-del-repo/, y eso hay que tenerlo en cuenta al escribir las rutas de CSS e imágenes.
- Crea el repositorio y sube los archivos, desde la interfaz web con Add file → Upload files o clonando y empujando desde la terminal.
- Entra en Settings → Pages, en la barra lateral izquierda.
- En Build and deployment, elige el origen: una rama o un flujo de GitHub Actions.
- Si eliges rama, indica cuál (normalmente
main) y si publicas desde la raíz o desde la carpeta/docs.
git clone https://github.com/tu-usuario/tu-repositorio.git
cd tu-repositorio
# copia aquí tus archivos
git add .
git commit -m "Publicar sitio web"
git push origin mainEl primer despliegue tarda un par de minutos. A partir de ahí, cada push a la rama publicada vuelve a desplegar solo.
Rama o GitHub Actions: la decisión que condiciona el resto
Publicar desde una rama es lo más simple: lo que hay en esa carpeta es lo que se sirve. Vale para HTML escrito a mano y para Jekyll, que GitHub compila por su cuenta.
El flujo de GitHub Actions hace falta en cuanto el sitio se genera con otra herramienta (Astro, Hugo, Eleventy, un empaquetador de JavaScript) porque permite ejecutar la compilación antes de publicar. Tiene otra ventaja que casi nunca se menciona: el límite de compilaciones por hora del sistema clásico no se aplica a los sitios construidos con un flujo propio de Actions.
Dominio propio: los registros exactos
Esta es la parte donde más gente se queda a medias. Para un dominio raíz, del tipo ejemplo.com, hay que crear cuatro registros A en el proveedor de DNS apuntando a las direcciones de GitHub:
A @ 185.199.108.153
A @ 185.199.109.153
A @ 185.199.110.153
A @ 185.199.111.153Y, para servir también por IPv6, los cuatro registros AAAA equivalentes:
AAAA @ 2606:50c0:8000::153
AAAA @ 2606:50c0:8001::153
AAAA @ 2606:50c0:8002::153
AAAA @ 2606:50c0:8003::153Para el subdominio www no se usan direcciones IP sino un CNAME que apunte a tu-usuario.github.io. Al guardar el dominio en los ajustes de Pages, GitHub añade un archivo CNAME en la raíz de la rama publicada; si borras ese archivo, el dominio deja de funcionar.
La casilla Enforce HTTPS es el último paso, y conviene saber que puede tardar hasta 24 horas en estar disponible mientras se emite el certificado. Un aviso de la propia documentación: apuntar el subdominio personalizado al dominio raíz da problemas justo con esa opción.
Los límites que conviene mirar antes
- Repositorio de origen: límite recomendado de 1 GB.
- Sitio publicado: no puede superar 1 GB.
- Ancho de banda: límite blando de 100 GB al mes.
- Compilaciones: límite blando de 10 por hora, que no se aplica si publicas con un flujo propio de GitHub Actions.
- Despliegue: con un tiempo máximo de 10 minutos.
Que dos de ellos sean blandos significa que GitHub no corta el servicio de golpe, pero sí puede ponerse en contacto si se superan de forma sostenida. Para un portafolio o una documentación no son cifras que preocupen; para un sitio con vídeo o descargas pesadas, sí.
Sobre el coste, el matiz está en la visibilidad del repositorio: Pages funciona en repositorios públicos con las cuentas gratuitas, mientras que publicar desde un repositorio privado requiere GitHub Pro, Team o Enterprise.
Jekyll y los generadores modernos
Jekyll viene integrado y compila solo: basta un _config.yml en la raíz y contenido en Markdown para tener plantillas sin escribir HTML a mano. Es la vía más corta si el objetivo es un blog personal o una documentación con buscador.
Para cualquier otro generador la ruta es el flujo de Actions: compilar en el flujo y subir el resultado como artefacto de Pages. Cambia poco en esfuerzo y abre la puerta a todo el ecosistema actual.
Cuándo se queda corto
Sin base de datos ni código en servidor, hay cosas que no se pueden hacer: un formulario que guarde lo que recibe, un área privada, un catálogo que cambie a diario o un blog con varios autores editando desde un panel. Existen apaños con servicios externos para los formularios, pero cuando esas necesidades son el núcleo del proyecto y no la excepción, el sitio estático deja de compensar.
En ese punto toca valorar un gestor de contenidos, repasando antes los requisitos básicos para que un proyecto web aguante, o una arquitectura desacoplada si el equipo necesita separar contenido y presentación, que está en headless WordPress: ventajas reales para SEO, UX y escalabilidad.
Preguntas frecuentes
¿Qué registros DNS necesito para usar mi dominio?
Para el dominio raíz, cuatro registros A a 185.199.108.153, 185.199.109.153, 185.199.110.153 y 185.199.111.153, más los cuatro AAAA de IPv6 si quieres servirlo también por ahí. Para el subdominio www, un CNAME apuntando a tu-usuario.github.io.
¿Cuánto puede pesar un sitio en GitHub Pages?
El sitio publicado no puede superar 1 GB y el repositorio de origen tiene un límite recomendado de 1 GB. El ancho de banda tiene un tope blando de 100 GB al mes.
¿Por qué no me aparece la opción de forzar HTTPS?
Porque el certificado tarda en emitirse: GitHub indica que la casilla puede tardar hasta 24 horas en estar disponible después de configurar el dominio.
¿Puedo publicar desde un repositorio privado?
Sí, pero no con una cuenta gratuita. Los repositorios públicos funcionan con GitHub Free, mientras que publicar desde uno privado requiere GitHub Pro, Team o Enterprise.
¿Rama o GitHub Actions?
Rama si publicas HTML o Jekyll, que GitHub compila solo. Actions si usas otro generador que necesite un paso de compilación; además, el límite de diez compilaciones por hora no se aplica a los sitios construidos con un flujo propio.
¿Sirve para un blog con varios autores?
No de forma nativa. Sin base de datos ni panel de administración, cada autor tendría que editar archivos en el repositorio. Para ese caso compensa más un gestor de contenidos.
Fuentes
- GitHub Docs, GitHub Pages limits
- GitHub Docs, Managing a custom domain for your GitHub Pages site
- GitHub Docs, About GitHub Pages
