Cómo migrar tu tienda online sin perder posicionamiento SEO

Lo que realmente pierdes cuando migras mal

Un cliente nos llamó tres semanas después de haber cambiado de plataforma. Su tráfico orgánico había caído más de la mitad, las fichas de producto devolvían 404 en Google y el equipo comercial estaba respondiendo llamadas de clientes que no encontraban su cuenta. El desarrollador anterior había hecho la migración en fin de semana, sin plan de redirecciones y sin backup del catálogo original. Recuperar la situación llevó meses de trabajo que se podían haber ahorrado con una hoja de ruta correcta.

Migrar una tienda online no es mover archivos de un servidor a otro. Es trasladar años de autoridad SEO, historial de clientes, pedidos, integraciones fiscales y comportamiento de usuario. Cualquier fallo en la cadena, una URL mal redirigida, un slug modificado sin motivo, un sitemap que no se actualiza a tiempo, termina traduciéndose en ingresos perdidos que tardan trimestres en volver.

Los riesgos que aparecen en toda migración

Hay cinco puntos de fallo que se repiten en prácticamente cada proyecto que auditamos:

• Cambio de estructura de URLs sin mapa de redirecciones. La plataforma nueva tiene otra lógica de rutas (por ejemplo, pasas de /tienda/categoria/producto a /shop/product-slug) y las miles de URLs que Google tiene indexadas empiezan a devolver 404.
• Pérdida de metadatos SEO. Title, meta description, atributos alt de imagen y datos estructurados a menudo no se exportan correctamente y hay que reconstruirlos a mano.
• Cuentas de cliente sin migrar. Las contraseñas están hasheadas y no se pueden trasladar en claro, pero sí puedes conservar los emails, las direcciones y el historial, forzando un reset de contraseña la primera vez que entren.
• Pedidos y facturas huérfanos. Los pedidos antiguos siguen siendo obligatorios por normativa fiscal (en España, seis años). Perderlos no es solo un problema comercial, es un problema legal.
• Integraciones rotas. ERP, pasarelas de pago, sistemas de envío, píxeles de marketing, todo lo que apuntaba al dominio o a endpoints concretos deja de funcionar el día del cambio si no se ha reconfigurado antes.

Auditoría previa: el paso que casi nadie hace

Antes de tocar una línea de código, extrae un inventario completo de lo que tienes. Este es el trabajo aburrido que decide si la migración va a salir bien.

Necesitas un CSV con todas las URLs indexadas (lo saca Screaming Frog o similar), otro con las URLs que reciben tráfico orgánico según Search Console de los últimos doce meses, un export completo del catálogo con SKUs, precios, variantes, stock e imágenes, un backup de la base de datos con clientes y pedidos, y un listado de integraciones activas con sus credenciales. Sin estos cinco documentos no empieces.

Con la auditoría en la mano puedes identificar qué contenido tiene valor real. No todas las URLs importan igual. Las páginas que concentran el 80% del tráfico orgánico son las que hay que proteger con obsesión. El resto puede consolidarse, redirigirse a categoría padre o incluso archivarse si ya no tiene sentido comercial.

Plan de redirecciones 301: la columna vertebral

El mapa de redirecciones es el documento más importante de toda la migración. Es una hoja de cálculo con dos columnas: URL antigua y URL nueva. Nada más, nada menos.

Reglas básicas para construirlo:

1. Toda URL con tráfico orgánico o backlinks apuntando a ella tiene que tener destino. Sin excepciones.
2. La redirección debe ser 301 (permanente), no 302 ni 307. El 301 transfiere la autoridad SEO, los demás no.
3. Evita cadenas de redirecciones. Si /a redirige a /b y /b a /c, colapsa directamente /a a /c. Cada salto pierde señal.
4. Si un producto ya no existe, redirige a su categoría, no a la home. La home es el peor destino posible porque Google interpreta que el contenido original ha desaparecido.
5. Cuidado con las URLs paramétricas de filtros, paginación y búsqueda interna. Muchas veces conviene bloquearlas en robots.txt en la tienda nueva en lugar de redirigirlas.

Testea el mapa antes de publicarlo. Un script sencillo que recorra la columna de URLs antiguas y compruebe que la nueva devuelve 200 te ahorra sustos. En proyectos de más de 5.000 URLs, el testing manual no es viable.

Migración de catálogo, clientes y pedidos

Los datos deberían moverse en este orden: catálogo primero, luego clientes, luego pedidos. Cada bloque tiene sus trampas.

