Generadores de sitios estáticos

TL;DR — Un generador de sitios estáticos compila todo el sitio en archivos HTML planos por adelantado. Así, cuando Google aparece, el contenido ya está en la página: no hay que esperar a que se ejecute JavaScript. Es la configuración más sencilla posible para el SEO. La pega: el sitio solo se actualiza cuando se vuelve a compilar.

Qué es un generador de sitios estáticos

La mayor parte de los problemas de SEO con JavaScript se reducen a una pregunta: ¿el contenido está realmente en la página cuando un rastreador la solicita, o solo aparece después de que se ejecuten los scripts? Un generador de sitios estáticos (SSG) esquiva esa pregunta por completo.

Un SSG toma el contenido (normalmente escrito en Markdown) y las plantillas y —en el equipo local o en un servidor de compilación— convierte cada página en un archivo HTML terminado antes de que nadie la visite. Después se suben esos archivos HTML planos a un alojamiento. Cuando Google, Bing o un lector solicitan una página, reciben HTML completo al primer intento. Evidence for this claim A static site generator builds source content and templates into static files before requests are served. Scope: Hugo as a representative static site generator. Confidence: high · Verified: 2026-07-14 Hugo documentation

Compárese con una aplicación JavaScript típica, en la que el servidor envía un armazón casi vacío y el navegador construye la página después. Con un SSG no hay nada que construir en el navegador: ya está hecho.

Por qué eso es excelente para el SEO

• El contenido está en el HTML sin procesar. No hace falta que ningún paso de renderizado tenga éxito para que Google vea el texto y los enlaces.
• Es rápido. Los archivos HTML planos cargan rápido, lo que ayuda a las Core Web Vitals (Métricas web esenciales).
• Hay menos cosas que se puedan romper. Menos piezas móviles significan menos formas de que el contenido desaparezca de la búsqueda.

Los más populares

Hay seis de los que más se habla: Hugo, Jekyll, Eleventy, Hexo, Gatsby y Astro. Todos producen HTML estático; se diferencian en el lenguaje en el que están construidos y en cuánto JavaScript adicional (si es que envían alguno) mandan al navegador. Cada uno tiene su propio análisis en profundidad enlazado al final de esta página.

Lo único que hay que vigilar

Un sitio estático es una instantánea. Muestra lo que fuera cierto la última vez que se compiló. Si se cambia un precio, se corrige una errata o se publica un artículo y se olvida recompilar y volver a desplegar, los motores de búsqueda siguen viendo la versión antigua. Así que la disciplina principal con un SSG es asegurarse de que los cambios disparen una compilación nueva. Evidence for this claim Changes to a statically generated site require a new build and deployment before the generated output changes. Scope: Astro static builds as a representative SSG workflow. Confidence: high · Verified: 2026-07-14 Astro: Deploy your site

La pestaña Advanced ofrece la versión técnica: diferencias entre los SSG, los frameworks del lado del cliente y los metaframeworks; una comparación de los seis generadores; y un análisis detallado de la frescura de compilación.

TL;DR — Un SSG prerrenderiza cada ruta a HTML estático en tiempo de compilación, de modo que el contenido existe en la respuesta antes de la primera petición de un rastreador: sin Web Rendering Service, sin cola de renderizado, sin el retraso de la «segunda oleada» (Wave 2). Es la mayor ventaja de indexabilidad que se le puede dar a un sitio. Los SSG se diferencian de los frameworks de CSR (que construyen la página en el navegador) y de los metaframeworks (que pueden hacer SSR por petición). Los seis de este clúster —Hugo, Jekyll, Eleventy, Hexo, Gatsby, Astro— entregan HTML estático; varían en lenguaje, carga de JS y herramientas integradas de sitemap e imágenes. El verdadero modo de fallo no es el renderizado, sino la frescura de la compilación: un sitio estático solo está tan actualizado como su última compilación, así que el contenido modificado que no dispara una recompilación sirve en silencio HTML obsoleto a los motores de búsqueda. Este sitio lo tengo montado sobre Astro exactamente por este conjunto de compensaciones.

Qué significa realmente «estático»

