El benchmark del sector para la caída de tráfico orgánico tras la migración de una tienda es del 15–30% en los tres primeros meses, con una recuperación al nivel original a lo largo de los 6–12 siguientes. Para una tienda que factura entre varios y más de diez millones de PLN al año esto no es una estadística: es un trimestre o dos por debajo del plan, contable en margen perdido.
En nuestras migraciones la caída media es inferior al 3%. Esa diferencia no viene de mejores herramientas ni de magia: viene del orden de las acciones. A continuación mostramos por qué las migraciones borran el tráfico orgánico y el proceso concreto SEO-first con el que mantenemos la pérdida por debajo del 3%. Al final encontrarás una lista de preguntas con las que comprobar a tu propio proveedor antes de firmar un contrato.
Por qué una migración borra el tráfico orgánico: seis mecanismos
El tráfico orgánico no desaparece el día del cambio por un abstracto «cambio de plataforma». Desaparece por seis mecanismos técnicos concretos. Todos son evitables, siempre que te ocupes de ellos antes de la implantación y no después.
1. Las URL antiguas empiezan a devolver 404
Cada plataforma construye las direcciones de forma distinta. Lo que en PrestaShop era /123-nombre-del-producto.html se convierte en Shopify en /products/nombre-del-producto. Si la dirección antigua no recibe una redirección 301 a la nueva, devuelve un 404. Después de unas cuantas visitas Google la elimina del índice y con ella desaparece toda la fuerza histórica de enlaces —externos e internos— que esa página había acumulado durante años. Es la mayor causa individual de caídas.
2. Las redirecciones existen, pero están mal hechas
La simple presencia de una 301 no basta. Cadenas de redirecciones (301 → 301 → 200), bucles o —el clásico— redirigir todas las direcciones antiguas a la página principal en lugar de a la subpágina correspondiente. Esto último Google lo trata como un «soft 404» y no transmite fuerza. El mapa de redirecciones tiene que ser uno a uno: una URL antigua concreta a una nueva concreta con la misma intención.
3. Los metadatos y los datos estructurados vuelven a los valores por defecto
La nueva plataforma genera sus propias etiquetas title, meta description y H1, normalmente de plantilla. Desaparecen los títulos trabajados, las canónicas empiezan a apuntar a direcciones equivocadas y el schema.org (Product, Offer, BreadcrumbList, Review) no se reconstruye. El efecto: pierdes los rich results en los resultados de búsqueda —estrellas, precios, disponibilidad—. La posición puede quedarse igual y el CTR caer, porque tu resultado de pronto se ve más pobre que el de la competencia.
4. Cambian el renderizado y el rendimiento
Migrar a headless o a una aplicación de una sola página traslada a menudo el renderizado al lado del cliente (JavaScript). Si el contenido no se renderiza en el servidor, Googlebot ve una página vacía en su primer paso. A eso se añaden las Core Web Vitals: un TTFB y un LCP más lentos son un problema real —un TTFB por encima de 500 ms correlaciona con una caída de la conversión del 5–10%— y Google indexa con menos frecuencia las páginas lentas.
5. Se desperdicia el crawl budget
Tras el cambio, Googlebot se topa con miles de redirecciones, páginas 404 y duplicados. Con un catálogo de decenas de miles de direcciones, el bot quema su presupuesto de rastreo volviendo a visitar basura en lugar de indexar páginas nuevas. Cuanto mayor es la tienda, más esperan las direcciones nuevas a ser indexadas, y una página sin índice no genera tráfico.
6. Inestabilidad temporal del índice
Incluso una migración perfecta provoca de 2 a 6 semanas de «reordenación»: Google rastrea, renderiza y evalúa las páginas de nuevo. Las posiciones oscilan. El mayor riesgo en esta etapa es el pánico: el equipo empieza a cambiar cosas a mitad del proceso, con lo que la evaluación arranca desde cero. Un buen proceso no elimina esta fase, pero la acorta y aplana su amplitud.
SEO-first significa: el SEO decide primero, no repara al final
La mayoría de las agencias llevan la migración primero en lo técnico. Primero se crea la tienda, se trasladan los datos y el SEO entra al final, como capa reparadora, cuando la caída ya se ve en Google Search Console. En ese orden el mapa de redirecciones nace bajo presión y a posteriori, y los metadatos y el schema quedan «para cuando haya un rato».
Nosotros invertimos ese orden. Cada sprint empieza con una decisión de SEO y solo después con una técnica. La estructura de URL de la nueva tienda se diseña antes de que exista la primera línea de código de frontend, no se descubre después del lanzamiento. Es un único cambio en el proceso, pero es el responsable de la diferencia entre una caída del 15–30% y una caída por debajo del 3%.
SEO-first no significa «congela todo tal como estaba». A veces la estructura de URL antigua es mala y conviene corregirla: jerarquía de categorías plana, parámetros duplicados, direcciones con ID en lugar de palabras clave. La diferencia es que en el enfoque SEO-first cada cambio así es una decisión consciente con una redirección asignada, y no un efecto secundario accidental de la nueva plataforma. Cambias lo que quieres cambiar y sabes exactamente a dónde lleva cada dirección antigua.
Si el proveedor trata el SEO como una etapa posterior a la implantación, una caída del 15–30% no es un riesgo: está inscrita en el plan. La única pregunta es cuándo la verás.
El proceso SEO-first paso a paso
A continuación, el recorrido real, el mismo para una migración de PrestaShop a Shopify Plus y para reescribir PHP legacy en Symfony. Cambia la duración, no el orden.
Paso 1 — Auditoría y baseline de SEO (semana 1–2)
Auditoría completa de la tienda actual: estructura de URL, páginas indexables, enlazado interno, schema markup, Core Web Vitals. Además, un baseline de tráfico de Google Search Console y Ahrefs. Se genera un documento «Qué conservamos sin excepción»: una lista de las 200–500 direcciones más importantes por tráfico y conversión. Sin esa lista, la migración se hace a ciegas.
Paso 2 — Arquitectura de la información y mapeo de URL (semana 2–4)
Diseñamos la estructura de la nueva tienda con un mapeo uno a uno para todas las páginas indexadas. El detalle clave: cada URL la valida un especialista en SEO, no solo un programador. El mapa de redirecciones nace justo aquí, antes de la implantación, y pasa a las pruebas de regresión, no a un backlog «para después del lanzamiento».
Paso 3 — Desarrollo con pruebas de SEO después de cada sprint (semana 4–18)
Desarrollo iterativo con validación en staging. Después de cada sprint de dos semanas lanzamos pruebas automáticas de SEO: corrección del mapeo de redirecciones, presencia de schema markup, Core Web Vitals, indexabilidad. Además, una revisión manual por parte de un especialista en SEO. Una regresión detectada en staging en la semana 8 cuesta una hora de trabajo; la misma regresión detectada en producción tras el lanzamiento cuesta posiciones.
Paso 4 — Cutover en una ventana de bajo tráfico (fin de semana)
La migración productiva se hace en la ventana de menor tráfico —normalmente la noche del domingo— con un plan de rollback listo y monitorización 24/7 durante las primeras 72 horas. El cambio se produce sin interrumpir las ventas: los clientes compran durante todo el proceso. Subir cambios un viernes por la tarde o en el pico de ventas es un riesgo innecesario que eliminas con la simple elección de la fecha.
Paso 5 — 90 días de monitorización tras la implantación (incluidos)
Tras el cutover empieza la fase en la que se gana o se pierde la mayor parte del tráfico. Durante 90 días hay informes semanales de tráfico orgánico, monitorización de 404, verificación de la indexación de las nuevas páginas y alertas por regresiones de Core Web Vitals. Hemos fijado un umbral: una caída superior al 5% en los primeros 30 días la corregimos sin coste adicional. En la práctica, en cerca del 95% de nuestras migraciones no hizo falta ningún arreglo posterior al lanzamiento, porque el problema se resolvió en la fase de diseño y no apagando fuegos.
¿Parallel run o big-bang cutover?
El cambio del tráfico del sistema antiguo al nuevo se puede hacer de dos formas, y la elección entre ellas influye directamente en el riesgo SEO.
El big-bang cutover es el cambio de todo de una vez en una única ventana. Más rápido, más barato y más simple: funciona bien con catálogos pequeños y migraciones de SaaS a SaaS, donde el sistema antiguo es predecible y está bien documentado. El riesgo es entonces lo bastante bajo como para que mantener dos entornos en paralelo no tenga justificación.
El parallel run significa que el sistema antiguo y el nuevo funcionan uno al lado del otro durante un tiempo. Permite validar datos, redirecciones y rendimiento con tráfico real de producción antes de apagar la tienda antigua. Es más caro y más complejo: hay que mantener dos infraestructuras y sincronizar entre ellas datos que cambian con el tiempo, como el stock, los pedidos y las cuentas de clientes. Pero con un legacy sin documentación y un catálogo de decenas de miles de direcciones es la única manera de detectar las dependencias que ya nadie recuerda antes de que golpeen la producción.
La regla es simple: cuantas más incógnitas haya en el sistema antiguo y mayor sea el catálogo, más se inclina la balanza hacia el parallel run. Una recomendación equivocada cuesta en ambas direcciones: un parallel run innecesario en una migración SaaS limpia quema presupuesto, y un big bang allí donde hacía falta un parallel run quema tráfico. Esta es exactamente la decisión que quieres oír justificada, y no por defecto.
La prueba: miles de direcciones y casi todas las posiciones conservadas
El escenario más difícil que gestionamos es una migración legacy. Bogart Meble funcionó doce años sobre código a medida en PHP 5.4, sin documentación y con consultas a la base de datos que tardaban varios segundos. Reescribimos la tienda a Symfony 6.4 con el patrón Strangler Fig, módulo a módulo, en unas 16 semanas.
Desde la perspectiva del SEO cuentan tres decisiones:
Mapeo 301 para todas las URL: uno a uno, conservando una estructura semántica idéntica, y no una redirección masiva a las categorías.
Parallel run de dos semanas: el sistema antiguo y el nuevo funcionaron en paralelo, lo que permitió validar datos y redirecciones con tráfico de producción antes del cambio definitivo.
Cambio de DNS fuera de las horas punta, con monitorización de posiciones desde la primera hora después del cutover.
Resultado: casi todas las posiciones en Google conservadas, la caída de tráfico orgánico del primer mes mantenida por debajo de nuestro umbral del 3%, sin caídas de servicio y sin pedidos perdidos. Además, el LCP de la página de producto bajó de varios segundos a menos de uno y la conversión creció con claridad al cabo de tres meses, porque una página más rápida vende mejor, independientemente de la posición.
El segundo ejemplo muestra que cambiar de plataforma no es enemigo del tráfico si está bien mapeado. Topeshop migró de PrestaShop a Shopify Plus junto con la integración de marketplaces y registró un +58% de conversión. El mismo principio: primero traslada uno a uno lo que ya funciona en SEO y solo después añade crecimiento.
Cómo comprobar a tu propio proveedor
No hace falta que entiendas de SEO para juzgar si un proveedor lleva la migración de forma segura. Bastan unas pocas preguntas y comparar las respuestas con el aspecto de un proceso SEO-first frente a una migración típica de «primero lo técnico».
EtapaMigración SEO-firstMigración «primero lo técnico»Mapa de redirecciones 301Nace en la semana 2–4, antes del frontendDespués de la implantación, cuando la caída ya se veQuién valida las URLUn especialista en SEO, no solo un programadorNadie, o un programador «de paso»Pruebas de SEODespués de cada sprint, automáticas y manualesUn vistazo antes del lanzamientoFecha del cutoverVentana de bajo tráfico, plan de rollback, 72 h de monitorización«Lo subimos el viernes por la tarde»Monitorización de posiciones90 días incluidos, alerta por regresión superior al 5%El cliente nota la caída por su cuenta en GSCCaída de tráfico habitualPor debajo del 3%15–30%, recuperación en 6–12 meses
Una pregunta pesa más que las demás: ¿cuándo nace el mapa de redirecciones 301? Si la respuesta es «nos ocuparemos de eso después de la implantación» o «lo generaremos automáticamente al final», ya tienes tu respuesta, independientemente del resto de la oferta.
Conclusiones
Una migración no pierde tráfico por el cambio de plataforma: lo pierde por la falta de un mapa de redirecciones, por metadatos perdidos y por un rendimiento peor que antes. Los tres son evitables si el SEO decide primero en lugar de reparar al final. El benchmark del 15–30% describe migraciones llevadas desde lo técnico; una caída por debajo del 3% es alcanzable cuando la estructura de URL, las redirecciones y la monitorización se planifican antes de la implantación, no después.
Si estás planificando una migración y quieres saber cuánto tráfico arriesgas realmente, empieza por una auditoría de la tienda: es lo que crea la lista de «qué conservamos sin excepción». Mira también cómo es nuestro proceso de migración de tienda y nuestros proyectos concretos, y si tienes preguntas sobre tu caso, escríbenos.