Mejores generadores de sitios estáticos 2026: Astro a Hugo

Para la mayoría de los nuevos sitios de marketing y blogs en 2026, Astro es la opción por defecto: orientado al contenido, cero JavaScript salvo que lo actives, y adapters para cualquier host. Elige Next.js static export cuando el equipo ya ha invertido en React y puede necesitar funciones de servidor más adelante, y Hugo cuando la velocidad bruta de build en miles de páginas importa más que un ecosistema JavaScript. Jekyll sigue siendo válido para sitios pequeños en GitHub Pages, y Gatsby no debería usarse para nada nuevo.

Qué cambió en los generadores de sitios estáticos desde la era Jekyll vs Hugo vs Gatsby

La comparación original a tres bandas asumía un trade-off: builds rápidos con un lenguaje de plantillas rígido (Hugo, Jekyll), o un modelo moderno de componentes pagado con builds lentos y JavaScript pesado en el cliente (Gatsby). Ese trade-off ya no se sostiene.

Tres cosas movieron el mercado:

• Arquitectura de islands. Astro popularizó renderizar la página como HTML estático e hidratar solo los componentes que necesitan JavaScript. Una página de marketing sale con cero JS por defecto; el formulario de newsletter o el toggle de precios se hidrata por su cuenta. Esto eliminó el principal coste de Gatsby sin renunciar a componentes React, Vue, Svelte o Solid.
• Vite como toolchain compartida. Astro, VitePress, Docusaurus (en sus versiones recientes) y la mayor parte del mundo Vue y Svelte se construyen sobre Vite. El arranque del dev server pasó de decenas de segundos a bastante menos de un segundo, y los plugins sirven entre herramientas. Consulta Vite vs Webpack vs Parcel para el lado de las herramientas de build de este cambio.
• Frameworks full-stack que también exportan estático. Next.js, Nuxt y SvelteKit permiten prerenderizar todo a archivos planos. Un equipo puede empezar estático y activar el renderizado en servidor para una ruta más adelante sin cambiar de framework.

El resultado es que "generador de sitios estáticos" describe hoy más un modo de salida que una categoría de herramienta. La pregunta ya no es "qué SSG" sino "qué modelo de contenido y qué estrategia de hidratación", con el alojamiento en CDN como constante. El post sobre arquitectura Jamstack cubre el lado del alojamiento y las APIs con más profundidad.

Tabla comparativa de generadores de sitios estáticos (2026)

	Astro	Next.js (static export)	Hugo	Eleventy	Jekyll	Gatsby	Docusaurus	VitePress
Lenguaje / runtime	TypeScript, Node (Vite)	TypeScript, Node	Go, binario único	JavaScript, Node	Ruby	JavaScript, Node (webpack)	TypeScript, Node, React	TypeScript, Node (Vite), Vue
Velocidad de build (orden de magnitud)	Decenas de segundos para cientos de páginas; crece con el trabajo de imágenes	Decenas de segundos a minutos; memoiza los data loaders	Segundos para miles de páginas	Segundos a un minuto para miles de páginas	Segundos a minutos; se ralentiza con plugins	Minutos; necesita builds incrementales	Decenas de segundos a minutos	Segundos a decenas de segundos
Modelo de contenido	Markdown/MDX con content collections tipadas; cualquier CMS vía loaders	Lo que programes; Markdown vía librerías, CMS vía fetch	Markdown, front matter, archivos de datos, taxonomías	Markdown, Nunjucks/Liquid, datos globales, cualquier fuente de datos JS	Markdown, Liquid, collections	Capa de datos GraphQL sobre source plugins	Docs en Markdown/MDX, blog, versionado	Markdown con Vue dentro del Markdown
Islands / hidratación parcial	Sí, nativo (directivas client:*)	Sin islands; React Server Components reducen el JS en cliente	Ninguna (sin JS por defecto)	Ninguna (sin JS por defecto)	Ninguna	No, hidratación completa	No, hidratación completa (React)	Hidratación Vue por página
i18n	Enrutado, fallbacks y content collections por locale integrados	No soportado por el enrutado del static export; a mano con segmento [locale] y una librería	Integrado, maduro, árboles de contenido por idioma	Plugin (@11ty/eleventy-i18n) más tu propia estructura	Plugin (jekyll-polyglot), limitado	Plugins, irregular	Integrado, con docs traducidas por versión	Integrado, por configuración
Manejo de imágenes	<Image> y <Picture> integrados, optimización en build	next/image exige unoptimized: true en export; usa un loader o preprocesa	Procesamiento de imágenes integrado en plantillas	Plugin (@11ty/eleventy-img), muy capaz	Plugins, flojo	Plugin (gatsby-plugin-image), bueno pero lento	Manual, o plugin	Manual; pipeline de assets de Vite
Salud del ecosistema	Crece rápido, releases frecuentes	Muy grande; el modo export es un subconjunto	Estable, maduro, ritmo de funciones más lento	Sano, core team pequeño, buen conjunto de plugins	Mantenido, poca actividad	Modo mantenimiento tras la adquisición por Netlify	Activo, respaldado por Meta	Activo, mantenido por el equipo de Vue
Mejor encaje	Sitios de marketing, blogs, sitios de contenido con algo de interactividad	Equipos React; sitios que pueden crecer hasta ser apps	Grandes volúmenes de contenido, docs, sitios multilingües, CI sin Node	Blogs y sitios donde quieres control total y mínima magia	Sitios pequeños en GitHub Pages	Solo sitios legacy	Docs de producto y API, versionadas	Docs de librerías y herramientas internas

