SEO para ecommerce headless

En resumen: Un ecommerce headless separa el escaparate (lo que ven los compradores) del motor de comercio (Shopify, Commercetools, BigCommerce). Para el SEO, lo importante es cómo renderiza las páginas el escaparate. Si se construyen en el servidor o durante el despliegue, Google recibe un HTML terminado. Si se construyen en el navegador, Google tiene que esperar a que se ejecute JavaScript: puede hacerlo, pero es más lento y arriesgado.

Qué significa «headless» para una tienda

Una plataforma de ecommerce tradicional (WooCommerce o Shopify estándar) lo gestiona todo en un mismo sistema: almacena los productos, procesa los pedidos y renderiza las páginas HTML que ven compradores y rastreadores. Una configuración headless separa esas responsabilidades. Un motor de comercio gestiona productos, inventario y proceso de pago. Un framework de frontend independiente —normalmente Next.js, Nuxt o Astro— obtiene esos datos y renderiza lo que realmente ven los visitantes.

El motor de comercio pasa a ser invisible para los buscadores. Google ve lo que renderice tu frontend.

La decisión que determina los resultados de SEO

¿Cómo construye cada página tu frontend?

• SSR (renderizado del lado del servidor): el servidor construye la página con cada solicitud. Los rastreadores reciben un HTML completo. Es seguro para el SEO.
• SSG (generación de sitios estáticos): las páginas se preconstruyen como archivos HTML durante el despliegue. Es la opción más rápida y segura para el SEO.
• CSR (renderizado del lado del cliente): el servidor envía una estructura vacía y JavaScript construye la página en el navegador. Google puede renderizarla, pero la pone en una cola diferida. Otros rastreadores a menudo no pueden hacerlo.

La mayoría de los escaparates headless utilizan Next.js, Nuxt o Astro, y todos admiten SSR y SSG. El riesgo consiste en activar CSR por accidente en páginas de producto o categoría.

Lo que ahora te corresponde gestionar

En una plataforma monolítica, los módulos o complementos integrados se ocupan de los aspectos básicos del SEO. En una configuración headless, tú debes construir todo esto:

• Etiquetas de título y metadescripciones (por página, no para todo el sitio)
• Etiquetas canónicas (especialmente importantes para la navegación por facetas y las URL de variantes)
• Generación del sitemap XML
• Datos estructurados JSON-LD (Product, BreadcrumbList, Organization)
• robots.txt

Los frameworks que abarca este grupo —SEO para JavaScript, Next.js, React y CMS headless— se ocupan cada uno de una parte de este panorama.

En resumen: El SEO para ecommerce headless tiene dos capas: la arquitectura de renderizado (que determina si Googlebot recibe HTML o una estructura vacía) y la capa de datos estructurados y feeds (que determina la elegibilidad para resultados enriquecidos y fichas de producto gratuitas en Google Shopping). En cuanto al renderizado, SSR y SSG son seguros; CSR requiere una verificación explícita. Para los datos estructurados, se exige el esquema Product con Offer (no AggregateOffer) para optar a fichas de comerciantes; ProductGroup + hasVariant representa correctamente conjuntos de variantes. En cuanto a los feeds, un feed de Google Merchant Center es independiente del renderizado del frontend y tiene la misma importancia para las superficies de Shopping: una arquitectura headless no te exime de los requisitos de calidad del feed.

Arquitectura de renderizado para tiendas headless

La pila canónica de ecommerce headless utiliza Next.js (Vercel Commerce) o Nuxt. Shopify Hydrogen funciona con React Router 7: migró desde Remix a finales de 2024 y, a mediados de 2026, el propio paquete @shopify/remix-oxygen de Shopify incluye un aviso de obsolescencia que dirige a los integradores a react-router y @shopify/hydrogen/oxygen. (Algunas páginas de la documentación de Shopify todavía muestran ejemplos de código antiguos con el estilo de Remix; comprueba la versión del paquete que utilizas realmente, no solo la página de documentación a la que llegues.) Todas estas opciones utilizan de forma predeterminada el renderizado del lado del servidor o la generación estática, por lo que Googlebot recibe el HTML completo en la primera solicitud, sin esperar en una cola de renderizado.

