SEO en Hydrogen: SSR vs streaming para Shopify headless

Hydrogen es el framework de tiendas headless de Shopify. Está basado en React, incluye React Router, se ejecuta en Oxygen (la plataforma de workers en el edge de Shopify basada en aislamientos V8) y obtiene los datos de la Storefront API. También es una de las superficies más potentes y más fáciles de configurar mal en el SEO para eCommerce moderno. La decisión con más consecuencias en un proyecto con Hydrogen es cómo se renderiza la tienda: renderizado completo del lado del servidor (SSR), SSR con streaming o un híbrido que combina ambos. Esa decisión lo cambia todo en la forma en que Googlebot, Bingbot y la nueva generación de rastreadores de IA (GPTBot, ClaudeBot, PerplexityBot, Applebot-Extended) ven tus páginas de producto, de colección y de contenido.

Este artículo recorre la arquitectura y explica qué modo elegir, cuándo y por qué.

El proceso de renderizado de Hydrogen en 60 segundos

Hydrogen se distribuye como una app de React Router. Cada solicitud llega a un worker de Oxygen; el worker resuelve la ruta correspondiente, obtiene los datos de la Storefront API de Shopify (normalmente a través del endpoint de GraphQL) y devuelve HTML al navegador. El modo en que se produce ese HTML determina lo que reciben los rastreadores en el primer byte:

• El SSR completo espera a que se resuelvan todos los loaders de la ruta antes de enviar cualquier HTML. Los rastreadores reciben la página completamente poblada en la respuesta inicial.
• El SSR con streaming envía de inmediato la estructura base del documento y transmite los fragmentos que dependen de loaders más lentos a medida que se resuelven, usando límites de React Suspense.
• El renderizado solo en el cliente (a veces llamado CSR para las partes dinámicas) envía una estructura mínima e hidrata el resto en el navegador mediante JavaScript.

Hydrogen admite los tres, y los valores predeterminados del framework han cambiado a lo largo de su vida. En 2026, los valores predeterminados son sensatos, pero no son lo que importa. Lo que importa es lo que hacen realmente tus rutas específicas.

Por qué el SSR completo es la opción correcta por defecto para el comercio

Googlebot sí ejecuta JavaScript, pero con tres limitaciones que importan en un sitio de comercio:

1. Indexación en dos pasadas. El renderizador de Googlebot pone en cola la ejecución de JavaScript detrás del rastreo inicial del HTML. El retraso puede ser de horas o días. Los productos nuevos publicados en una tienda con Hydrogen que depende de datos renderizados en el cliente pueden tardar una semana en indexarse.
2. Límites de recursos. Las solicitudes fetch que se hacen durante el renderizado de la página están sujetas a límites de presupuesto. Una página que lanza media docena de llamadas a la Storefront API desde el navegador para mostrar el precio, la disponibilidad, el número de reseñas y los productos relacionados puede perder esas llamadas sin aviso.
3. Los rastreadores de IA no renderizan JS en absoluto. GPTBot, ClaudeBot y PerplexityBot no ejecutan JavaScript. Si el precio, la descripción o las especificaciones de tu página de producto se renderizan en el cliente, las superficies de IA que impulsan una parte cada vez mayor del descubrimiento de productos no los verán.

El SSR completo evita cada uno de esos problemas. También es más lento en llegar al primer byte que el streaming, a veces de forma considerable en rutas que obtienen en paralelo el producto, las recomendaciones, las reseñas y el inventario.

Cuándo el SSR con streaming es la respuesta correcta

El streaming es la respuesta correcta cuando la ruta tiene tanto contenido crítico como no crítico, y el contenido crítico se puede resolver rápido mientras que el no crítico no. El patrón se ve así:

// PDP route - pseudocode
export const loader = async ({ params, context }) => {
  // Critical: product, price, image, JSON-LD inputs
  const product = await context.storefront.query(PRODUCT_QUERY, { variables: { handle: params.handle }});
  return defer({
    product,
    // Non-critical: deferred. Streamed in when ready.
    recommendations: context.storefront.query(RECS_QUERY, ...),
    reviews: fetchReviews(product.id),
  });
};

En este patrón, el producto en sí (la parte que Googlebot y los rastreadores de IA necesitan indexar) está en la parte síncrona y esperada del loader. Las recomendaciones y las reseñas se difieren y se transmiten mediante límites <Suspense>. La respuesta HTML inicial contiene todo lo indexable; la página hidrata las piezas no críticas a medida que llegan.

Este es el patrón de streaming más seguro para el SEO. El error que debes evitar: diferir el precio, la disponibilidad o la descripción. Todo lo que pertenece al JSON-LD de Producto u Offer pertenece al loader síncrono.

Checklist de canónicas, hreflang y JSON-LD

En cada ruta de Hydrogen, valida lo siguiente:

• La etiqueta canónica se emite en el <head> renderizado con SSR, no se inyecta en el cliente después de la hidratación. Usa las exportaciones meta de Hydrogen en el módulo de la ruta para colocarla ahí de forma confiable.
• Grupos de hreflang para tiendas en varios mercados. Si usas Markets con Hydrogen, el loader de tu ruta necesita saber en qué configuración regional se resolvió la solicitud y emitir el conjunto completo de alternativas.
• JSON-LD de Producto para cada página de producto. nombre, image, description, sku, marca y un bloque offers completo. Inclúyelo en la respuesta SSR dentro de un <script type="application/ld+json">.
• JSON-LD de BreadcrumbList para las páginas de colección y de producto.
• JSON-LD de Organización en el layout raíz, una sola vez, con sameAs hacia cada perfil de la marca.

Renderizado en el edge, latencia geográfica y Core Web Vitals

Oxygen se ejecuta en el edge. Ese es justamente el punto. Una solicitud desde São Paulo llega a un worker de Oxygen en São Paulo o cerca, obtiene los datos de la Storefront API (que está distribuida por regiones) y devuelve HTML en decenas de milisegundos. Ese perfil de latencia es lo que hace viable el streaming: incluso la parte síncrona del loader se resuelve tan rápido que el tiempo hasta el primer byte se mantiene competitivo.

Pero el renderizado en el edge solo ayuda si la ruta realmente usa streaming o SSR. Una ruta de Hydrogen que envía una estructura vacía y se hidrata en el cliente no se beneficiará. Pasa la ruta por un verdadero simulador de rastreadores (no solo Lighthouse) y revisa qué contiene la respuesta antes de que se ejecute cualquier JavaScript.

Para entender mejor por qué importa el renderizado en el edge, consulta por qué los CWV dependen del renderizado en el edge en el comercio headless.

Hydrogen vs Remix vs el ecosistema headless en general

Hydrogen está hecho a la medida de Shopify e incluye primitivas que Remix por sí solo no tiene: el createStorefrontClient, el CartProvider, el hook useShopQuery (ahora reemplazado en su mayoría por los loaders de las rutas) y la superficie de despliegue de Oxygen. Una app genérica de Remix puede comunicarse con la Storefront API, pero no tendrá la misma solución de hosting y caché de primer nivel.

Hay razones válidas para elegir una arquitectura headless distinta de Hydrogen para Shopify; Next.js en Vercel es la alternativa más común. Las concesiones de SEO son reales: la red edge de Vercel es excelente, pero es un sistema más que integrar, y los límites de uso de la Storefront API se vuelven más difíciles cuando el caché es tu responsabilidad y no la del framework. Hydrogen gana en integración estrecha; Next.js gana en flexibilidad.

Si todavía no usas Hydrogen pero lo estás evaluando, nuestra práctica de desarrollo de comercio headless ha lanzado proyectos con ambas arquitecturas.

Regresiones de SEO comunes que vemos en Hydrogen

En las auditorías de cuentas, aparecen una y otra vez las mismas regresiones de SEO en Hydrogen:

• Canónica inyectada mediante useEffect. Siempre renderiza la canónica con SSR. Siempre.
• JSON-LD de Producto generado en el cliente a partir de una llamada useFetcher. El HTML renderizado no tiene marcado de schema. Muévelo al loader de la ruta y emítelo en la respuesta SSR.
• Sitemap construido a partir de una lista fija. Los sitemaps de Hydrogen deben generarse dinámicamente desde la Storefront API en el momento de la solicitud, con caché en el edge. Así los productos nuevos aparecen de inmediato.
• El robots.txt permite el dominio de vista previa de Oxygen. Bloquea la indexación de *.shopifypreview.com y de cualquier hostname de staging de Oxygen.
• Transmitir el precio por streaming. No lo hagas. El precio pertenece a la parte síncrona y esperada del loader.

Puntos clave

• Hydrogen se ejecuta en workers edge de Oxygen y admite SSR completo, SSR con streaming y renderizado solo en el cliente. Usa por defecto SSR completo para las rutas de comercio.
• El SSR con streaming es correcto cuando puedes mantener el contenido indexable (producto, precio, JSON-LD) en el loader síncrono y diferir solo las secciones no críticas (recomendaciones, reseñas).
• Los rastreadores de IA no ejecutan JavaScript. El contenido renderizado en el cliente es invisible para GPTBot, ClaudeBot y PerplexityBot.
• La canónica, el hreflang y el JSON-LD de Producto deben emitirse en la respuesta SSR, no hidratarse en el cliente.
• Valida revisando la respuesta HTML sin procesar. Lighthouse por sí solo no es suficiente.

Para el contenido de referencia específico de Hydrogen, consulta nuestra práctica de SEO para Hydrogen. Para trabajo headless más amplio, aplican tanto el SEO para comercio headless como la descripción general de SEO para Shopify Plus. Toda la base de SEO para Shopify está en SEO para Shopify. Cuando quieras hablar de tu arquitectura específica, aquí estamos.