Un generador de sitios estáticos pasa el contenido y las plantillas por un paso de compilación y emite una carpeta de HTML, CSS y recursos terminados. La parte crucial para el SEO es cuándo se produce el HTML: en tiempo de compilación, una vez, para todo el mundo, no por petición ni en el navegador. La guía de JavaScript de Google describe el rastreo, el renderizado y la indexación como etapas de procesamiento distintas. Un SSG saca el renderizado del lado del cliente de la ruta crítica para el contenido que genera, porque el HTML ya está completo. Evidence for this claim Google processes JavaScript through crawling, rendering, and indexing, while pre-rendered HTML is present before client execution. Scope: Google Search JavaScript processing; indexing is not guaranteed. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

Por eso los sitios estáticos son la arquitectura más segura posible para conseguir la indexación. El contenido está en el primer byte de la respuesta. No hay brecha de paridad entre el HTML sin procesar y el renderizado, ni dependencia de que el renderizador funcione, ni peculiaridades del Chrome sin estado que haya que tener en cuenta al diseñar.

SSG frente a renderizado del lado del cliente frente a metaframeworks

Tres arquitecturas, tres momentos distintos en los que el HTML pasa a existir:

• Generación de sitios estáticos (SSG). El HTML se compila una vez, en tiempo de compilación, antes de cualquier petición. Se sirve como archivos planos (a menudo desde una CDN). El contenido está en el HTML sin procesar. Es el caso de Hugo, Jekyll, Eleventy y Hexo, y también de Gatsby y Astro en su modo estático por defecto.
• Renderizado del lado del cliente (CSR). El servidor envía un armazón mínimo; JavaScript construye la página en el navegador en tiempo de petición o ejecución. El contenido depende de que el renderizado funcione. Es el caso de una SPA de React o Vue con CSR por defecto, la configuración más arriesgada para el SEO (véase SEO en JavaScript).
• Metaframeworks (SSR / híbrido). Frameworks como Next.js, Nuxt y SvelteKit pueden renderizar HTML por petición en el servidor (SSR), prerrenderizar algunas rutas (SSG) o mezclar ambas cosas. El contenido está en el HTML, pero se produce en tiempo de petición, lo que añade un costo de servidor y una latencia que no se tienen con un SSG puro.

La línea se difumina en los extremos: a veces se llama metaframeworks a Gatsby y Astro porque están basados en componentes y pueden hacer más que emitir archivos planos. Pero en su modo habitual son generadores estáticos, y así es como conviene tratarlos para el SEO. El modelo mental que importa: cuanto antes exista el HTML, menos cosas pueden salir mal antes de que un rastreador lo vea. El SSG es el más temprano.

Los seis generadores, comparados

Los seis producen HTML estático indexable. Así se diferencian en los ejes que de verdad afectan a una decisión de SEO:

Algunas cosas que conviene destacar de esa tabla:

• La carga de JS es el diferenciador relacionado con el SEO. Hugo, Jekyll, Eleventy y Hexo prácticamente no envían JavaScript salvo que se añada. Gatsby rehidrata un bundle completo de React en el cliente: sigue siendo indexable (el HTML es estático), pero tiene un costo en Core Web Vitals que los demás no tienen. Astro se queda a medio camino con la arquitectura de islas: HTML estático por defecto y JavaScript solo para los componentes interactivos concretos (las «islas») que lo necesitan.
• La velocidad de compilación escala de forma distinta. Hugo (Go) es famoso por su rapidez y maneja decenas de miles de páginas sin problema. Los generadores basados en Node son más lentos a gran escala, y los tiempos de compilación de Gatsby han sido históricamente su mayor queja.
• Los sitemaps y la optimización de imágenes están resueltos casi en todas partes, pero Hugo y Astro son los que más ofrecen de serie, mientras que Jekyll, Eleventy y Hexo se apoyan en plugins (bien mantenidos).
• La cadencia de versiones de Gatsby se ha ralentizado de forma apreciable. El proyecto no está archivado y sigue publicando parches, pero, a fecha de julio de 2026, su repositorio de GitHub muestra solo un puñado de commits en los últimos 90 días y una versión menor desde febrero. Eso conviene sopesarlo frente a una opción con desarrollo más activo si hoy se está eligiendo un generador, además del costo de hidratación y CWV mencionado arriba.

Por qué construí esto sobre Astro