Catálogo. Mantén los mismos SKUs. Cambiar la codificación de referencia interna te obliga a reeducar al equipo, resincronizar el ERP y reetiquetar el almacén. Los slugs de producto pueden cambiar solo si vas a redirigir los antiguos correctamente. Las imágenes tienen que mantener nombres de archivo estables o redirigirse también, porque Google Images también posiciona.

Clientes. Migra emails, teléfonos, direcciones fiscales y de envío, grupo de cliente, historial de suscripción a newsletter y consentimientos RGPD. Los consentimientos son especialmente importantes: si en la plataforma antigua el usuario opt-in a marketing en 2022, ese consentimiento tiene que viajar con su registro. Perderlo te obliga a pedirlo de nuevo, con la caída de base de contactos que eso implica.

Pedidos. Migra los datos crudos, incluyendo estado, importe, línea de pedido, dirección de envío y facturación en el momento de la compra. Los pedidos son documentos contables, no información de marketing, así que tienen que conservar la información tal cual estaba cuando se emitieron, aunque el catálogo actual haya cambiado.

Pruebas antes del cambio de DNS

Durante mínimo dos semanas, la tienda nueva debe funcionar en un dominio de staging (por ejemplo, nueva.tudominio.com) con el catálogo real. Aquí es donde detectas los problemas antes de que los vea el cliente final.

La checklist mínima de pruebas incluye:

• Compra completa con las principales pasarelas de pago (Stripe, Redsys, PayPal). Simula también fallos de pago para ver que el flujo de error funciona.
• Alta de cliente nuevo y login de cliente migrado con reset de contraseña.
• Cálculo de portes por país y por peso, con umbrales de envío gratuito si los tienes.
• Aplicación de cupones y descuentos por grupo de cliente.
• Emisión correcta de factura y albarán con numeración correlativa.
• Sincronización con ERP y sistemas de stock en tiempo real.
• Comportamiento en móvil de las fichas de producto y del checkout, con Core Web Vitals medidos.

Bloquea el staging con noindex y robots.txt disallow mientras dura la fase de pruebas. Si Google indexa la versión de staging, tendrás contenido duplicado y penalización asegurada.

El día del cambio y las 48 horas siguientes

Elige un momento de bajo tráfico (típicamente martes o miércoles por la mañana, nunca viernes tarde). Ten preparado un plan de rollback en caso de que algo salga mal: DNS del proveedor con TTL bajo al menos 24 horas antes, backup completo de la plataforma antigua accesible.

En cuanto el cambio esté hecho, ejecuta esta lista sin esperar:

1. Envía el nuevo sitemap.xml a Search Console.
2. Comprueba que el robots.txt de producción permite indexación y no arrastra el disallow del staging.
3. Verifica que la redirección de www a no-www (o al revés, según tu configuración canónica) sigue funcionando.
4. Revisa que el certificado SSL cubre todos los subdominios activos.
5. Confirma que Google Analytics, Tag Manager y el píxel de Meta están disparando eventos.
6. Simula 20 URLs antiguas al azar del mapa de redirecciones y verifica que devuelven 301 al destino correcto.

Checklist post-migración: las cuatro semanas siguientes

La migración no termina el día del cambio. Las cuatro semanas siguientes son las que deciden si conservas el posicionamiento.

Monitoriza a diario Search Console para detectar picos de errores 404 y páginas excluidas. Cualquier URL antigua que aparezca como 404 debe añadirse al mapa de redirecciones al momento. Revisa los rankings de las 50 keywords principales cada tres o cuatro días: es normal una caída inicial del 10 al 20% que se recupera en cuatro a seis semanas si el plan estaba bien hecho. Si a las dos semanas no ves recuperación, hay algo mal en las redirecciones o en la nueva arquitectura.

Vigila también los ingresos por canal orgánico frente a la media de los tres meses previos. Cualquier caída superior al 30% pasado el primer mes es una señal de alarma que hay que auditar en profundidad.

Cuándo pedir ayuda especializada

Una migración con menos de 500 productos y sin integraciones críticas es abordable con un buen desarrollador y una checklist como esta. Cuando entran ERP, catálogos de miles de referencias, múltiples idiomas o volúmenes de tráfico orgánico que representan una parte importante de la facturación, el riesgo de hacerlo internamente supera al coste de contratar a especialistas.

En Vértice Labs llevamos años haciendo migraciones de PrestaShop y otras plataformas a stacks modernos, preservando SEO y datos. Si estás valorando cambiar tu tienda online, el punto de partida sensato es una auditoría honesta de qué tienes hoy y qué riesgos concretos vas a asumir. Ofrecemos un diagnóstico gratuito de tu situación actual, con estimación de tráfico en riesgo y plan de migración por fases. Escríbenos y lo revisamos juntos antes de que tomes la decisión.