En la Parte 1 hicimos el trabajo más difícil, que era decidir si íbamos a hacerlo siquiera. Si está aquí, es porque recorrió la prueba de los cuatro muros y al menos uno de ellos es real. Puede nombrarlo, puede cuantificar lo que le está costando y puede señalar la palanca que espera mover.
Bien. Ahora construyamos. Y la construcción es donde realmente se fabrica la mayor parte del arrepentimiento. No en la decisión, sino en la docena de decisiones silenciosas que vienen después.
Voy a entregarle esto tal como se lo entregaría a un equipo de producto en el que confío. Empezar por la decisión, nombrar la contrapartida, trazar una secuencia ejecutable. Nada de muros teóricos. Vamos allá.
La arquitectura, y por qué “qué framework” es la primera pregunta equivocada
Todo el mundo quiere empezar con la pregunta de Hydrogen frente a Next.js. Esa es la segunda pregunta. La primera, la que realmente decide el asunto, es esta: ¿cuán comprometido está con permanecer en Shopify, y cuán pesado es su contenido no relacionado con el comercio? Responda a esas dos con honestidad y el framework prácticamente se elige solo.
Para la mayoría de los comerciantes que genuinamente se han ganado la construcción, la opción honesta por defecto en 2026 es Hydrogen sobre Oxygen. Está disponible con carácter general desde 2023, ahora funciona sobre React Router v7, que es la evolución de Remix, con Vite como herramienta de compilación, y está en producción en marcas como Allbirds y Gymshark. Ya no es tecnología para early adopters. Recorta semanas del calendario y reduce el mantenimiento a largo plazo, precisamente porque deja de luchar contra la plataforma.
Aquí está el replanteamiento más importante, porque invierte el instinto habitual. En Shopify en 2026, el acoplamiento es la característica, no la concesión. Shopify ha pasado el último año haciendo que la integración estrecha valga más, no menos. Existe una herramienta consciente del esquema que conecta directamente Cursor, Claude Code y VS Code con las API de Shopify con validación en vivo, junto con perímetros de autenticación anti-bots y publicación a nivel de variante. Intentar recrear todo eso en un backend personalizado totalmente desacoplado significa dedicar sprints a reconstruir lo que Hydrogen le entrega servido en bandeja. Si lo que quería era control de React dentro del grafo de Shopify, Hydrogen es la respuesta. Si lo que quería era escapar por completo del grafo de Shopify, vuelva a leer la Parte 1.
Mi heurística de arquitecto, la misma que aplico a cualquier sistema: empiece acoplado y pragmático. Siempre puede añadir complejidad cuando sienta las costuras. Casi nunca puede eliminarla una vez que se ha vuelto estructural.
La pila tecnológica a la que realmente se está comprometiendo
“Shopify headless” es un pequeño conjunto de piezas. Conozca cada una antes de definir el alcance, porque cada una es una partida de coste y un punto de fallo.
La Storefront API, que es GraphQL, es su capa de lectura para productos, colecciones y contenido. Es de donde su escaparate obtiene sus datos. La Storefront Cart API es donde crea y gestiona carritos, tras lo cual envía al comprador al checkout usando la URL de checkout del carrito. Esto es lo que sustituyó a la antigua Checkout API, ahora descontinuada. La Customer Account API gestiona el inicio de sesión, el historial de pedidos y la gestión de cuenta del comprador identificado. Checkout Extensibility, junto con Shopify Functions, es como se personaliza el checkout alojado, cubriendo upsells, campos personalizados, lógica de descuentos y envío, sin tocar su núcleo. Functions es donde reside ahora su lógica personalizada de descuentos, envíos y paquetes. Y Oxygen es el hosting en el borde de Shopify para Hydrogen, desplegado directamente desde su repositorio e incluido en los planes de pago, por lo que no hay ningún contrato de hosting separado que negociar.
Interiorice un cambio mental y la mitad de las decisiones posteriores se vuelven más sencillas. No está construyendo una tienda. Está construyendo una aplicación de frontend que consume servicios de comercio. Eso cambia cómo la dota de personal, cómo la prueba y cómo la despliega, que es el resto de esta guía.
El CMS que no puede saltarse
Lo diré tan claramente como pueda, porque es el análisis post mortem headless más común que encuentro. Una tienda headless sin CMS significa que cada cambio de contenido es un despliegue de desarrollador.
Imagine el día a día. Su encargado de merchandising quiere lanzar una colección, cambiar un banner principal o publicar una landing page de temporada. En Liquid lo hace él mismo en minutos. En una tienda headless sin capa de contenido, abre un ticket, espera a un desarrollador y espera un despliegue. La velocidad de marketing se desploma, con agencias reportando caídas del 60 al 80 %, y el resentimiento aparece en las reuniones de equipo. Habrá gastado seis cifras para hacer que su equipo de marketing sea más lento. He visto exactamente esto arruinar un lanzamiento que, técnicamente, fue un éxito completo.
Así que el CMS no es opcional. Es parte de la construcción, y es la partida que a las propuestas les encanta olvidar discretamente. Las opciones reales se reducen a unas pocas.
- Sanity es querido por los desarrolladores, flexible y barato para empezar, aunque necesita desarrolladores para modelar el contenido.
- Contentful es de nivel empresarial, con precios por uso, y escala hasta una complejidad seria.
- Storyblok ofrece edición visual de componentes que sus responsables de marketing realmente pueden usar.
- Los editores visuales nativos de Hydrogen, como Weaverse, están construidos para que los encargados de merchandising puedan editar sin un desarrollador, fusionando el CMS y el constructor de páginas en uno solo.
La elección depende de una sola pregunta. ¿Quién edita el contenido, y con qué frecuencia? Si marketing publica a diario, priorice un editor visual que una persona no técnica pueda manejar. Si el contenido es escaso y estructurado, un CMS orientado a desarrolladores está bien. Equivóquese aquí y la arquitectura funcionará perfectamente mientras el negocio se agarrota silenciosamente.
La migración de SEO, lo más arriesgado que va a hacer
Aquí es donde realmente mueren las buenas construcciones headless. No en la arquitectura, sino en la migración. Está reemplazando cada URL de un sitio en el que Google ya confía. Hágalo con descuido y no obtendrá una tienda más rápida. Obtendrá una tienda más rápida que nadie puede encontrar.
Estos son los innegociables, por orden de prioridad.
Primero, el mapa de redirecciones es el elemento de mayor riesgo de todo el proyecto. Cada URL del sitio antiguo necesita una redirección 301 probada hacia su equivalente nuevo. Construya y pruebe ese mapa antes del lanzamiento, no durante él. Este es el punto de fallo de SEO más común en cualquier migración, sea headless o no.
Segundo, el renderizado del lado del servidor es obligatorio. Tanto Hydrogen como Next.js hacen SSR, y los motores de búsqueda deben recibir HTML completamente renderizado. Lanzar un escaparate solo del lado del cliente en 2026 es negligencia profesional, y ningún equipo competente lo hace.
Tercero, los datos estructurados son ahora responsabilidad suya. Los temas nativos de Shopify generan automáticamente el JSON-LD de productos y colecciones. El headless no lo hace, así que tiene que construirlo usted mismo. Es sencillo y no debe saltarse. En un mundo de descubrimiento agéntico, al que enseguida llegaremos, los datos estructurados no son solo higiene de SEO. Es cómo las máquinas leen su catálogo.
Cuarto, los Core Web Vitals son un factor de posicionamiento. El techo de rendimiento que pagó es también una palanca de SEO, pero solo si realmente lo alcanza.
Trate la migración como su propio proyecto, con su propio responsable, su propia lista de verificación y su propia puerta de decisión go/no-go. No es una tarea de la semana de lanzamiento.
El reloj de cumplimiento normativo, los plazos que rompen tiendas en silencio
Esta es la parte que nadie pone en la diapositiva romántica del headless, y es la parte que le despierta a las 3 de la madrugada. Shopify ha estado replataformando su capa de checkout, y los plazos son reales, secuenciales y peligrosamente fáciles de confundir. Confundirlos es el error de planificación más costoso que una tienda Plus puede cometer ahora mismo.
Empiece por checkout.liquid, que está obsoleto. Las páginas de información, envío y pago debían migrar a Checkout Extensibility antes del 13 de agosto de 2024. Las páginas de agradecimiento y estado del pedido debían migrar antes del 28 de agosto de 2025 para Plus, y las tiendas no Plus tienen hasta el 26 de agosto de 2026. Shopify ha estado actualizando automáticamente las tiendas que no migraron, lo que significa que el código de checkout personalizado remanente y los Additional Scripts simplemente dejan de renderizarse. El síntoma más insidioso es que sus píxeles de post-compra y su analítica se rompen en silencio, y parece que los anuncios están rindiendo mal hasta que alguien finalmente indaga en los datos.
Luego está la vía separada del paso de Shopify Scripts a Shopify Functions. Esta tiene su propio plazo. Scripts se descontinúa el 30 de junio de 2026. Si su tienda usa Scripts para combinaciones de descuentos, envío escalonado, precios B2B o lógica de paquetes, esa lógica deja de funcionar el 1 de julio de 2026. La ruta de migración es Functions, escrito en JavaScript o Rust. Si no ha empezado todavía, esto es muy probablemente su pendiente más urgente en el momento en que lee esto.
Detrás de todo esto está PCI DSS v4, que es gran parte de la razón por la que esto está sucediendo en primer lugar. El antiguo modelo de inyección de scripts en bruto no podía cumplir con los estándares modernos de seguridad de pagos. El modelo alojado y basado en extensibilidad es la vía conforme, lo cual es una razón más por la que no querrá ser dueño del checkout.
Para una construcción headless en concreto, su arquitectura debe asumir el checkout alojado por Shopify a través de la URL de checkout, con Checkout Extensibility y Functions para cualquier personalización. Cualquier plan que se apoye discretamente en la personalización de checkout heredada ya está roto. Audite esto el primer día de la definición del alcance, no en QA.
El equipo y el modelo operativo, el coste que nadie define en el alcance
Un escaparate headless es una aplicación viva. Necesita un responsable con pulso, no un lanzamiento y un apretón de manos.
La verdad sin rodeos de los análisis post mortem es que una tienda Hydrogen sin un ingeniero React senior a tiempo completo, o un contrato de agencia comprometido, se convierte en un pasivo. Las actualizaciones se estancan, las funciones que tomaban semanas empiezan a tomar trimestres, el backlog crece, y la tienda que construyó para tener agilidad se convierte en lo más lento que posee. Antes de empezar, exija una respuesta real a tres preguntas.
- ¿Quién despliega? Nombre la capacidad de ingeniería, ya sea talento React senior interno o un estudio contratado de forma permanente. “Ya lo resolveremos” no es una respuesta.
- ¿Quién hace el merchandising? Esta es la decisión del CMS hecha concreta. Qué personas editan qué, sin necesidad de un despliegue.
- ¿Quién es responsable del mapa de redirecciones, los datos estructurados, los Core Web Vitals y los plazos de cumplimiento? Son tareas de las que nadie se ocupa hasta que se convierten en un incidente. Asígnelas ahora, por nombre.
Aquí es también donde reside el coste real. La construcción es la cifra visible. La propiedad es la recurrente. El headless convierte una parte de su gasto en plataforma en un gasto de ingeniería permanente. Si esa contrapartida no tiene una palanca de ingresos detrás, no tenía un muro. Tenía un deseo. Sigo enviándole de vuelta a la Parte 1 porque ahí es donde vive la disciplina.
Construir para el descubrimiento agéntico, la razón propia de 2026 que cambió todo esto
Señalé esto como un muro en la Parte 1. Aquí está la realidad de la implementación, porque es discretamente la parte más estratégica de todo el ejercicio.
La frontera del descubrimiento se está moviendo. Shopify ahora permite que los escaparates Hydrogen se conecten al Storefront MCP, lo que significa construir agentes de compra de IA directamente en su tienda que pueden recomendar productos, llenar carritos y guiar a los compradores usando datos de producto y cliente en vivo. Por separado, Shopify Catalog está haciendo que los productos sean descubribles dentro de asistentes de IA como ChatGPT y Perplexity, abriendo un canal que no existía hace dos años.
Lo que eso significa para la construcción se reduce a tres cosas. Los datos estructurados y API-first dejan de ser higiene y se convierten en distribución. La misma disciplina de JSON-LD limpio y Storefront API que ayuda al SEO es lo que permite que una máquina lea, recomiende y transaccione con su catálogo, y las arquitecturas headless están estructuralmente mejor posicionadas para esto que las tiendas Liquid ensambladas a base de parches. La velocidad se convierte en un factor de descubrimiento y no solo de UX, porque el tráfico agéntico castiga a las tiendas lentas y desordenadas con más dureza que los humanos. Un bot no espera educadamente. Y debería diseñar la capa de datos para lectores no humanos desde ahora, tratando la pregunta de si un agente de IA puede entender y actuar sobre su escaparate como un requisito de primer nivel en lugar de algo deseable para una segunda fase.
Este es el único lugar donde me permitiré sonar como un futurista. Los comerciantes que hoy construyen escaparates headless limpios y estructurados no solo están comprando un sitio más rápido. Están comprando uno legible, legible por los intermediarios de IA que cada vez más se interpondrán entre sus productos y sus clientes. Esa es una razón genuina para pasarse a headless, y sencillamente no tenía peso en 2023.
El plan por fases, cómo ejecutar esto sin un desastre de big bang
Si hay algo táctico que sacar de esta guía, es esto. No haga una migración headless en modo big bang. El enfoque más inteligente es incremental. Reemplace primero la superficie de mayor valor, demuéstrela y luego expanda. Mantenga el checkout intacto durante todo el proceso.
La Fase 0 consiste en ganárselo y demostrar que la solución barata está agotada. Ejecute la pasada de velocidad limpia en Liquid. Audite aplicaciones, imágenes y scripts. Confirme que el muro es real y que la ganancia no es solo higiene. Consiga alineación por escrito entre marketing, ingeniería y liderazgo sobre el muro, el coste y la palanca. El criterio de salida es un registro de decisión de una página firmado por todos.
La Fase 1 consiste en decidir y reducir el riesgo. Fije tres cosas: la arquitectura (con Hydrogen y Oxygen como opción por defecto), el CMS (elegido según quién edita qué) y el hosting. Audite el reloj de cumplimiento y la migración de Scripts a Functions. Construya el mapa de redirecciones y el plan de SSR y datos estructurados como entregables, no como intenciones. El criterio de salida es un mapa de redirecciones redactado y probado en staging, con cada elemento de cumplimiento asignado a un responsable y una fecha.
La Fase 2 consiste en desplegar una superficie. Elija la superficie donde el muro más duele. A menudo son las páginas de producto y colección para un muro de experiencia, o una superficie de aterrizaje de alto tráfico para un muro de rendimiento. Constrúyala en headless, conéctela a la Storefront API, mantenga todo lo demás en Liquid y mantenga el checkout en Shopify. El criterio de salida es que la nueva superficie supere a la antigua en la métrica que nombró, que es la conversión, no Lighthouse.
La Fase 3 consiste en expandirse deliberadamente. Migre las siguientes superficies solo a medida que cada una demuestre su valor. Mantenga el mapa de redirecciones y los datos estructurados de forma continua. Incorpore a los encargados de merchandising al CMS y confirme que pueden publicar sin usted. El criterio de salida es que la velocidad de marketing esté igual o por encima de donde estaba antes de la migración.
La Fase 4 consiste en construir hacia el futuro. Ahora invierte en las cosas que justificaron la arquitectura en primer lugar: el configurador, la preparación para el descubrimiento agéntico, la composabilidad multisuperficie. Aquí es donde el techo que pagó finalmente se convierte en ingresos.
Las trampas, y cómo evitarlas
He visto los mismos errores repetirse en suficientes construcciones como para nombrarlos.
Pasarse a headless por un problema que una pasada de velocidad habría resuelto. Seis cifras gastadas para arreglar páginas lentas que eran lentas por la sobrecarga de aplicaciones y las imágenes sin optimizar. La Fase 0 no es negociable: agote la solución barata y mida antes de comprometerse.
Olvidar el CMS. Cada cambio de contenido se convierte en un despliegue y la velocidad de marketing se desploma. Defina el alcance del CMS como parte de la construcción, elegido según quién edita qué.
Tratar la migración como una tarea de la semana de lanzamiento. Sin mapa de redirecciones, posicionamiento perdido, tráfico que se desploma tras el lanzamiento. La migración es su propio proyecto con su propio responsable y puerta go/no-go. El mapa de redirecciones primero.
Confundir los dos plazos de cumplimiento. El equipo migra checkout.liquid y asume que Scripts también está resuelto, y luego la lógica de descuentos se rompe el 1 de julio de 2026. Trate Checkout Extensibility y la migración de Scripts a Functions como dos líneas de trabajo separadas con dos fechas separadas.
Lanzar sin un responsable designado. La tienda se despliega, la agencia se retira y no hay ningún ingeniero senior para mantenerla. Confirme la propiedad continua antes de empezar. Sin responsable, no hay construcción.
Medir lo que no toca. El equipo celebra una puntuación verde en Lighthouse mientras la conversión se mantiene plana. Defina la métrica de éxito en términos de negocio desde el principio y responsabilice a la construcción de cumplirla.
Medir el éxito, cómo se ve realmente el buen resultado
No puede mejorar lo que no mide, y “el sitio se siente más rápido” no es una medición. Responsabilice a la construcción de cifras, en tres capas: la capa técnica, la capa de experiencia y la capa de negocio rezagada.
Si las cifras rezagadas no se mueven, la construcción no se ganó su coste, y necesita saberlo pronto en lugar de en la próxima revisión de presupuesto. Haga seguimiento de las tres desde el lanzamiento.
La decisión go/no-go de una página que debería completar antes de gastar nada
Robe esto. Es el registro de decisión que exigiría antes de aprobar una construcción headless, basado en un simple Architecture Decision Record, la misma disciplina que uso para cualquier elección técnica de peso.
La decisión: pasarse a headless sobre Hydrogen y Oxygen, Next.js u otro. Sí o no.
El muro: ¿cuál de los cuatro muros (Experiencia, Rendimiento, Composabilidad, Descubrimiento) nos bloquea? Nómbrelo en una frase.
El coste del muro: ¿qué nos está costando hoy, en dinero o en velocidad? Si no podemos cuantificarlo, no lo hemos alcanzado.
La palanca: ¿qué métrica específica esperamos mover, y aproximadamente en cuánto?
La solución barata: ¿hemos agotado ya la pasada de velocidad en Liquid y el CRO? ¿Cuál es la evidencia?
Propiedad: ¿quién despliega el código? ¿Quién hace el merchandising sin un despliegue? ¿Quién es responsable de las redirecciones, los datos estructurados, los Core Web Vitals y los plazos de cumplimiento?
El presupuesto, con honestidad: la construcción, más la ingeniería continua, más Shopify Plus, más el CMS, más la integración. ¿La palanca lo recupera en 24 a 36 meses?
El reloj de cumplimiento: ¿estamos libres del checkout.liquid heredado, y está completa nuestra migración de Scripts a Functions antes del 30 de junio de 2026?
Si puede completar esa página con confianza, ya no está adivinando. Está decidiendo. Y eso, mucho más que qué framework elija, es lo que separa a los comerciantes que obtienen una ventaja competitiva de los que reciben una lección cara.
Conclusión: toda la guía en tres frases
Shopify headless no es un sitio web más rápido. Es una reestructuración arquitectónica que paga por un problema que puede nombrar. La construcción es un conjunto de decisiones silenciosas, a saber, arquitectura, CMS, migración, cumplimiento y propiedad, y en cada una de ellas es donde realmente se fabrica el arrepentimiento o la ventaja.
Elija acoplado y pragmático, mantenga el checkout en Shopify, despliegue de forma incremental y construya para un mundo donde las máquinas también leen su tienda. Haga eso, y el headless deja de ser una promesa que espera que dé fruto. Se convierte en una palanca que acciona a propósito.
El mercado no necesita más marcas con hermosos escaparates headless que no pueden mantener. Necesita más comerciantes que se pasaron a headless por una razón que podían nombrar.
Sea uno de ellos.