Glosario Generación estática (SSG)
En la generación estática el HTML de cada página se crea una sola vez, al compilar el proyecto, y se guarda como archivo. Cuando alguien la pide, el servidor sólo entrega ese archivo: no hay nada que calcular en el momento.
Lo más rápido y lo más robusto que se puede servir, con una condición: el contenido sólo cambia cuando algo vuelve a compilar.
Al compilar, un programa recorre el contenido —archivos, un CMS, una base de datos— y escribe un archivo HTML terminado para cada dirección. Lo que sale es una carpeta llena de archivos.
Esos archivos no necesitan servidor de aplicaciones. Pueden estar en un servidor web sencillo o directamente en un CDN, repartidos geográficamente y cerca de quien visita.
El rastreador recibe el contenido completo en la primera respuesta. No hay cola de renderizado, ni JavaScript que pueda fallar, ni petición de datos que se quede vacía en el momento equivocado.
A eso se suma el tiempo de respuesta. Un archivo terminado servido desde un CDN llega en pocos milisegundos: ayuda al LCP y abarata el rastreo, porque cada petición cuesta menos.
Lo que está compilado permanece así hasta que algo vuelva a compilar. Si cambia un precio, un stock o un horario, la página no se entera hasta que se ejecute una compilación.
Con unos cientos de páginas da igual: compilar lleva segundos. Con decenas de miles se convierte en un problema de cálculo: una compilación completa puede tardar de minutos a horas, y eso para un cambio en una sola página.
Hay dos respuestas. La compilación incremental renueva sólo lo que cambió. La revalidación posterior sirve la versión antigua y reconstruye esa página en segundo plano: la siguiente petición recibe la nueva.
Para los buscadores ambos son equivalentes: el contenido está en la primera respuesta. La elección se decide por otras dos preguntas.
¿Con qué frecuencia cambia el contenido? Una entrada de glosario, rara vez; un stock, constantemente. ¿Depende la página de quien la mira? Precios por país, un carrito, una sesión iniciada: eso no lo puede expresar un archivo.
Una obra de consulta, un blog o una documentación son los casos claros de SSG. Un carrito es el caso claro de SSR. En medio se mezcla, página a página.
Tres situaciones lo desaconsejan. Muchísimas páginas que cambian a menudo: el tiempo de compilación se vuelve el cuello de botella y, sin compilación incremental, cada corrección espera a la siguiente pasada completa.
El contenido distinto para cada persona no se puede producir por adelantado. Los ciclos de actualización muy cortos, como los precios en vivo, necesitan otra vía.
También aquí: no es una decisión para todo el proyecto. El catálogo puede ser estático y el carrito renderizarse en el servidor, dentro de la misma aplicación.
Una auditoría técnica revisa esto y el resto en un solo paso.
Solicitar auditoríaPara el rastreador son equivalentes: en ambos el contenido está en la primera respuesta. La ventaja del SSG es de velocidad y robustez, no de indexación. Quien elige entre los dos decide sobre frescura y coste, no sobre SEO.
Para una parte, sí. Fichas de producto, categorías y contenidos editoriales se prestan bien; el carrito, el precio en vivo y la sesión iniciada, no. Lo habitual es un sitio mixto, y esa mezcla es la norma, no una excepción.
El límite práctico no es el número de páginas sino el tiempo de compilación. Miles no plantean problema; a partir de decenas de miles conviene mirar si la herramienta compila de forma incremental, porque si no cada cambio pequeño arrastra una pasada completa.
En el resultado, poca: en ambos casos hay HTML terminado antes de la petición. La diferencia está en el propósito. El SSG es la forma de construir todo el sitio; el prerendering suele ser un añadido a una aplicación que, por lo demás, se renderiza en el navegador.
Sí. El HTML llega terminado y el JavaScript añade después lo que haga falta: un buscador, un filtro, un formulario. Lo importante para el rastreador es que el contenido no dependa de que ese código se ejecute.