Agencia de SEO para headless commerce

El SEO para headless commerce es la disciplina de lograr que las tiendas desacopladas, donde el framework del frontend (Next.js, Remix, Nuxt, SvelteKit) está separado del backend de comercio (Shopify, BigCommerce, Adobe Commerce, commercetools, Salesforce), sean indexables, rastreables y dignas de ser citadas por Google y los motores de IA. Los retos son la estrategia de renderizado (SSR vs ISR vs SSG vs CSR), la accesibilidad para rastreadores en el edge, la orquestación de sitemaps entre servicios, la inyección de datos estructurados en el edge y los Core Web Vitals en stacks donde la estrategia de caché es tu responsabilidad, no de la plataforma.

Usa SSR por defecto en páginas de categoría y producto donde los datos del catálogo cambian y los rastreadores deben ver contenido actualizado. Usa ISR (Incremental Static Regeneration) para PDPs de mucho tráfico donde el inventario y los precios toleran una ventana corta de revalidación (60–300 segundos). Reserva SSG para superficies realmente estáticas (institucional, políticas, marketing permanente). El CSR puro es incompatible con un SEO confiable: el renderizador de Google acaba ejecutando JS, pero la latencia de indexación se multiplica y los rastreadores de motores de IA (ChatGPT, Perplexity) con frecuencia no ejecutan JS del cliente en absoluto. Casi siempre la respuesta correcta es un híbrido: SSR para el catálogo, ISR para las PDPs más visitadas, SSG para lo estático, con encabezados de caché estrictos por ruta.

Los entornos edge (Oxygen, Vercel Edge, Cloudflare Workers, Netlify Edge) normalmente mejoran la experiencia del rastreador: un TTFB menor estira el presupuesto de renderizado de Googlebot, las mediciones de INP salen en verde con más consistencia y los rastreadores de motores de IA que asignan un tiempo estricto por solicitud reciben el HTML completo antes de que se agote. Ojo con dos problemas: (1) los entornos edge tienen límites de tamaño de bundle menores que Node, así que los SDK pesados pueden devolverte a Node y reintroducir latencia de arranque en frío; (2) algunos proveedores de edge eliminan o modifican encabezados que esperan los rastreadores (Vary, Cache-Control). Auditamos el comportamiento del edge por ruta y confirmamos el renderizado equivalente al del rastreador con la Inspección de URL de Search Console y comparaciones del HTML renderizado.

En las configuraciones headless, ningún servicio por sí solo es dueño del sitemap. Shopify, BigCommerce o Adobe Commerce solo conocen las rutas del catálogo; tu frontend headless agrega las rutas editoriales (blog, landing pages, SEO programático). El patrón: generar sitemap-index.xml en el origen del frontend, con sub-sitemaps de productos (consultados desde Storefront API o GraphQL), colecciones, contenido (impulsado por el CMS) y rutas editoriales. Revalidar con una cadencia fija (cada 60 minutos) o por webhook (actualización del catálogo). Incluir hreflang dentro del sitemap, no en etiquetas <link>, porque los presupuestos del <head> en Liquid o en plantillas se vuelven ajustados a gran escala.

El JSON-LD debe emitirse del lado del servidor en cada ruta indexable. Es decir, dentro de la exportación de metadata o head del framework, no mediante etiquetas script del lado del cliente. En Next.js App Router, es la función generateMetadata() más dangerouslySetInnerHTML <script type="application/ld+json">. En Remix/Hydrogen, es la exportación meta y scripts inyectados por el loader. Para Catalyst en BigCommerce, es la metadata de Next.js más grafos de Product / Offer / Review / BreadcrumbList / FAQPage / Organization alimentados por el loader. Diseñamos el schema a nivel de layout (Organization, WebSite) y a nivel de ruta (Product, Article, BreadcrumbList) para que el JSON-LD viaje con el HTML renderizado.

Las tiendas headless suelen empeorar el LCP y el INP porque el equipo subestima el costo de la hidratación en el cliente. Los fallos más comunes: (1) hidratar PDPs completas como un solo árbol de React bloquea el hilo principal y hunde el INP; (2) respuestas GraphQL pesadas inflan el LCP porque la imagen más grande queda detrás de una cascada de solicitudes; (3) los ejecutores de personalización de terceros (Nosto, Dynamic Yield) cargan scripts bloqueantes que llevan el INP por encima de 200 ms. Soluciones: React Server Components para superficies no interactivas, sugerencias de precarga de imágenes desde el servidor, personalización diferida con espacio reservado en el layout y división de código orientada al INP en los límites de los componentes.

El frontend headless es la superficie canónica, no el backend de headless commerce. Emitimos las etiquetas canonical desde el layout o los metadatos de página del frontend, sin depender nunca del canonical configurado en el administrador del backend (que a menudo apunta a la URL del propio backend headless, un destino equivocado). En cuanto a hreflang, el frontend es dueño de la topología porque controla la estructura de URLs. Normalmente usamos anotaciones hreflang a nivel de sitemap para rutas /<locale>/ y emitimos enlaces recíprocos entre todos los mercados del conjunto.

Sí, de dos maneras. Primero, los rastreadores de IA (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Google-Extended) hacen suposiciones más estrictas sobre el HTML renderizado: normalmente no ejecutan JS, así que SSR o ISR no es negociable. Segundo, la ubicación de llms.txt y la estructura del contenido importan más en headless porque controlas directamente el archivo raíz (la plataforma de comercio no lo hace). Implementamos llms.txt en la raíz del frontend, estructuramos el contenido para la extracción de entidades con patrones compatibles con markdown y medimos la participación en citas en ChatGPT Shopping, Perplexity Shop, Google AI Overviews, Gemini y Microsoft Copilot.

Shopify Hydrogen + Oxygen (Remix + edge), BigCommerce Catalyst (Next.js + Makeswift), commercetools + Next.js, Adobe Commerce headless (REST + GraphQL con Next.js) y Salesforce Commerce Cloud headless mediante OCAPI/SCAPI. Hemos trabajado en las cinco y auditamos el SEO en todas con una metodología compartida: estrategia de renderizado SSR primero, sitemap y llms.txt en el edge, inyección de schema a nivel de layout, hidratación orientada al INP y verificación de HTML equivalente al del rastreador.

Fase 1: auditoría de la estrategia de renderizado por ruta (SSR/ISR/SSG/CSR), comparación del HTML equivalente al del rastreador, revisión de la orquestación de sitemaps, mapa de cobertura de schema. Fase 2: reconstrucción de la topología de canonical y hreflang si hace falta, implementación de llms.txt, auditoría del schema Product, trabajo en Core Web Vitals (LCP / INP / CLS). Fase 3: estrategia de contenido alineada con el catálogo, rutas de SEO programático donde corresponda, seguimiento de citas en motores de IA. Entregamos código directamente en el repositorio del frontend: el mismo equipo es responsable de `/audit` y `/commit`.