Construí este sitio —y patrickstox.com— con Astro, y el razonamiento sale directamente de esta página. Quería escribir en Markdown/MDX con componentes de verdad, pero no quería pagar el peaje de JavaScript en cada página solo por tenerlos. El comportamiento por defecto de Astro es cero JS del lado del cliente: las páginas que está leyendo se entregan como HTML estático, y el único JavaScript que se carga es el de las pocas piezas interactivas (como las pestañas de lentes y el cuestionario). Eso me da la indexabilidad de un SSG clásico y buenas Core Web Vitals, sin renunciar a una experiencia de autoría basada en componentes. Si necesitara una velocidad de compilación fulminante en un conjunto de contenido enorme y sin interactividad, Hugo sería la elección obvia; para una capa de datos en React, Gatsby. Para esto —un sitio con mucho contenido y unos pocos toques interactivos— Astro es la compensación correcta.

La única pega real: la frescura de la compilación

Todo lo anterior es la parte buena. Aquí está la pega que pilla a la gente.

Un sitio estático solo está tan actualizado como su última compilación. El HTML es una instantánea congelada en tiempo de compilación. Los cambios de precio, las correcciones, las publicaciones y las actualizaciones de títulos no llegan a los motores de búsqueda hasta que se recompila y se vuelve a desplegar. No hay un servidor en vivo que ensamble la página desde una base de datos en cada petición, así que no hay nada que recoja el cambio automáticamente. Evidence for this claim Static build output remains a snapshot until the project is rebuilt and redeployed. Scope: Astro static build workflow as a representative example. Confidence: high · Verified: 2026-07-14 Astro: Build and deploy

En la práctica, esto significa:

• Las ediciones de contenido deben disparar una compilación. Cuando el contenido se gestiona en un CMS headless o en Git, un webhook debe iniciar el despliegue al publicar. Un proceso de compilación exclusivamente manual es la forma en que se cuelan en el índice precios obsoletos y errores «fantasma» de página no encontrada.
• Los datos que cambian con frecuencia son incómodos. Inventario, precios, contadores en vivo: si cambian más rápido de lo que se recompila, la copia estática se queda atrás. Ahí es donde las compilaciones incrementales, las recompilaciones programadas o un enfoque híbrido (un metaframework con SSR/ISR para las rutas volátiles) se ganan su sitio.
• Las páginas sensibles al tiempo necesitan una cadencia. Si «las ofertas de hoy» se hornea en tiempo de compilación, la compilación tiene que ejecutarse al menos a diario, o la página miente.

Nada de esto es un impedimento insalvable: es una disciplina. La razón misma por la que los SSG son excelentes para el SEO (el HTML decidido de antemano) es la misma razón por la que hay que ser deliberado a la hora de volver a decidirlo cuando cambia el contenido.

Adónde ir después: el clúster de generadores de sitios estáticos

Este hub es el mapa. Cada generador de abajo tiene su propio análisis en profundidad: lenguaje, carga de JS, herramientas de sitemap e imágenes, las pegas de SEO específicas de cada framework y cómo mantener frescas las compilaciones:

• SEO para Hugo — impulsado por Go, sin JS, compilaciones vertiginosas; el sitemap autogenerado, el procesamiento de imágenes integrado y la gestión de conjuntos de contenido enormes.
• SEO para Jekyll — el SSG original y la opción por defecto de GitHub Pages; jekyll-seo-tag, jekyll-sitemap y la limitación de los plugins en GitHub Pages.
• SEO para Eleventy (11ty) — basado en JavaScript, salida sin JS; generación de sitemaps desde plantillas y eleventy-img para imágenes responsive.
• SEO para Hexo — el generador de blogs de Node; plugins de sitemap y feeds, JS del tema e higiene de permalinks y canónicas.
• SEO para Gatsby — generación estática basada en React; la compensación entre hidratación y CWV, gatsby-plugin-image, gatsby-plugin-sitemap y el abastecimiento de datos en tiempo de compilación.
• SEO para Astro — cero JS por defecto, arquitectura de islas, @astrojs/sitemap, astro:assets, View Transitions y el comportamiento de reserva de las Server Islands.

Todos los temas anteriores están anidados bajo este hub y también aparecen en la barra lateral.

Para el contexto más amplio —cómo renderiza Google el JavaScript, los modos de fallo de paridad e interacción y qué modo de renderizado elegir cuando sí se necesita JS— puede consultarse el hub principal de SEO en JavaScript.

Resumen con IA

Una versión condensada de la variante Advanced:

• Un SSG prerrenderiza cada página a HTML estático en tiempo de compilación: el contenido existe en la respuesta antes de la primera petición de un rastreador. Sin Web Rendering Service, sin cola de renderizado, sin el retraso de la «segunda oleada» (Wave 2). La arquitectura más segura para la indexabilidad.
• Tres arquitecturas según cuándo existe el HTML: SSG (en tiempo de compilación, la más segura), CSR (en el navegador, en tiempo de ejecución, la más arriesgada), metaframeworks/SSR (por petición en el servidor; el contenido está presente, pero con latencia y costo).
• Los seis generadores entregan HTML estático indexable. Se diferencian en lenguaje, carga de JS y herramientas integradas de sitemap e imágenes:
  • Hugo (Go) — cero JS, las compilaciones más rápidas, sitemap y procesamiento de imágenes integrados.
  • Jekyll (Ruby) — cero JS, opción por defecto de GitHub Pages, basado en plugins.
  • Eleventy (Node) — cero JS, flexible, basado en plugins.
  • Hexo (Node) — cero JS por defecto, orientado a blogs, basado en plugins.
  • Gatsby (React) — hidrata un bundle de React (costo en CWV), herramientas de imagen potentes, pero su cadencia de versiones se ha ralentizado de forma apreciable a mediados de 2026.
  • Astro (cualquier framework) — cero JS por defecto gracias a las islas, sitemap oficial y astro:assets.
• La carga de JS es el diferenciador relacionado con el SEO: Gatsby lleva un bundle de React; las islas de Astro envían JS solo donde hace falta; el resto son cero JS.
• Patrick construyó este sitio (y patrickstox.com) sobre Astro: componentes sin el peaje de JS, HTML estático y buenas Core Web Vitals.
• La única pega real es la frescura de la compilación: un sitio estático solo está tan actualizado como su última compilación. Las ediciones de contenido deben conectarse a un webhook de recompilación; también pueden usarse compilaciones incrementales o programadas, o una ruta híbrida SSR/ISR para los datos que cambian rápido.

Documentación oficial

Documentación de fuente primaria: de los motores de búsqueda y de cada generador.

Motores de búsqueda: renderizado y HTML estático

• Fundamentos de SEO para JavaScript — título oficial: “Understand the JavaScript SEO basics” (traducción) «Fundamentos de SEO para JavaScript»; explica las fases de rastreo → renderizado → indexación que una compilación estática permite saltarse para el contenido.
• Guía detallada sobre el funcionamiento de la Búsqueda de Google — título oficial: “In-Depth Guide to How Google Search Works” (traducción) «Guía detallada sobre el funcionamiento de la Búsqueda de Google»; muestra dónde encaja el renderizado y por qué el HTML prerrenderizado es el de menor riesgo.

Los generadores

• Hugo documentation — y la documentación de sitemap template e image processing.
• Jekyll docs — además de jekyll-seo-tag y jekyll-sitemap.
• Eleventy (11ty) docs — y eleventy-img.
• Hexo docs — y el plugin hexo-generator-sitemap.
• Gatsby docs — y gatsby-plugin-image y gatsby-plugin-sitemap.
• Astro docs — además de @astrojs/sitemap y astro:assets / images.

Citas de la fuente

Declaraciones oficiales de Google y de los equipos de los propios generadores, más una nota de mis propios textos.

Google — el renderizado es un paso aparte

• “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome.” (traducción) «Durante el rastreo, Google renderiza la página y ejecuta cualquier JavaScript que encuentre usando una versión reciente de Chrome.» — el paso que un SSG saca de la ruta crítica al entregar HTML terminado. Ir a la cita
• “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (traducción) «El renderizado es importante porque los sitios web a menudo dependen de JavaScript para llevar contenido a la página y, sin renderizado, Google podría no ver ese contenido.» — es decir, si el contenido ya está en el HTML estático, el renderizado no puede costarle visibilidad. Ir a la cita

Astro — estático por defecto

• “By default, Astro pages, routes, and API endpoints will be pre-rendered at build time as static pages. However, you can choose to render some or all of your routes on demand by a server when a route is requested.” (traducción) «De forma predeterminada, las páginas, rutas y endpoints de API de Astro se prerrenderizarán en tiempo de compilación como páginas estáticas. Sin embargo, puede optar por renderizar algunas de sus rutas, o todas, bajo demanda mediante un servidor cuando se solicite una ruta.» Ir a la cita