Las cifras de build son órdenes de magnitud. Mide con tu propio contenido antes de decidir; el procesamiento de imágenes y la obtención de datos dominan el tiempo de build mucho más que el motor de plantillas del generador.

Astro: el estándar orientado al contenido

Astro renderiza componentes .astro a HTML en build y elimina todo el JavaScript salvo que un componente lleve una directiva client:load, client:idle o client:visible. Puedes colocar componentes React, Vue, Svelte, Solid o Preact uno junto a otro, lo que lo convierte en la opción de menor riesgo cuando el equipo tiene habilidades de front-end mixtas.

Las content collections dan a Markdown y MDX un esquema tipado:

// src/content.config.ts
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  loader: glob({ pattern: '**/*.md', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),
    date: z.date(),
    tags: z.array(z.string()).default([]),
  }),
});

export const collections = { blog };

Un campo ausente rompe el build en lugar de producir una página en blanco. Los loaders también extraen de un CMS headless o de una API con la misma interfaz, así que pasar de Markdown local a un CMS no toca tus plantillas. Consulta CMS headless vs tradicional para saber cómo tomar esa decisión.

Donde Astro se queda corto: los sitios muy grandes (decenas de miles de páginas) construyen más lento que Hugo, y si necesitas un shell de aplicación real, con enrutado en cliente en todas partes, un framework completo encaja mejor. Astro también soporta renderizado en servidor mediante adapters, así que la vía de escape existe.

Next.js static export: para equipos React que pueden necesitar más después

Next.js con output: 'export' en next.config escribe HTML, CSS y JS planos en una carpeta de salida que cualquier CDN puede servir.

Lo importante es lo que el static export desactiva: middleware, API routes, server actions, Incremental Static Regeneration, revalidación bajo demanda, optimización de imágenes (define images.unoptimized: true) y el enrutado i18n integrado. Toda ruta dinámica necesita generateStaticParams. Si dependes de cualquiera de ellos, ya no estás construyendo un sitio estático y deberías alojar en un runtime Node o edge.

Dos reglas prácticas de ejecutar Next.js export con unos cientos de páginas:

• Memoiza los data loaders. generateStaticParams, generateMetadata y el componente de página llaman a tu loader de contenido para cada página. Sin caché, unos cientos de páginas pueden disparar decenas de miles de lecturas de archivo y convertir un build de 30 segundos en varios minutos.
• Activa trailingSlash: true y enlaza con la barra. Los hosts estáticos sirven /about/index.html; un enlace a /about produce un redirect que los crawlers indexan en lugar de la página. Esto importa para Core Web Vitals y SEO técnico.

Elige Next.js export cuando compartes componentes con una aplicación React, cuando la memoria muscular del equipo es React, o cuando quieres un camino creíble hacia el renderizado en servidor. Elige Astro cuando el sitio es contenido y la dependencia de React no te aporta nada.