Los modos de fallo dependen de cada framework, pero siguen un patrón:

Next.js: convertir una página de producto o categoría en un Client Component desplaza el renderizado al navegador. Las rutas de App Router son Server Components de forma predeterminada; el riesgo es marcar por accidente una página con mucho tráfico como 'use client' y no detectarlo. Compruébalo con curl o con el código fuente: si el título y la descripción del producto no están en el HTML sin procesar, la página usa CSR.

Shopify Hydrogen (React Router): el modo framework de React Router utiliza loaders del lado del servidor de forma predeterminada, el mismo patrón que usaba Remix antes de la migración. El riesgo está en la configuración de caché de Oxygen (el alojamiento de Shopify): las respuestas obsoletas almacenadas en caché pueden mostrar contenido antiguo a los rastreadores mucho después de actualizar un producto.

React personalizado + Vite: de forma predeterminada, esta combinación utiliza CSR puro. Google puede renderizarlo, pero es la configuración más arriesgada. Añade React Server Components o cambia a un framework.

Datos estructurados para páginas de producto headless

Un frontend headless controla su propio <head>, así que los datos estructurados son enteramente responsabilidad tuya. Tres tipos de esquema son importantes para el ecommerce:

Esquema Product: el marcado mínimo viable incluye name, image y offers (con price, priceCurrency y availability). Usa Offer en páginas de compra directa para poder optar a fichas de comerciantes; AggregateOffer impide esa elegibilidad.

