SEO técnico para sitios headless y JAMstack

Un CMS headless separa la gestión del contenido (dónde se escribe y estructura) de su presentación (dónde y cómo se muestra), exponiendo el contenido a través de una API en vez de generar directamente el HTML final. JAMstack (JavaScript, APIs, Markup) es el patrón de arquitectura que suele acompañarlo: el sitio se pre-construye como archivos estáticos en tiempo de compilación (build time), a partir de esas APIs, y se sirve desde una red de distribución de contenido (CDN) en vez de generarse en cada petición desde un servidor de aplicación. La combinación cambia de forma sustancial qué problemas de SEO técnico son relevantes: algunos que dominan en un CMS monolítico tradicional (WordPress clásico, por ejemplo) prácticamente desaparecen, y aparecen otros específicos de esta arquitectura que un equipo acostumbrado al modelo monolítico no suele anticipar.

Lo que desaparece: la mayoría de problemas de renderizado en tiempo real

La guía de JavaScript y SEO de este sitio explica el desfase de dos fases con el que Google procesa contenido dependiente de JavaScript ejecutado en el navegador (client-side rendering). En un sitio JAMstack bien construido, ese problema deja de existir en la práctica: el HTML completo, con el contenido textual real ya presente, se genera en el momento de la compilación (build), no en el navegador del usuario ni en el momento de la visita del rastreador. Googlebot recibe el mismo HTML completo en la primera fase de rastreo que recibiría un usuario tras ejecutar JavaScript en un sitio client-side, así que el desfase de renderizado y la cola de recursos para ejecutar JavaScript, que sí son un problema real en aplicaciones de una sola página (SPA) sin pre-renderizado, simplemente no aplican aquí.

Lo que aparece: entornos de preview que se filtran al índice

La contrapartida de un pipeline de build automatizado es que la mayoría de plataformas JAMstack (Netlify, Vercel, Cloudflare Pages) generan automáticamente una URL de despliegue de vista previa (preview deployment) por cada rama o cada pull request, pensada para revisar cambios antes de fusionarlos a producción. Esas URLs de preview son sitios completos, públicamente accesibles por defecto en muchas configuraciones, con el mismo contenido que producción o una versión en curso de él. Si no se protegen explícitamente, un enlace compartido en una herramienta de gestión de proyecto, una notificación de Slack pública o simplemente un rastreador que descubre el dominio de la plataforma puede acabar indexando esos entornos de preview, generando contenido duplicado con la producción real y, en el peor caso, filtrando contenido todavía no publicado.

# Cabecera recomendada en cualquier despliegue de preview,
# aplicada a nivel de configuración de la plataforma (no del CMS):
X-Robots-Tag: noindex, nofollow

# Alternativa si la plataforma no permite cabeceras por entorno:
# proteger el dominio de preview con autenticación básica
# y excluirlo explícitamente del sitemap y del robots.txt de producción

Redirecciones: gestionadas en el edge, no en el CMS

En un CMS monolítico tradicional, las redirecciones suelen vivir dentro del propio sistema (un plugin, una tabla en base de datos) porque el mismo servidor que sirve el contenido gestiona también la lógica de redirección en cada petición. En una arquitectura JAMstack, el contenido servido es estático y se sirve desde el CDN, así que la lógica de redirección no puede depender del CMS (que ni siquiera está activo cuando se sirve la petición real): tiene que vivir en la capa de edge, como configuración propia de la plataforma de despliegue o de un proxy CDN.

# Netlify: fichero _redirects en la raíz del build
/producto-antiguo   /producto-nuevo   301
/blog/*             /articulos/:splat 301

# Vercel: bloque "redirects" en vercel.json
{
  "redirects": [
    { "source": "/producto-antiguo", "destination": "/producto-nuevo", "permanent": true }
  ]
}

El riesgo técnico habitual es que las redirecciones queden fuera del control editorial: si quien gestiona el contenido en el CMS headless da por hecho (por costumbre de plataformas anteriores) que cambiar la URL de una entrada crea automáticamente una redirección desde la antigua, y en realidad esa lógica vive en un fichero de configuración aparte que nadie actualiza en el mismo movimiento, cada cambio de URL en el CMS genera un 404 silencioso hasta que alguien añade la redirección manualmente en la capa de edge.

Canonicals rotos cuando el contenido viene de varias fuentes

Es habitual que un sitio JAMstack combine contenido de más de una fuente en tiempo de build: el CMS headless para páginas de contenido editorial, una API de comercio electrónico para productos, quizá un servicio de reservas o de eventos aparte. Cada fuente suele tener su propia noción de URL canónica o de slug, y si el proceso de build no unifica esa lógica de forma centralizada, es fácil que una misma pieza de contenido termine con dos rutas de acceso distintas (por ejemplo, accesible tanto desde /productos/silla-nordica como desde una ruta heredada de una integración antigua) sin una etiqueta canonical consistente que declare cuál es la de referencia, porque el componente que genera esa etiqueta se construyó pensando solo en una de las dos fuentes.

El sitemap tiene que ser parte del pipeline de build, no una tarea aparte

En un CMS monolítico, el sitemap suele generarse dinámicamente en cada petición, consultando la base de datos en tiempo real, así que siempre refleja el estado actual del contenido. En JAMstack, si el sitemap se genera como un paso manual o desconectado del proceso de build, puede quedarse desactualizado en cuanto se publica contenido nuevo sin volver a ejecutar ese paso. La solución correcta es integrar la generación del sitemap como parte del propio script de build, para que se regenere automáticamente cada vez que se compila el sitio a partir del contenido más reciente de todas las fuentes.

// Ejemplo de integración en el script de build (Node.js)
// se ejecuta como parte del mismo comando que genera el sitio estático
async function build() {
  const paginas = await construirSitioEstatico();
  await generarSitemap(paginas, './dist/sitemap.xml');
  await generarRobotsTxt('./dist/robots.txt');
}

Regeneración incremental (ISR): frescura de contenido y prioridad de rastreo

Algunos frameworks JAMstack ofrecen regeneración estática incremental (ISR, Incremental Static Regeneration): en vez de reconstruir todo el sitio en cada cambio, regeneran solo las páginas afectadas, bajo demanda o en un intervalo definido, manteniendo la ventaja de servir HTML estático sin sacrificar frescura. Para SEO tiene una implicación técnica concreta: si el intervalo de regeneración es demasiado largo para contenido que cambia con frecuencia (precios, disponibilidad, noticias), Googlebot puede seguir viendo una versión desactualizada de la página durante ese intervalo, aunque el HTML sea, técnicamente, siempre estático y rápido de servir. Ajustar el intervalo de revalidación al ritmo real de cambio del contenido, en vez de dejarlo en un valor por defecto genérico, es lo que evita ese desfase.

Preguntas frecuentes