Hugo y Eleventy: builds sin JavaScript que escalan

Hugo es un binario único en Go. Instálalo, ejecuta hugo, y miles de páginas Markdown se convierten en HTML en segundos. No hay node_modules, así que el CI es una descarga y un único comando. El soporte multilingüe está integrado en el modelo de contenido (un árbol de directorios por idioma, o un sufijo de idioma por archivo), las taxonomías son nativas y el procesamiento de imágenes corre en las plantillas. Las plantillas de Go son el principal coste de aprendizaje: escuetas, ajenas a los desarrolladores JavaScript y desagradables de depurar. Hugo es la mejor opción cuando el volumen de contenido es grande, el equipo no quiere una toolchain JavaScript, o necesitas enrutado multilingüe sin plugins.

Eleventy (11ty) adopta la postura opuesta: núcleo mínimo, configuración en JavaScript y el lenguaje de plantillas que elijas (Nunjucks, Liquid, WebC, JS plano). No tiene opinión sobre el JavaScript en cliente, lo que significa que la salida por defecto es cero JS. Los datos pueden venir de cualquier lugar al que llegue una función JavaScript. El plugin de imágenes es de los mejores de la categoría. Eleventy es la elección correcta cuando quieres la filosofía de salida de Hugo con un ecosistema JavaScript y control total sobre cada paso. El trade-off: sin enrutado i18n integrado ni esquema de contenido tipado.

Un build mínimo con Eleventy:

npm install @11ty/eleventy
npx @11ty/eleventy --serve

Jekyll y Gatsby: qué hacer con ellos en 2026

Jekyll sigue publicándose, sigue moviendo GitHub Pages y sigue funcionando para un sitio personal o una página de proyecto pequeña con un puñado de archivos Markdown. Sus problemas son prácticos: la toolchain Ruby diverge entre máquinas, hay una allowlist de plugins en GitHub Pages, los builds se ralentizan con muchos plugins y el conjunto de temas activos es mucho menor. Elige Jekyll solo cuando el alojamiento sin configuración de GitHub Pages sea el punto central. En caso contrario, empieza en Eleventy, que acepta plantillas Liquid y front matter al estilo Jekyll y hace la transición suave.

Gatsby fue la primera herramienta en combinar React, una capa de datos GraphQL y optimización de imágenes en un único paquete, y mereció su popularidad hacia 2019. Luego pasaron dos cosas. React se movió a Server Components y a un modelo de "menos JavaScript en cliente" que la arquitectura de hidratación completa de Gatsby no podía adoptar sin una reescritura. Y tras la adquisición de Gatsby Inc. por Netlify, el framework pasó a una cadencia de mantenimiento: las correcciones salen, pero el ecosistema de source plugins, el producto de build en la nube y la documentación dejaron de seguir el ritmo. Un equipo que elige Gatsby hoy hereda un build basado en webpack, una capa GraphQL que pocos quieren mantener y tiempos de build largos sin los builds incrementales que solo el descontinuado Gatsby Cloud manejaba bien.

Docusaurus y VitePress: sitios de documentación

La documentación tiene requisitos que las herramientas de propósito general resuelven mal: docs versionadas, sidebars generadas desde el árbol de archivos, búsqueda, páginas de referencia de API y docs traducidas que siguen las versiones.

Docusaurus cubre todo eso de serie. Está basado en React, soporta MDX, incluye versionado e i18n como funciones centrales y tiene plugins para referencias OpenAPI y búsqueda. El coste es un build más pesado, hidratación completa en React y más configuración.

VitePress es más pequeño y rápido. Está basado en Vue, se construye sobre Vite y produce un sitio de docs limpio con sidebar, búsqueda y modo oscuro desde un único archivo de configuración. No hace versionado de forma nativa, así que encaja en documentación de librerías, docs internas de ingeniería y productos de una sola versión.

Astro Starlight es la tercera opción: un tema de docs sobre Astro con i18n, sidebars y búsqueda. Si el resto de tus sitios son Astro, Starlight evita ejecutar un segundo framework.

Migrar desde Jekyll o Gatsby

El contenido en Markdown con front matter es portable. El trabajo está en las URLs, las imágenes y las plantillas.