ProductGroup + hasVariant: es la actualización del esquema de febrero de 2024. Cuando una página representa un producto disponible en varias variantes (talla, color o material), agrupa las variantes en un ProductGroup con variesBy (por ejemplo, https://schema.org/color) y enlaza cada variante mediante hasVariant. Así indicas a Google la relación y evitas señales de contenido duplicado entre URL de variantes.

BreadcrumbList: ayuda a Google a comprender la jerarquía del sitio y permite mostrar resultados enriquecidos con rutas de navegación. Es especialmente importante en configuraciones headless, donde la estructura de URL es personalizada.

Google Merchant Center y headless

El renderizado de tu frontend es independiente del feed de GMC. Incluso una tienda headless perfectamente renderizada mediante SSR necesita enviar un feed de productos a Merchant Center para optar a fichas gratuitas de Shopping y a toda la gama de experiencias de fichas de comerciantes. La calidad de los atributos del feed —título, GTIN, imagen y paridad de precios— influye en el posicionamiento de las cuadrículas orgánicas de productos, al margen del SEO on-page. No trates el feed como una cuestión exclusiva de publicidad; también es una cuestión de búsqueda.

Adónde ir ahora

Este grupo trata en profundidad la capa de renderizado y frameworks:

• SEO para JavaScript: los modos generales de fallo (paridad, interacción, estado y tiempos) aplicables a cualquier escaparate con mucho JavaScript.
• SEO para Next.js: el framework dominante para el comercio headless; App Router, Metadata API, sitemap.ts, imágenes LCP y problemas de ISR.
• SEO para React: el modelo de renderizado subyacente y cómo el Web Rendering Service de Google pone en cola y procesa las páginas de React.
• SEO para CMS headless: cuando el contenido de los productos reside en un CMS (Contentful, Sanity o Storyblok) en lugar de en el propio motor de comercio.
• Plataformas de comercio headless: comparación de las opciones reales (Shopify Hydrogen, BigCommerce, commercetools, Salesforce PWA Kit, Medusa, Saleor y Elastic Path) y de lo que cada una deja en tus manos.
• Comercio componible: el patrón de arquitectura MACH situado un nivel por encima de headless y el riesgo para la responsabilidad de SEO al montar una pila con proveedores independientes.

El SEO para ecommerce headless tiene dos capas:

Capa de renderizado (determina la rastreabilidad):

• SSR y SSG producen HTML que Googlebot lee en la primera solicitud: son seguros.
• CSR produce una estructura vacía; Google la renderiza más tarde (queda en cola y puede agotar el tiempo): es arriesgado.
• Next.js, React Router (Hydrogen) y Nuxt utilizan SSR/SSG de forma predeterminada; comprueba con curl o con el código fuente que las páginas de producto y categoría no usen CSR por accidente.

Capa de datos estructurados y feeds (determina la elegibilidad para resultados enriquecidos y Shopping):

• Esquema Product: usa Offer (no AggregateOffer) en páginas de compra directa para optar a fichas de comerciantes.
• ProductGroup + hasVariant (febrero de 2024): marcado correcto para conjuntos de variantes.
• La calidad del feed de GMC (título, GTIN, imagen y paridad de precios) influye de forma independiente en el posicionamiento de las superficies de Shopping; no es opcional en configuraciones headless.

Lo que ahora debes construir de forma explícita (sin complemento de plataforma):

• Título y metadescripción por página
• Etiquetas canónicas (esenciales para la navegación por facetas y las URL de variantes)
• Sitemap XML
• JSON-LD (Product, BreadcrumbList)
• robots.txt

Google Search Central

• Datos estructurados de producto — requisitos de los esquemas Product, Offer y ProductGroup
• Conceptos básicos del SEO para JavaScript — cómo gestiona Googlebot el contenido renderizado mediante JavaScript
• Corregir contenido de carga diferida — Intersection Observer y desplazamiento infinito
• Sitemaps XML — formato y envío de sitemaps

Google Merchant Center

• Fichas de producto gratuitas — elegibilidad para superficies orgánicas de Shopping
• Especificación de datos de producto — requisitos de los atributos del feed

Documentación de frameworks

• Metadata API de Next.js — metadatos de App Router y generateMetadata
• sitemap.ts de Next.js — generación de sitemaps basada en archivos
• React Router: carga de datos — funciones loader del lado del servidor (el patrón que utiliza ahora Shopify Hydrogen)

“Some JavaScript sites may use the app shell model where the initial HTML does not contain the actual content and Google needs to execute JavaScript before being able to see the actual page content that JavaScript generates … The page may stay on this queue for a few seconds, but it can take longer than that.” — Google Search Central, «Understand the JavaScript SEO basics». Ir a la cita

Traducción: «Algunos sitios con JavaScript pueden utilizar el modelo de estructura de aplicación, en el que el HTML inicial no contiene el contenido real y Google necesita ejecutar JavaScript antes de poder ver el contenido que este genera… La página puede permanecer en esta cola unos segundos, aunque puede tardar más».

“We do an HTTP request, and we get something back … some barebone HTML and all it does is load the JavaScript and run the JavaScript. Then, this HTML … goes into rendering. Rendering runs JavaScript — boom!, a lot of content happens that wasn’t there before.” — Martin Splitt, defensor de desarrolladores de Google, sesión de Google Webmaster Central Office Hours. [Fuente: grabación de Office Hours; comprobar con el audio en directo]

Traducción: «Hacemos una solicitud HTTP y recibimos algo… un HTML básico cuya única función es cargar y ejecutar JavaScript. Después, este HTML… pasa al renderizado. El renderizado ejecuta JavaScript y, de repente, aparece mucho contenido que antes no estaba».

Lista de comprobación de SEO para ecommerce headless

Verificación del renderizado

• curl -s https://yourstore.com/products/[slug] | grep '<title>' — confirma que el título está en el HTML sin procesar
• Consulta el código fuente de una página de producto: el nombre y la descripción deben ser visibles sin JavaScript
• Confirma que las páginas de categoría o colección también se renderizan en el servidor (la mayoría de los errores de CSR se producen en rutas dinámicas)
• Comprueba en Google Search Console → Inspección de URL → «Probar URL publicada» las páginas clave

Datos estructurados

• Esquema Product en cada PDP: name, image, offers (con price, priceCurrency y availability)
• Uso de Offer (no AggregateOffer) en páginas de compra directa, obligatorio para optar a fichas de comerciantes
• ProductGroup + hasVariant + variesBy para conjuntos de variantes (color, talla y material)
• BreadcrumbList en páginas de producto y categoría
• Validación con la prueba de resultados enriquecidos

Responsabilidad del SEO técnico

• <title> y <meta name="description"> únicos por página (no una plantilla para todo el sitio)
• Etiqueta canónica en todas las páginas (especialmente en URL de variantes y filtradas)
• Sitemap XML generado y enviado (incluye páginas de producto y categoría)
• robots.txt accesible y correcto (no bloquea JS/CSS)
• Redirecciones 301 gestionadas en el nivel del framework o CDN (no perdidas en un router de SPA)

Google Merchant Center

• Feed de productos enviado a GMC (aunque solo uses fichas orgánicas)
• Paridad de precios: el precio del feed coincide exactamente con el de la página de destino
• GTIN incluidos para productos de marca
• Diagnósticos del feed revisados en GMC → Diagnóstico

SEO para ecommerce headless: marco de decisión

Elección del framework según el riesgo de SEO

Cuándo elegir SSG o SSR

Usa SSG cuando:

• El catálogo de productos sea relativamente estable (<100 actualizaciones al día)
• Uses ISR para la revalidación (revalidate en Next.js o useAsyncData con lazy en Nuxt)
• El rendimiento sea la máxima prioridad (HTML estático desde el perímetro de la CDN)

Usa SSR cuando:

• La disponibilidad, el precio o la personalización del producto cambien con cada solicitud
• El inventario en tiempo real sea esencial (los productos agotados deben mostrarse con precisión)
• El catálogo sea demasiado grande para preconstruirlo durante el despliegue

Evita CSR en:

• Páginas de producto
• Páginas de categoría o colección
• Cualquier página que quieras posicionar orgánicamente

¿Cómo debería renderizarse esta ruta headless?

Decídelo en el nivel de la plantilla de ruta. Las páginas de detalle de producto y las de categoría pueden tomar decisiones distintas.

Fallos habituales de SEO en ecommerce headless

El contenido del producto aparece en el navegador, pero no en el código fuente

Causa probable: una ruta de producto o una vía de obtención de datos pasó al renderizado del lado del cliente, por ejemplo mediante un Client Component de alto nivel en Next.js.

Solución: obtén los datos en un Server Component, loader o ruta del servidor y devuelve el contenido indexable del producto en el HTML inicial. Confírmalo con curl y el código fuente, no solo con el DOM hidratado.

Los resultados de búsqueda muestran un título genérico en muchos productos

Causa probable: el frontend headless utiliza un valor alternativo para todo el sitio porque los metadatos de la ruta no reciben los datos del producto del lado del servidor.

Solución: genera el título, la descripción y la etiqueta canónica a partir de la respuesta de producto de la ruta en el servidor. Rastrea varias plantillas de productos y categorías y confirma que cada respuesta sin procesar contenga los valores únicos esperados.

El precio o la disponibilidad están obsoletos para los rastreadores

Causa probable: SSG/ISR o la caché perimetral duran más que la actualización del catálogo, mientras que una solicitud del cliente muestra a los compradores un valor más reciente tras la hidratación.

Solución: conecta los eventos del motor de comercio con la revalidación o acorta la ventana de caché de las rutas sensibles al precio. Compara el HTML sin procesar, la página renderizada, el feed y el proceso de pago para el mismo SKU hasta que los cuatro coincidan.

Faltan resultados enriquecidos de producto pese a que el JSON-LD parece válido

Causas probables: el marcado solo se inyecta después de ejecutar JavaScript, usa AggregateOffer en una página de compra directa, omite campos obligatorios de la oferta o describe datos que no coinciden con la página.

Solución: emite un único objeto Product renderizado en el servidor con el Offer adecuado; después, ejecuta la prueba de resultados enriquecidos y compara sus valores con el producto visible y el feed de GMC.

Las URL de variantes compiten o se canonizan de forma imprevisible

Causa probable: el frontend crea URL de estado rastreables sin una etiqueta canónica coherente y sin expresar la relación entre el grupo de productos y sus variantes.

Solución: elige la estrategia de variantes indexables, mantén las etiquetas canónicas coherentes con ella e implementa ProductGroup junto con hasVariant cuando la página represente un conjunto de variantes. Rastrea todos los estados seleccionables para comprobar la URL y el marcado emitidos.

Los productos desaparecen después de una migración headless

Causas probables: las URL antiguas carecen de redirecciones del lado del servidor, el nuevo sitemap está incompleto o la navegación SPA oculta errores 404 del servidor.

Solución: prueba las URL antiguas mediante solicitudes directas, valida el mapa de redirecciones de antiguas a nuevas y compara el nuevo sitemap con el catálogo publicado. El comportamiento del router del cliente no sustituye una redirección HTTP.

Verificar la capa de renderizado headless

Inspeccionar el HTML sin procesar en busca de las señales necesarias

Ejecuta lo siguiente en una consola con una URL de producto y otra de categoría. Sustituye los valores de ejemplo por términos que deban aparecer en esas páginas.

url='https://store.example/products/example'
html="$(curl -fsSL "$url")"
printf '%s' "$html" | grep -i '<title'
printf '%s' "$html" | grep -i 'rel="canonical"'
printf '%s' "$html" | grep -F 'Example Product Name'
printf '%s' "$html" | grep -F 'application/ld+json'

Si una señal solo existe después de que el navegador ejecute JavaScript, esta prueba revela la brecha en la respuesta sin procesar.

Comparar en bloque una lista de URL con Python

Guarda las URL canónicas de productos y categorías en urls.txt, una por línea. Este script informa del estado, de si el HTML final contiene un título y una etiqueta canónica, y del número de cadenas del esquema Product presentes.

from urllib.request import Request, urlopen
from urllib.error import HTTPError
import re

for url in open("urls.txt", encoding="utf-8"):
    url = url.strip()
    if not url:
        continue
    try:
        response = urlopen(Request(url, headers={"User-Agent": "HeadlessSEOCheck/1.0"}))
        html = response.read().decode("utf-8", errors="replace")
        print(url, response.status,
              "title=" + str(bool(re.search(r"<title[^>]*>.+?</title>", html, re.I | re.S))),
              "canonical=" + str('rel="canonical"' in html.lower()),
              "product_schema=" + str(len(re.findall(r'"@type"\s*:\s*"Product"', html))))
    except HTTPError as error:
        print(url, error.code, "HTTP error")

Inspeccionar los metadatos renderizados en Chrome DevTools

Pega este código en la consola de una página de producto. Comprueba el DOM hidratado; compara el resultado con los scripts de respuesta sin procesar anteriores para detectar problemas de paridad.

({
  title: document.title,
  canonical: document.querySelector('link[rel="canonical"]')?.href ?? null,
  productSchemas: [...document.querySelectorAll('script[type="application/ld+json"]')]
    .filter((node) => /"@type"\s*:\s*"Product"/.test(node.textContent)).length,
  productHeading: document.querySelector('h1')?.textContent?.trim() ?? null,
});

Recursos del sector

• Vercel Commerce (plantilla inicial de Next.js) — implementación de referencia de código abierto para un escaparate headless
• Documentación de Shopify Hydrogen — framework headless oficial de Shopify (basado en React Router 7 desde 2026; algunas páginas de la documentación todavía muestran ejemplos de código de Remix anteriores a la migración)
• Google Search Central: conceptos básicos del SEO para JavaScript — directrices para desarrolladores de Google sobre el renderizado mediante JS (el artículo de web.dev sobre SEO para JS se retiró; esta es la ubicación vigente de esas directrices)
• Onely: How Does Google Crawl JS Content? An Experiment — análisis técnico detallado de cómo Googlebot rastrea e indexa el contenido renderizado mediante JavaScript (el enlace anterior de esta posición devolvía un 404; este es el artículo equivalente vigente de Onely)
• Google Search Central: datos estructurados de producto — requisitos oficiales de esquema para resultados enriquecidos y fichas de comerciantes

Ponte a prueba: SEO para ecommerce headless

Cinco preguntas rápidas sobre la arquitectura de una tienda headless y el SEO. Elige una respuesta para cada una y compruébala después.

Registro de cambios