Hugo — velocidad

• Hugo se presenta a sí mismo como “the world’s fastest framework for building websites” (traducción) «el framework más rápido del mundo para crear sitios web»: la ventaja de velocidad de compilación que importa a gran escala de contenido. Fuente

Patrick Stox (trabajo propio — JavaScript SEO: A Definitive Guide)

• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (traducción) «Cualquier tipo de configuración de SSR, renderizado estático y prerrenderizado va a funcionar bien para los motores de búsqueda.» — la generación estática es el extremo de bajo riesgo de ese espectro.

Lista de comprobación de SEO para sitios estáticos

Un repaso rápido para confirmar que la configuración del SSG es apta para buscadores y se mantiene actualizada:

• El contenido importante está presente en View Source (el HTML sin procesar), no solo después de que se ejecute el JS: el sentido mismo de un SSG.
• Se genera un sitemap XML en cada compilación y se envía en Google Search Console y en Bing Webmaster Tools.
• Cada página tiene un <title> y una metadescripción únicos generados en tiempo de compilación (mediante el sistema de plantillas del generador o un plugin o integración de SEO).
• Las etiquetas canónicas están puestas y apuntan a las URL finales en vivo (no a localhost ni a un dominio de previsualización).
• Las imágenes se optimizan en tiempo de compilación (tamaños responsive, formatos modernos): se utilizan las herramientas integradas del generador o un plugin de imágenes.
• Ningún JavaScript del lado del cliente (el bundle de React de Gatsby, las islas de Astro, el JS del tema) está ocultando contenido principal detrás de una interacción.
• Los recursos JS y CSS no están bloqueados en robots.txt.
• Las ediciones de contenido disparan una recompilación y un nuevo despliegue: un webhook del CMS o de Git lanza el despliegue automáticamente.
• Las páginas sensibles al tiempo o que cambian con frecuencia tienen una cadencia de recompilación programada (o se sirven mediante SSR/ISR en lugar de estáticamente).
• Las URL antiguas de una compilación previa no quedan como archivos estáticos huérfanos: limpie el directorio de salida y gestione las eliminaciones para que las páginas borradas devuelvan 404 o 410.
• La compilación desplegada coincide con el contenido más reciente (se comprueba una página modificada recientemente en producción, no solo en local).

Generadores de sitios estáticos — hoja de referencia rápida

Los seis de un vistazo

Cuándo existe el HTML (y por qué importa)

Datos rápidos

• SSG = sin Web Rendering Service en la ruta crítica → sin retraso de «segunda oleada» (Wave 2) para el contenido.
• Gatsby hidrata un bundle de React (costo en CWV); Astro envía JS solo para las islas; Hugo, Jekyll, Eleventy y Hexo son cero JS por defecto.
• La cadencia de versiones de Gatsby se ha ralentizado a mediados de 2026: conviene revisar su actividad en GitHub antes de elegirlo para un proyecto nuevo.
• Hugo (Go) es el campeón de velocidad a gran escala.
• La única trampa: la frescura de la compilación; un sitio estático muestra su última compilación. Las ediciones de contenido deben conectarse a un webhook de recompilación.
• Datos que cambian rápido (precios, inventario) → compilaciones incrementales o programadas, o SSR/ISR híbrido.

¿Qué ruta de renderizado encaja?

El marco compilar → desplegar → verificar

• Compilar: enumere las rutas previstas y genere HTML, metadatos, canónicas y datos estructurados completos.
• Desplegar: el nuevo artefacto se publica de forma atómica para que el HTML, los recursos, los sitemaps y las redirecciones se mantengan sincronizados.
• Verificar: se comparan el HTML de origen y la respuesta de producción con la versión de contenido que disparó la compilación.

El HTML estático resuelve la dependencia del renderizado; no resuelve las compilaciones obsoletas, las rutas que faltan, los hooks de despliegue rotos ni los metadatos generados en el cliente que nunca llegan al HTML de origen.

Comprobar si el contenido clave existe en el HTML de origen

curl -sS https://example.com/page/ | grep -F 'Expected visible heading'

Para una lista de URL, la CI debe fallar cuando falte una ruta de producción o cuando no tenga título:

while IFS= read -r url; do html=$(curl -fsSL "$url") || { echo "FETCH FAIL $url"; continue; }; printf '%s' "$html" | grep -qi '<title>[^<]' || echo "TITLE FAIL $url"; done < urls.txt