Desde Jekyll:

1. Exporta las carpetas _posts y _pages tal cual. Las claves del front matter (title, date, layout, permalink) mapean directamente a content collections de Astro o a datos de Eleventy.
2. Reescribe las plantillas Liquid. Eleventy acepta Liquid de forma nativa, así que el tema puede migrar con cambios mínimos. Astro exige reescribir los layouts en .astro, que suele ser uno o dos días para un blog típico.
3. Conserva los permalinks. El patrón por defecto de Jekyll /:year/:month/:day/:title/ debe reproducirse o redirigirse. Genera un mapa de redirects (_redirects en Cloudflare Pages o Netlify) a partir del sitemap antiguo antes de cambiar el DNS.
4. Saca el procesamiento de imágenes de los plugins Ruby y llévalo al pipeline de imágenes del generador.

Desde Gatsby:

1. Elimina primero la capa GraphQL. Las llamadas useStaticQuery de Gatsby se convierten en imports directos o consultas a content collections. Esto es la mayor parte del trabajo.
2. Los componentes React se portan a Next.js sin cambios y a Astro con una directiva client:* donde necesiten hidratarse; la mayoría no la necesitará.
3. Sustituye gatsby-plugin-image por next/image (con unoptimized y un paso de preprocesado) o por el <Image> de Astro.
4. Sustituye los plugins gatsby-source-* por llamadas fetch en un loader. Contentful, Sanity y CMS similares tienen SDKs sencillos.
5. Audita gatsby-browser.js y gatsby-ssr.js en busca de wrappers globales; se convierten en un layout raíz.

En ambos casos, compara el HTML generado para una muestra de páginas y rastrea el nuevo build en busca de 404 antes del cambio. Mantén los redirects del sitemap antiguo al menos durante unos meses.

Checklist de decisión por tipo de proyecto

Usa la primera línea que coincida.

• Sitio de marketing con un CMS y algunos componentes interactivos. Astro. Usa islands para las partes interactivas y un loader de CMS para el contenido. Next.js export si el sitio comparte una librería de componentes con una app React.
• Documentación de producto o API, versionada. Docusaurus. Versión única, equipo afín a Vue o docs internas: VitePress. Ya en Astro: Starlight.
• Blog o sitio editorial con cientos de posts. Astro o Eleventy. Por encima de unas diez mil páginas, o sin toolchain JavaScript permitida en el CI: Hugo.
• Tienda de e-commerce. Un generador estático se encarga del catálogo y las landing pages; carrito, checkout y cuenta necesitan código en cliente o un servidor. Next.js (normalmente fuera del modo export) o Astro con rutas renderizadas en servidor. Puramente estático solo es viable con una API de commerce headless y carrito en cliente.
• Sitio multilingüe. Astro (enrutado i18n y fallbacks integrados) o Hugo (árboles de contenido por idioma maduros). Evita Next.js export salvo que estés preparado para construir el enrutado de locale por tu cuenta; el i18n del framework no funciona en modo export. El post sobre i18n y localización cubre las decisiones del lado del contenido.
• Sitio personal o de proyecto pequeño en GitHub Pages sin paso de build. Jekyll sigue siendo aceptable. Cualquier cosa con planes de crecimiento: Eleventy.
• Sitio Gatsby existente. Planifica la migración; no añadas funciones.

Recomendación

Adopta Astro por defecto para nuevos sitios de contenido. Envía el mínimo JavaScript, sus content collections detectan errores en build y te deja usar el framework de componentes que tu equipo ya conoce. Pasa a Next.js static export solo cuando React ya sea el estándar de la empresa y esperes que el sitio gane funciones de aplicación. Elige Hugo para conjuntos de contenido grandes o multilingües, donde un binario Go en el CI es una ventaja y no una restricción. Usa Docusaurus o VitePress para documentación en lugar de forzar una herramienta de propósito general. Mantén Jekyll para el caso pequeño en GitHub Pages y trata a Gatsby como origen de migración, no como destino. En Arvucore solemos recomendar Astro o Next.js export para sitios de marketing de clientes, y este sitio corre en Next.js static export exactamente por la razón de compartir React mencionada arriba.