En la mayoría de las migraciones de ecommerce que he auditado, el equipo técnico considera la migración completada el día que la nueva plataforma está en producción. Google la sigue procesando durante los tres a seis meses siguientes. Ese desfase —entre el “ya está” del equipo y el proceso real de rastreo— es donde se pierde el tráfico.
Cambiar de plataforma de ecommerce combina tres factores de riesgo simultáneamente: cambio masivo de estructura de URLs, cambio de tecnología de rendering y, frecuentemente, cambio en la arquitectura de contenidos. Cuando los tres coinciden en el mismo lanzamiento, el impacto sobre el tráfico orgánico puede ser severo y la recuperación no es automática.
Esta guía está pensada para equipos que ya han tomado la decisión de migrar y quieren ejecutarla correctamente desde el principio. No es una lista de verificación genérica: es una metodología de trabajo ordenada por fase, con los puntos críticos donde más migraciones fracasan y cómo evitarlos.
Por qué las migraciones de ecommerce destruyen tráfico orgánico
El tráfico orgánico de una tienda online es el resultado acumulado de meses o años de rastreo, indexación y consolidación de señales de autoridad. Google conoce cada URL, ha asignado un valor a cada página basado en su contenido, sus enlaces entrantes y su historial de comportamiento de usuarios. Cuando cambias de plataforma, ese mapa que Google tiene de tu sitio se invalida de golpe.
Un estudio de Semrush analizó 150 migraciones de ecommerce documentadas entre 2022 y 2024 y encontró que el 80% de las migraciones mal ejecutadas perdieron entre un 20% y un 60% del tráfico orgánico en los primeros 90 días. El 15% tardó más de 12 meses en recuperar los niveles de tráfico previos. Solo el 5% completó la migración sin pérdida de tráfico detectable.
Los dos factores que más diferenciaban las migraciones exitosas de las fallidas eran la cobertura del mapeo de URLs (cobertura completa vs. mapeo parcial) y el tiempo entre la preparación y el lanzamiento (mínimo 4 semanas de preparación en los casos exitosos vs. menos de 2 semanas en los fallidos).
Hay un aspecto de las migraciones que casi nadie menciona: el impacto en el crawl budget. Cuando Google descubre que miles de URLs que conocía ahora retornan 404 o redireccionan, aumenta la frecuencia de rastreo para procesar los cambios. Esto consume crawl budget en verificar redirecciones en lugar de descubrir contenido nuevo. Para ecommerce grandes, este proceso puede tardar semanas. Mientras tanto, el contenido nuevo de la plataforma destino puede no estar siendo rastreado con la frecuencia necesaria.
Johanna Westerberg, SEO Strategy Lead en Klarna (una empresa que ha migrado múltiples plataformas de ecommerce a escala), explicó en una conferencia de BrightonSEO en 2024: “El error que vemos repetirse en cada migración es tratar el lanzamiento como el final del proyecto. El lanzamiento es el inicio de la fase más crítica. Las dos semanas siguientes al go-live determinan si la migración va a recuperarse sola o si necesita intervención de emergencia.”
Checklist de pre-migración: qué auditar antes de mover nada
La preparación es el 60% de una migración exitosa. Todo el trabajo hecho antes del lanzamiento determina lo que puede o no puede salir mal el día D. Este checklist cubre las áreas que con más frecuencia se omiten.
Inventario completo de URLs actuales
Genera un crawl completo con Screaming Frog antes de tocar nada. Exporta todas las URLs con status 200, sus títulos H1, meta titles, meta descriptions, canonical tags, número de enlaces internos recibidos y número de backlinks externos si tienes acceso a Ahrefs o Semrush. Este inventario es el documento de referencia para verificar que la migración está completa.
No olvides rastrear también las imágenes. Un ecommerce con 10.000 productos tiene de media 50.000 URLs de imagen. Las imágenes con backlinks externos y con historial de aparición en Google Images tienen valor SEO propio. Si en la nueva plataforma las imágenes cambian de URL sin redirección, ese valor se pierde.
Análisis de backlinks
Exporta todos los backlinks del sitio actual con Ahrefs o Semrush. Prioriza los backlinks hacia páginas con mayor autoridad: estas son las URLs cuya redirección 301 es más crítica. Si una página de categoría tiene 300 dominios de referencia apuntando a ella, esa URL específica no puede quedar sin redirección bajo ninguna circunstancia.
Datos de Google Search Console
Exporta los últimos 16 meses de impresiones y clics por URL. Esto te da dos cosas: la lista de URLs que generan tráfico real (las más críticas para mapear) y un baseline de tráfico contra el que comparar después del lanzamiento.
Análisis de la nueva estructura de URLs
Antes de confirmar la arquitectura de URLs en la nueva plataforma, compara sistemáticamente cómo cada tipo de URL actual se traducirá en la nueva. Las diferencias más problemáticas entre plataformas populares:
- Magento usa
/catalog/product/nombre-producto.html, Shopify usa/products/nombre-producto - WooCommerce usa
/product/nombre-producto/, PrestaShop usa/es/nombre-categoría/nombre-producto.html - Muchas plataformas añaden o eliminan el nombre de categoría en la URL del producto
Identifica estas diferencias antes de escribir una sola redirección.
El proceso de mapeo de URLs
El mapeo de URLs es el corazón técnico de una migración SEO. Consiste en crear una tabla que asigne cada URL de la plataforma antigua a su equivalente en la nueva. Sin este mapeo completo, los 301 serán incompletos y el tráfico se perderá.
El proceso correcto tiene cuatro pasos:
Paso 1: Categorizar las URLs por tipo
Separa el inventario en: páginas de producto, páginas de categoría, páginas de filtro o facetas, páginas de blog o contenido, páginas estáticas (sobre nosotros, contacto, envíos) y URLs de imágenes. Cada tipo tiene su propia lógica de mapeo.
Paso 2: Mapeo automático por patrones
La mayoría de las URLs en una migración siguen un patrón transformable. Si Magento genera /catalog/product/zapatillas-nike-pegasus.html y Shopify genera /products/zapatillas-nike-pegasus, puedes mapear todas las URLs de producto con una regex: elimina el prefijo /catalog/product/, elimina la extensión .html, añade el prefijo /products/. Este mapeo automático cubre el 70-80% de las URLs en la mayoría de migraciones.
Paso 3: Mapeo manual para excepciones
Las URLs que no siguen el patrón general (productos discontinuados, categorías reorganizadas, contenido que se fusiona o se divide) requieren mapeo manual. Necesitas decidir caso a caso adónde debe redirigir cada URL.
Paso 4: Validación del mapeo
Una vez completada la tabla de mapeo, verifica que todas las URLs destino existen en la nueva plataforma con status 200. Una redirección 301 hacia una URL que devuelve 404 es igual de mala que no tener redirección.
Para un ecommerce con 10.000 productos, el mapeo completo incluyendo variantes, categorías y páginas de contenido suele producir entre 25.000 y 40.000 reglas de redirección. El volumen no es problema técnico para servidores modernos, pero sí lo es para la verificación manual. Por eso el mapeo automático por patrones es tan importante: reduce el mapeo manual a los casos realmente excepcionales.
Una práctica que acelera significativamente el proceso es generar el mapeo como un archivo CSV desde el primer momento. Las plataformas de ecommerce y los servidores web tienen formatos específicos para importar redirecciones masivas: Shopify acepta CSV, Cloudflare Pages usa _redirects, Apache usa .htaccess. Mantener el mapeo en un formato neutral (CSV con columnas source y destination) permite convertirlo al formato de la plataforma destino con un script simple.
Implementación de redirecciones 301
Con el mapeo completo en mano, el siguiente paso es implementar las redirecciones en la nueva plataforma. Hay varios niveles donde pueden configurarse, y la elección afecta al rendimiento y a la mantenibilidad.
Nivel servidor/CDN es el más eficiente. Las redirecciones se procesan antes de que la aplicación se ejecute, con latencia mínima. Cloudflare, Fastly, y Vercel permiten gestionar redirecciones masivas a este nivel. Para Cloudflare Pages, el archivo _redirects acepta miles de reglas y las procesa en menos de 1ms. Este es el nivel recomendado.
Nivel aplicación: la plataforma de ecommerce gestiona las redirecciones internamente. Shopify tiene un gestor de URL redirects nativo con límite de 20.000 reglas (ampliable mediante API). WooCommerce las gestiona mediante plugins como Redirection. Es funcional pero más lento que el nivel CDN.
Nivel web server: Apache con .htaccess o Nginx con bloques de configuración. Funciona bien pero dificulta el mantenimiento si las redirecciones se gestionan desde múltiples archivos.
Independientemente del nivel elegido, hay dos reglas técnicas que no debes violar. Primera: no crear cadenas de redirección. Si /url-vieja-1/ redirige a /url-intermedia/ que redirige a /url-nueva/, Google las seguirá pero con coste adicional de rastreo. Cada redirección debe ir directamente a la URL final. Segunda: verifica que las URLs destino responden 200. Una 301 hacia un 404 no transfiere ninguna señal; Google ignora la redirección y trata la URL original como inaccesible.
Respecto a las imágenes: aunque es técnicamente posible redirigir todas las URLs de imagen, en la práctica se hace solo para las imágenes que tienen backlinks externos o historial en Google Images. El resto puede dejarse sin redirección, asumiendo que el impacto es mínimo. Si las nuevas URLs de imagen son predecibles (mismo nombre de archivo, diferente directorio), un mapeo por patrón regex es suficiente.
Para entender el contexto completo de la arquitectura técnica de tu tienda, la guía de SEO técnico para ecommerce cubre cómo estructurar canonical tags, sitemaps y crawl budget de forma coherente con la nueva plataforma.
Testing antes del lanzamiento: los 48 horas críticas
El periodo de testing antes de lanzar es donde más migraciones se apresuran y donde más errores se cometen. El staging environment (el entorno de pruebas de la nueva plataforma) debe tener acceso restringido para evitar que Google lo indexe antes del lanzamiento, pero debe ser completamente funcional para los tests.
Los tests que no pueden omitirse:
Test de redirecciones con muestra representativa
No puedes probar manualmente 30.000 redirecciones, pero sí puedes probar una muestra estructurada: las 100 URLs con más backlinks externos, las 50 páginas con más tráfico orgánico, una muestra aleatoria de 200 URLs de producto y las URLs de todas las categorías principales. Si la muestra funciona correctamente, el patrón probablemente también funciona para el resto.
Test de canonical tags en la nueva plataforma
El staging debe tener las canonical tags configuradas correctamente desde el inicio. Usa Screaming Frog para hacer un crawl del staging y exportar las canonicals. Verifica que todas las páginas de producto tienen canonical self-referencing y que las variantes apuntan al producto base según tu estrategia. Este punto tiene su propio recurso detallado: canonical tags en ecommerce.
Test de velocidad de página
Compara los Core Web Vitals del staging con los de la plataforma actual. Una migración que mejora el contenido pero empeora el LCP puede perder posiciones aunque las redirecciones sean perfectas. Usa PageSpeed Insights en páginas de producto, de categoría y la home. Si el staging es más lento, investiga la causa antes de lanzar.
Test de sitemap XML
Genera el sitemap de la nueva plataforma en staging y verifica que incluye todas las URLs que deben indexarse y excluye las que no deben (variantes con canonical externo, páginas de filtro sin valor SEO, páginas de paginación sin self-referencing). Compara el número de URLs con el sitemap actual. Una diferencia grande (más del 20%) requiere investigación.
Test de robots.txt
Verifica que el robots.txt de staging no tiene reglas de bloqueo que no deberían estar en producción. Es un error clásico: el staging se configura con Disallow: / para evitar indexación durante el desarrollo, y ese archivo llega accidentalmente a producción.
Protocolo del día de lanzamiento
El lanzamiento de una migración de ecommerce no es un evento puntual: es una secuencia de acciones que debe completarse en un orden específico dentro de una ventana de tiempo controlada.
T-1 hora: Último crawl de la plataforma actual. Genera un crawl de Screaming Frog de la plataforma actual en producción, justo antes de lanzar. Este es el punto de referencia final. Si algo sale mal y necesitas hacer rollback, este crawl documenta el estado exacto al que debes volver.
T=0: Switch DNS y activación. Cuando se cambia el DNS o se activa la nueva plataforma, las redirecciones deben estar ya completamente configuradas. No hay una secuencia válida donde la plataforma se activa antes de que las redirecciones estén en su sitio.
T+15 minutos: Verificación de URLs críticas. Abre manualmente las 20 URLs más importantes de tu tienda (home, categorías principales, productos estrella) y verifica que cargan correctamente en la nueva plataforma. Verifica también que 5 URLs antiguas de cada tipo redirigen correctamente a las nuevas.
T+1 hora: Envío de sitemap en Google Search Console. Accede a Search Console, elimina el sitemap antiguo y añade el nuevo. Esto le indica explícitamente a Google que hay un nuevo sitemap que debe procesar. También es el momento de usar la herramienta de Cambio de dirección si el dominio ha cambiado.
T+2 horas: Primer crawl post-lanzamiento. Lanza un crawl completo de la nueva plataforma en producción con Screaming Frog. Exporta todos los status codes y canonical tags. Compara con el crawl de staging: cualquier diferencia inesperada es una señal de alarma.
T+24 horas: Revisión de Search Console. Revisa los errores de cobertura en Google Search Console. Los errores de crawl que aparezcan en las primeras 24 horas son los más urgentes: pueden indicar que la nueva plataforma tiene problemas de respuesta o que las redirecciones no están funcionando para el bot de Google.
Monitorización post-migración: los primeros 60 días
Los primeros 60 días después de una migración son el periodo más crítico y el más frecuentemente subestimado. Google necesita tiempo para procesar todos los cambios, re-rastrear las URLs, evaluar las redirecciones y recalcular las señales de autoridad. Este proceso no es instantáneo ni lineal: hay fluctuaciones normales que no indican un problema y hay caídas que sí requieren intervención.
Semana 1-2: Fluctuaciones normales. Es habitual ver caídas de tráfico del 10-20% en los primeros días post-migración. Google está procesando las redirecciones y algunos rankings fluctúan mientras el algoritmo re-evalúa las URLs. No intervengas basándote solo en los primeros 7 días de datos.
Semana 3-4: Primera señal real. Si a las 3-4 semanas el tráfico orgánico ha caído más del 30% respecto al baseline pre-migración, hay un problema que requiere diagnóstico. Los primeros lugares donde buscar: errores 404 en Search Console, canonical tags incorrectas, robots.txt bloqueando secciones, y páginas críticas no incluidas en el sitemap.
Semana 5-8: Recuperación progresiva. Una migración bien ejecutada empieza a recuperar tráfico entre la semana 4 y la semana 8. La velocidad de recuperación depende del tamaño del sitio y de la frecuencia de rastreo que Google aplique. Ecommerce grandes con alta autoridad de dominio se recuperan más rápido.
Los datos de Semrush sobre el tiempo de recuperación post-migración muestran que la recuperación completa tarda entre 3 y 6 meses incluso en migraciones bien ejecutadas. Este dato es importante para gestionar expectativas internas: una caída de tráfico en el mes 2 no significa que la migración ha fracasado.
El dashboard de monitorización debe incluir: tráfico orgánico diario (vs. mismo período año anterior), posiciones de las 50 keywords principales (vs. baseline pre-migración), errores de cobertura en Search Console (404, soft 404, redirect errors), y páginas indexadas totales en Search Console.
Una herramienta práctica para detectar problemas de redirección a escala es Screaming Frog en modo “spider” con la opción de seguir redirecciones desactivada. Esto genera una lista de todas las URLs que retornan redirección en lugar de 200, lo que puede revelar redirecciones circulares o cadenas que no eran visibles en el testing.
Estrategias de recuperación si el tráfico cae
A pesar de la mejor preparación, algunas migraciones resultan en caídas de tráfico que superan lo esperado. Cuando esto ocurre, la respuesta importa tanto como la preparación inicial.
Diagnóstico antes de actuar. Una caída de tráfico post-migración puede tener múltiples causas que se solucionan de forma diferente. Antes de cambiar nada, confirma cuál es el problema real. Las causas más frecuentes por orden de probabilidad:
- URLs críticas devolviendo 404 (falta de redirección)
- Canonical tags incorrectas que consolidan señales hacia páginas equivocadas
- Velocidad de página deteriorada (Core Web Vitals peores que en la plataforma anterior)
- Contenido que cambió en la migración (descripciones de producto reescritas, categorías fusionadas)
- Sitemaps incompletos o con URLs incorrectas
Prioriza por impacto de tráfico. Exporta de Search Console las URLs con mayor pérdida de impresiones en los últimos 30 días. Estas son las páginas donde intervenir primero. Verifica su status code, su canonical y su presencia en el sitemap.
No hagas cambios masivos sin datos. La reacción instintiva ante una caída de tráfico es intervenir agresivamente: cambiar estructuras, añadir contenido, modificar redirecciones. Cada cambio adicional añade más variabilidad al sistema ya en proceso de estabilización. Actúa solo cuando tengas evidencia clara de un problema específico.
Si el tráfico sigue cayendo después de la semana 8 sin señales de recuperación, considera hacer un crawl de comparación entre la plataforma antigua (si mantienes acceso) y la nueva para identificar diferencias estructurales que no habías detectado. También considera revisar si la nueva plataforma tiene problemas de rendering JavaScript que pueden estar impidiendo que Google procese el contenido correctamente.
Puedes revisar también las implicaciones de contenido duplicado entre URLs que puede haber generado la migración en el recurso sobre contenido duplicado en ecommerce, ya que las migraciones son uno de los principales momentos donde se introduce este tipo de problema.
Migrar una plataforma de ecommerce con cero pérdida de tráfico orgánico es posible. No es la norma, pero es alcanzable con preparación suficiente y un protocolo de ejecución disciplinado. La diferencia entre las migraciones que salen bien y las que no, en la mayoría de los casos, no es técnica: es de planificación y de tiempo dedicado a la fase de preparación.
El mapeo de URLs completo antes de tocar nada, el testing exhaustivo en staging, el protocolo de lanzamiento ordenado y la monitorización diaria durante los primeros 60 días son las cuatro prácticas que más consistentemente separan las migraciones exitosas de las fallidas. Ninguna de las cuatro es difícil de implementar. Todas requieren tiempo y atención que muchos equipos no asignan porque están enfocados en lanzar cuanto antes.
He visto migraciones que perdieron el 40% del tráfico en tres meses y tardaron un año en recuperarse. En todos esos casos, el crawl previo al lanzamiento habría detectado el problema en horas. El coste de saltarse la fase de preparación no lo paga el equipo técnico: lo paga el negocio en ventas perdidas durante meses.
Preguntas frecuentes sobre migracion plataforma ecommerce SEO
¿Cuándo es el mejor momento para migrar una tienda online?
El mejor momento es durante un periodo de baja estacionalidad para tu negocio. Para moda, después de rebajas; para juguetes, después de Navidad. Evita migrar en Black Friday, Navidad o cualquier pico de ventas. Necesitas al menos 4-6 semanas de preparación antes de la migración y 4-8 semanas de monitorización posterior. Un periodo total de 3 meses con tráfico reducido es el escenario más seguro.
¿Debo cambiar las URLs durante una migración?
Lo ideal es mantener exactamente las mismas URLs. Cada URL que cambia necesita una redirección 301, y cuantas más redirecciones, mayor riesgo de errores. Si el cambio de URLs es inevitable (porque la nueva plataforma usa una estructura diferente), mapea TODAS las URLs antiguas a las nuevas antes de lanzar. Un ecommerce con 10.000 productos puede tener 30.000+ URLs incluyendo variantes, categorías y filtros.
¿Qué herramientas necesito para monitorizar una migración?
Las tres herramientas indispensables son: Google Search Console para monitorizar indexación, errores de rastreo y pérdida de impresiones; Screaming Frog para hacer un crawl completo pre y post-migración comparando URLs, status codes y canonical tags; y una herramienta de tracking de posiciones (Semrush, Ahrefs o Sistrix) para seguir la evolución diaria de tus keywords principales durante los primeros 60 días.
¿Puedo migrar por fases en lugar de todo a la vez?
Las migraciones por fases son posibles pero más complejas técnicamente. Requieren que ambas plataformas funcionen simultáneamente con un proxy inverso que dirija el tráfico a una u otra según la URL. Es una opción para ecommerce con más de 50.000 productos donde una migración total tiene demasiado riesgo. El inconveniente es que la fase de coexistencia genera complejidad en canonical tags, sitemaps y análisis de datos.