Un cliente llegó a mí a principios de 2022 — marca de moda de tamaño medio, alrededor de 40,000 sesiones orgánicas mensuales, autoridad de dominio decente, llevaban cuatro años en Shopify. Habían contratado a una agencia de desarrollo para reconstruir todo en Next.js con Shopify Storefront API. El sitio nuevo era hermoso. Genuinamente rápido. Y dentro de seis semanas de estar en vivo, habían perdido el 38% de su tráfico orgánico.
Punto clave: las migraciones a Shopify headless protegen los rankings de la misma manera que cualquier migración: mapeo completo de redirecciones, transporte byte-idéntico de metadatos, y un presupuesto de Core Web Vitals en la nueva compilación.Headless Shopify migrations protect rankings the same way every migration does: full redirect map, byte-identical metadata transport, and a Core Web Vitals budget on the new build.
Nadie había hecho una auditoría de redirecciones. El sitemap estaba roto. Las etiquetas canónicas apuntaban al ambiente incorrecto. Fue un desastre, y les costó aproximadamente £60,000 en ingresos antes de que estabilizáramos las cosas.
Las migraciones headless son uno de esos cambios que parecen una victoria técnica pura — renderizado más rápido, front-end desacoplado, libertad total de diseño — pero si tratas el SEO como algo secundario, lo pagarás. Muy caro. He trabajado en más de 12,000 sitios en Seahawk y he visto este patrón repetirse suficientes veces como para querer escribirlo todo correctamente.look like a pure technical win -- faster rendering, decoupled front-end, total design freedom -- but if you treat SEO as an afterthought, you'll pay for it. Badly. I've worked on 12,000+ sites at Seahawk and I've seen this pattern repeat itself enough times that I wanted to write it all down properly.
---
Por Qué Shopify Headless Rompe el SEO en Primer Lugar
La arquitectura estándar de temas en Shopify maneja mucho del trabajo pesado de SEO sin que lo notes. Las etiquetas canónicas se generan automáticamente. El sitemap.xml en /sitemap.xml se mantiene automáticamente. Los datos estructurados para productos vienen integrados a través de Liquid. La paginación usa las convenciones rel="next" y rel="prev" que Shopify gestiona silenciosamente en segundo plano./sitemap.xml is maintained automatically. Structured data for products comes baked in via Liquid. Pagination uses rel="next" and rel="prev" conventions that Shopify manages quietly in the background.
En el momento en que vas headless — típicamente con un framework como Next.js, Nuxt, Remix o SvelteKit obteniendo datos de Shopify Storefront API — eres responsable de todo eso. Cada canonical. Cada hreflang. Cada bloque de datos estructurados. Cada redirección. Ya no viene gratis.Next.js, Nuxt, Remix, or SvelteKit pulling data from the Shopify Storefront API -- you own all of that. Every canonical. Every hreflang. Every structured data block. Every redirect. It doesn't come for free anymore.
Y aquí está el punto: la mayoría de los equipos de desarrollo se contratan porque son buenos con React. No porque sepan cómo se ve una trampa de rastreo de navegación facetada.
Los tres modos de fallo que veo constantemente
- URLs del entorno de staging filtrándose en los índices de producción. El equipo de desarrollo construye en staging.mybrand.com o en una URL de vista previa de Vercel, se olvida de ponerle noindex correctamente, Google la rastrea, y de repente tienes contenido duplicado compitiendo con tu sitio activo. The dev team builds on
staging.mybrand.comor a Vercel preview URL, forgets tonoindexit properly, Google crawls it, and suddenly you have duplicate content competing with your live site. - Redirecciones rotas o faltantes durante la reestructuración de URLs. Los proyectos headless casi siempre implican cambios de URL. /collections/mens-shirts se convierte en /category/shirts o algo peor. Sin los 301s en su lugar, cada enlace entrante y cada URL indexada por Google devuelve un 404. Headless projects almost always involve URL changes.
/collections/mens-shirtsbecomes/category/shirtsor something worse. Without 301s in place, every inbound link and every Google-indexed URL returns a 404. - La renderización del lado del cliente matando la rastreabilidad. Si tu front-end headless está renderizando contenido de productos puramente del lado del cliente sin SSR o SSG, es posible que Googlebot no esté capturando tu contenido de manera confiable. Google puede renderizar JavaScript, pero se procesa en una segunda onda y hay retraso en la indexación. Para catálogos grandes, ese retraso te cuesta. If your headless front-end is rendering product content purely client-side without SSR or SSG, Googlebot may not be picking up your content reliably. Google can render JavaScript, but it's processed in a second wave and there's indexing lag. For large catalogues, that lag costs you.
---
La auditoría previa a la migración que no puedes saltarte
Seré directo: si no has hecho esto antes de ir en vivo, ya estás retrasado. Pero nunca es demasiado tarde.
Antes de que cambie un solo registro DNS, quiero tener cuatro cosas listas.
1. Un rastreo completo del sitio Shopify existente. Usa Screaming Frog (lo ejecuto localmente aquí en Londres en una máquina dedicada — no rastreo en la nube, local, para poder captar todo incluyendo páginas renderizadas con JavaScript). Exporta cada URL, código de estado, title tag, meta description, canonical y H1. Este es tu punto de referencia. Es tu foto del antes. Use Screaming Frog (I run it locally here in London on a dedicated machine -- not cloud crawl, local, so I can catch everything including JavaScript-rendered pages). Export every URL, status code, title tag, meta description, canonical, and H1. This is your baseline. It's your before-photo.
2. Un documento de mapeo. Cada URL antigua → URL nueva. No solo páginas de categoría y producto. Publicaciones de blog. Páginas de etiquetas. Páginas de guía de tallas. La URL /pages/about que tiene 47 enlaces de retorno de esa mención de prensa en 2020. Cada URL que tenga historial de rastreo, enlaces de retorno o palabras clave posicionadas necesita estar en esta hoja de cálculo. Every old URL → new URL. Not just category and product pages. Blog posts. Tag pages. Size guide pages. The /pages/about URL that has 47 backlinks from that press mention in 2020. Every URL that has crawl history, backlinks, or ranking keywords needs to be in this spreadsheet.
3. Una exportación de enlaces de retorno desde Ahrefs o SEMrush. Filtra a páginas con al menos un dominio de referencia. Estos son tus objetivos de redirección de máxima prioridad. Pierde un 301 en una página con 12 dominios de referencia y habrás eliminado una porción significativa de autoridad de enlace. Filter to pages with at least one referring domain. These are your highest-priority redirect targets. Miss a 301 on a page with 12 referring domains and you've just deleted a meaningful chunk of link equity.
4. Captura de posicionamiento de palabras clave. Exporta tus posicionamientos actuales de Google Search Console — como mínimo, las 200 consultas principales por volumen de clics. Necesitas esto para poder comparar antes y después de la migración. Si "pantalones de lino para hombre" cae de la posición 4 a la posición 22 después del lanzamiento, necesitas poder detectarlo inmediatamente. Export your current rankings from Google Search Console -- at minimum, the top 200 queries by click volume. You need this so you can compare pre- and post-migration. If "mens linen trousers" drops from position 4 to position 22 after go-live, you need to be able to spot that immediately.
---
Implementar Redirecciones en una Configuración Headless
Aquí es donde se pone un poco técnico, pero quédate conmigo.
En una configuración Shopify estándar, administras redirecciones dentro del panel de Shopify. En una configuración headless, tu framework front-end maneja el enrutamiento — lo que significa que las redirecciones viven en algún lugar diferente dependiendo de tu objetivo de despliegue.
Si estás en Vercel (que es donde terminan la mayoría de proyectos Next.js headless con Shopify), tus redirecciones van en vercel.json bajo el array de redirects. Maneja 301s de forma limpia y la red edge de Vercel las aplica antes de que la página se renderice, que es exactamente lo que quieres para SEO — la redirección sucede en la capa de infraestructura, no en JavaScript.vercel.json under the redirects array. It handles 301s cleanly and Vercel's edge network applies them before the page even renders, which is exactly what you want for SEO -- the redirect happens at the infrastructure layer, not in JavaScript.
Si estás en Netlify, la misma idea — netlify.toml o un archivo _redirects.Netlify, same idea -- netlify.toml or a _redirects file.
Si haces self-hosting en algo como AWS CloudFront o un servidor Node personalizado, necesitarás implementar redirecciones a nivel de reverse proxy. No lo hagas en React router. Las redirecciones a nivel edge son las que transmiten link equity de forma limpia.
Una cosa que siempre hago: después de implementar cada redirección, ejecuto una verificación en lote a través de httpstatus.io para validar la cadena. Una cadena 301 → 301 → 200 es mala. Quieres 301 → 200. Las cadenas de redirección pierden link equity y ralentizan las cosas.httpstatus.io to verify the chain. A 301 → 301 → 200 chain is bad. You want 301 → 200. Redirect chains bleed link equity and slow things down.
---
Canonicals, Datos Estructurados, y los Detalles que los Equipos Olvidan
En 2023, Seahawk tuvo que migrar una marca DTC de skincare a una configuración headless de Hydrogen (el propio framework React de Shopify). Los desarrolladores habían hecho un buen trabajo con los redirects. Pero se olvidaron de que Hydrogen no genera automáticamente canonical tags -- tienes que configurarlos manualmente en el <head> usando el componente SEO de Hydrogen. El resultado: cada página de producto se canonicalizaba a sí misma con los parámetros de query string adjuntos, porque la lógica del carrito y los filtros estaba escribiendo params en la URL. Google estaba viendo cientos de páginas de producto prácticamente duplicadas.<head> using Hydrogen's SEO component. Result: every product page was canonicalising to itself with the query string parameters appended, because the cart and filter logic was writing params into the URL. Google was seeing hundreds of near-duplicate product pages.
La corrección tomó alrededor de un día una vez que la encontramos, pero la volatilidad de rankings que causó tardó aproximadamente tres semanas en estabilizarse.
Qué verificar manualmente antes del lanzamiento
- Las etiquetas canonical en páginas de productos apuntan a la URL limpia (sin query strings, sin parámetros UTM).
noindex va en tu ambiente de staging y en cualquier URL de preview de Vercel/Netlify -- agrega esto a tu checklist de deployment, no a tu lista de tareas.is on your staging environment and any Vercel/Netlify preview URLs -- add this to your deployment checklist, not your to-do list.- Los datos estructurados del producto (tipo Product de Schema.org) se renderizan en el servidor dentro del <head>, no se inyectan mediante un script del lado del cliente después de la hidratación.Schema.org
Producttype) is being server-rendered in the<head>, not injected by a client-side script after hydration. - Tu robots.txt es accesible en el dominio raíz y no está bloqueando a Googlebot de tus nuevos patrones de URL.
robots.txtis reachable at the root domain and isn't blocking Googlebot from your new URL patterns. - El XML sitemap refleja la nueva estructura de URLs -- no el antiguo sitemap de Shopify, ni una versión en caché de tu proceso de build.
---
Core Web Vitals: La Espada de Doble Filo
Este es el argumento que la mayoría de agencias usan cuando venden headless: "Mejorará tus Core Web Vitals". Y no están equivocadas -- potencialmente. Un front-end de Next.js bien construido con optimización de imágenes, caching en edge y proper code splitting puede genuinamente lograr verde en las tres métricas de Core Web Vitals.potentially. A well-built Next.js front-end with image optimisation, edge caching, and proper code splitting can genuinely hit green across all three Core Web Vitals metrics.
Pero he visto migraciones headless que empeoraron el CWV. Específicamente LCP (Largest Contentful Paint) y CLS (Cumulative Layout Shift).worse. Specifically LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift).
LCP empeora cuando la imagen hero o la imagen del producto above-the-fold no se está precargando correctamente. En una configuración headless, tu image pipeline es tu propia responsabilidad. Ya no dependerás de la CDN de Shopify -- necesitas asegurarte de que tu framework está usando priority flags en imágenes hero (en Next.js, eso es la prop priority en <Image>) y que estás sirviendo imágenes con el tamaño correcto a través de una CDN como Cloudflare o Fastly.priority flags on hero images (in Next.js, that's the priority prop on <Image>) and that you're serving correctly sized images via a CDN like Cloudflare or Fastly.
CLS empeora cuando las fuentes o el contenido dinámico (especialmente el estado del carrito drawer, banners promocionales o chips de filtros) causan cambios de diseño durante la hidratación. Los temas de Shopify manejan esto razonablemente bien de fábrica. Tu front-end headless personalizado no lo hará, a menos que alguien específicamente lo diseñe para ello.
Prueba con PageSpeed Insights en tu URL de staging antes del go-live, no después. Usa field data del Chrome UX Report si el sitio ha estado en staging el tiempo suficiente para acumularlos. Y verifica en mobile -- ese es el dato que Google realmente usa para rankear.PageSpeed Insights on your staging URL before go-live, not after. Use field data from Chrome UX Report if the site has been in staging long enough to accumulate it. And check on mobile -- that's the data Google actually uses for ranking.
---
Presupuesto de rastreo y catálogos grandes
Si tienes menos de 5,000 URLs de producto, el crawl budget probablemente no sea tu preocupación principal. Pero si estás migrando un catálogo con 50,000+ SKUs, navegación facetada, múltiples variantes de moneda/región, y un blog que se remonta a 2015 -- necesitas pensar en esto.
Los setups headless a menudo crean más URLs que el setup de Shopify que están reemplazando. Los filtros facetados que antes se manejaban mediante AJAX con noindex en Shopify ahora obtienen sus propias rutas renderizadas en el servidor si alguien no ha pensado cuidadosamente en el manejo de parámetros de URL. De repente, Googlebot intenta rastrear un sitio de 200,000 URLs cuando antes tenías 30,000.more URLs than the Shopify setup they're replacing. Faceted filters that were previously handled via AJAX with noindex in Shopify now get their own server-rendered routes if someone hasn't thought carefully about URL parameter handling. Suddenly Googlebot is trying to crawl a 200,000-URL site when you had 30,000 before.
Mantén tu robots.txt ajustado. Desactiva el crawling de patrones de URLs filtradas que no representen contenido único y rankeable. Usa rel="canonical" en páginas filtradas para apuntar de vuelta a la categoría raíz. Y no crees rutas individuales del lado del servidor para cada combinación de facetas -- ese camino lleva a la locura y al desperdicio de crawl.robots.txt tight. Disallow crawling of filtered URL patterns that don't represent unique, rankable content. Use rel="canonical" on filtered pages to point back to the root category. And don't create individual server-side routes for every facet combination -- that way lies madness and crawl waste.
---
Monitoreo posterior a la migración (la parte que la gente deja de hacer después de la segunda semana)
La migración se activa, el cliente da su visto bueno, todos celebran. Y luego nadie revisa Search Console durante un mes. No hagas eso.
Configura una exportación semanal de datos de GSC durante los primeros tres meses como mínimo. Rastrea impressions, clicks, posición promedio y cobertura de índice. Vigila caídas en el índice -- si tu conteo de páginas indexadas cae repentinamente de 8,000 a 4,200, algo está mal y necesitas encontrarlo antes de que Google decida que esas páginas desaparecieron para siempre.
También configuré un monitor de uptime (yo uso Better Uptime) en la URL del sitemap -- tudominio.com/sitemap.xml. Si empieza a devolver un 500 durante un deployment, quieres saberlo inmediatamente, no tres días después cuando notes que los rankings están bajando.yourdomain.com/sitemap.xml. If it starts returning a 500 during a deployment, you want to know immediately, not three days later when you notice rankings sliding.
Una cosa más: vuelve a enviar tu sitemap en Search Console después del lanzamiento. Obvio, tal vez. Pero lo he visto olvidarse más veces de las que me gustaría admitir.
---
FAQ
¿Ir headless siempre daña el SEO al principio?
No siempre, pero casi siempre hay algo de volatilidad en el ranking durante las primeras cuatro a ocho semanas mientras Google vuelve a rastrear e indexar la nueva configuración. Si tus redirecciones son sólidas, tus canonicals son correctos y tus datos estructurados están intactos, típicamente se estabiliza y a menudo mejora. El peligro es cuando las migraciones se hacen apresuradamente -- es ahí cuando la volatilidad a corto plazo se convierte en pérdida a largo plazo.
¿Puedo usar el framework Hydrogen de Shopify y aún mantener un buen SEO?
Sí. Hydrogen utiliza server-side rendering por defecto, que es la base correcta para SEO. Las brechas están en los detalles -- manejo de canonicals, generación de sitemaps y datos estructurados. Shopify sí proporciona una utilidad de SEO en la librería de componentes de Hydrogen, pero no es magia. Aún necesitas a alguien que entienda qué está haciendo y por qué.
¿Cuánto tiempo tarda en recuperarse el ranking después de un problema de migración?
Honestamente, depende de la gravedad. Un redirect faltante en un puñado de páginas podría corregirse solo en algunas semanas una vez lo arregles. Un error de canonical en todo el sitio o un noindex accidental en tu dominio completo puede tomar dos a cuatro meses para recuperarse, a veces más para términos altamente competitivos. Cuanto antes lo detectes y lo arregles, más corta será la recuperación.noindex on your entire domain can take two to four months to recover from, sometimes longer for highly competitive terms. The sooner you catch and fix it, the shorter the recovery.
¿Vale la pena ir headless solo desde el punto de vista del SEO?
No. Headless vale la pena por el rendimiento, la flexibilidad y la experiencia del desarrollador front-end. SEO es un factor neutral si migras correctamente. No dejes que una agencia te venda headless destacando beneficios de SEO -- las mismas ganancias de rendimiento a menudo pueden lograrse con un tema de Shopify 2.0 bien optimizado y una configuración sólida de CDN, a una fracción del costo.if you migrate correctly. Don't let an agency sell you headless by leading with SEO benefits -- the same performance gains can often be achieved with a well-optimised Shopify 2.0 theme and a solid CDN setup, at a fraction of the cost.
---
Las migraciones no son lanzamientos. Son transferencias de confianza -- de un entorno antiguo que Google conoce bien a uno nuevo que no conoce. Trata cada detalle técnico como si importara, porque para tu canal de búsqueda orgánica, importa.