Este fragmento puede ejecutarse en la consola de DevTools para comparar el título, la canónica y el encabezado de una página renderizada:

({title: document.title, canonical: document.querySelector('link[rel="canonical"]')?.href, h1: document.querySelector('h1')?.textContent.trim()});

Herramientas para la salida estática

• Raw vs. Rendered HTML Checker muestra si el contenido importante y las señales de head ya están presentes en el HTML inicial.
• HTTP Status Checker comprueba por lotes las rutas generadas, las redirecciones y las páginas ausentes.
• HTTP Header Checker inspecciona las cabeceras de caché y de despliegue a lo largo de las redirecciones.
• El registro de compilación del entorno y su manifiesto de despliegue son la fuente de verdad sobre qué rutas se generaron correctamente.

Demostrar que el despliegue estático funciona

Prueba del HTML de origen

Ejecución: se recuperan URL de producción representativas con curl o con Render Gap. Resultado esperado: el contenido principal, el título, la canónica y los enlaces aparecen en el HTML sin procesar. Interpretación del fallo: la ruta se renderiza en el cliente o la compilación omitió datos. Ventana de monitorización: inmediatamente después del despliegue. Disparador de reversión: plantillas importantes que entregan HTML de origen vacío o incompleto.

Prueba de frescura de la publicación

Ejecución: se publica un cambio de contenido controlado y se compara su marca de tiempo en el CMS, el registro de compilación, el artefacto de despliegue y el HTML en vivo. Resultado esperado: el cambio dispara una única compilación correcta y llega a producción. Interpretación del fallo: el webhook, la compilación, la caché o la cadena de despliegue están obsoletos. Ventana de monitorización: el SLA de publicación habitual. Disparador de reversión: producción mezcla HTML antiguo con metadatos o recursos nuevos.

Prueba de completitud de rutas

Ejecución: se comparan las URL preferidas previstas con las rutas generadas y desplegadas, y se verifican los códigos de estado por lotes. Resultado esperado: cada ruta prevista devuelve su código de estado planificado. Interpretación del fallo: el descubrimiento dinámico de rutas o la configuración de compilación omitió rutas. Ventana de monitorización: cada compilación. Disparador de reversión: páginas preferidas que dejan de encontrarse o que redirigen de forma inesperada.

Evaluación: generadores de sitios estáticos

Cinco preguntas sobre la ventaja SEO de los generadores de sitios estáticos y su principal riesgo operativo. Cada pregunta permite seleccionar una respuesta y comprobar el resultado.

Recursos recomendados

Mis textos relacionados

• JavaScript SEO: A Definitive Guide — renderizado, paridad del DOM y por qué la salida estática o prerrenderizada es el extremo de bajo riesgo del espectro.
• The Beginner’s Guide to Technical SEO — dónde encaja la arquitectura de renderizado en el panorama general.

Mis ponencias

• How Search Works (SlideShare) — mi recorrido por el rastreo, el renderizado, la indexación y el ranking. (Se aplica mi descargo de responsabilidad habitual: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas… no va a ser 100 % completa ni precisa».)

Del sector

• web.dev — Renderizado web — título oficial: “Rendering on the Web” (traducción) «Renderizado web»; es la explicación canónica del equipo de Chrome sobre SSG frente a SSR frente a CSR y las compensaciones entre ellos.
• Google Search Central — Fundamentos de SEO para JavaScript — título oficial: “JavaScript SEO basics” (traducción) «Fundamentos de SEO para JavaScript»; explica las fases de rastreo → renderizado → indexación que una compilación estática permite saltarse para el contenido.
• Jamstack — el movimiento arquitectónico (marcado prerrenderizado servido desde una CDN) del que los generadores de sitios estáticos son el motor, con un directorio de generadores.
• Astro — ¿Por qué Astro? — título oficial: “Why Astro?” (traducción) «¿Por qué Astro?»; ofrece la formulación más clara del modelo «HTML estático, cero JS por defecto, islas para la interactividad».
• Hugo — el generador basado en Go construido en torno a la velocidad de compilación a gran escala de contenido.
• Smashing Magazine — Generadores de sitios estáticos — título oficial: “Static site generator coverage” (traducción) «Generadores de sitios estáticos»; reúne artículos de profesionales sobre cómo elegir y usar SSG.

Registro de cambios