Qué se rompe la semana después de migrar a PrestaShop
El día del lanzamiento casi siempre sale bien. Es una falsa señal
Una migración que «funciona», en el sentido estricto de que la tienda nueva está en marcha y recibe pedidos, es relativamente fácil de conseguir: productos, precios, stock e historial de pedidos son datos estructurados, las herramientas de importación los trasladan bastante bien y el primer día todo parece en orden. Los problemas de verdad no aparecen el día del lanzamiento, aparecen entre siete y diez días después, cuando llegan visitantes con una URL antigua guardada en sus favoritos, cuando Google retoma el rastreo con el mapa de direcciones que conocía, y cuando alguien nota que una función «que existía antes» ha desaparecido, no porque alguien la haya eliminado a propósito, sino porque ninguna herramienta de importación la tuvo nunca en cuenta. Este artículo no trata de cómo migrar (existen servicios especializados para eso, no es nuestro oficio): trata de qué hay que comprobar la semana siguiente, cuando la tienda ya está en línea y la lista de problemas empieza a salir a la superficie por sí sola.
URL muertas, no por decenas: por centenares
El problema más subestimado es la escala. Quien migra espera corregir «unas pocas URL», no toda la estructura de direcciones. En la práctica, casi ninguna plataforma comparte el esquema de URL de otra: un catálogo que vivía bajo /product/nombre-producto/ en WooCommerce, bajo /nombre-categoria/nombre-producto.html en Magento, o bajo /products/nombre-producto en Shopify, llega a PrestaShop con otro esquema distinto, que a menudo incluye el identificador numérico del producto en la dirección. Cada URL que un buscador había indexado, cada enlace que otro sitio o un cliente había guardado, apunta ahora a una ruta que sencillamente no existe en la tienda nueva. En un catálogo de unos pocos miles de productos, con las categorías, las páginas de filtros indexadas y los contenidos editoriales, el número de URL que hay que redirigir alcanza fácilmente unos cuantos centenares, incluso en una tienda de tamaño medio: no es un caso límite reservado a los catálogos grandes.
La buena práctica, casi nunca aplicada a tiempo, consiste en exportar la lista completa de URL que la plataforma anterior había hecho indexar (desde Google Search Console, no desde el sitemap del sitio antiguo, que a menudo ya está incompleto) antes del cambio, y construir el plan de redirecciones como una parte del proyecto de migración, no como una corrección después de los primeros informes de tráfico perdido.
El banner de cookies que ya no distingue los países
Una migración multilingüe hecha con prisas casi siempre reutiliza textos y ajustes pensados para el idioma principal, y la configuración del consentimiento de cookies es uno de los primeros lugares donde se nota: un banner que distinguía correctamente al público por idioma o por país vuelve a veces a un único valor por defecto tras la migración o, peor aún, muestra un texto sin traducir en los idiomas secundarios (encontramos y corregimos un defecto exactamente de este tipo en septiembre de 2026 en nuestro propio módulo de consentimiento de cookies, no a causa de una migración sino por la misma causa de fondo: textos que solo cubrían dos idiomas de cinco). Merece la pena volver a comprobar la configuración del consentimiento en cada idioma activo justo después del cambio, y no solo en el idioma principal en el que se hicieron realmente las pruebas.
Los datos de cumplimiento normativo que la herramienta de importación ni siquiera sabía buscar
Las herramientas de importación trasladan bien todo lo que ya existía como concepto en la plataforma de origen: precio, descripción, imágenes, categorías. Un campo como «fabricante GPSR», «advertencia de seguridad para este producto concreto» o «representante autorizado en la UE» a menudo no existía en absoluto como dato estructurado en la plataforma anterior, y por tanto ninguna herramienta de importación podía trasladarlo, sencillamente porque no había ningún campo de origen que copiar. El verdadero riesgo es una tienda migrada que da por hecho que «si estaba bien antes, está bien ahora», cuando la laguna de cumplimiento, si existía, ya estaba ahí antes, y la migración solo la hace más visible al obligar a replantear los datos de producto desde el principio.
La búsqueda interna que vuelve a empezar de cero
Si la tienda anterior tenía un buscador ajustado con el tiempo, con sinónimos añadidos a mano después de que clientes buscaran un término sin encontrar nada, palabras vacías calibradas según el idioma del catálogo, un orden de relevancia corregido tras meses de observar en qué hacían clic realmente los clientes, nada de ese ajuste viaja con una importación de productos. Es un trabajo hecho sobre el comportamiento de la búsqueda, no sobre los datos del catálogo, y ninguna herramienta de migración puede trasladarlo porque ni siquiera es un «dato» en el sentido habitual: es configuración acumulada. El síntoma típico es una bajada de las conversiones procedentes de la búsqueda interna en las primeras semanas, no porque el buscador nuevo sea peor en sí, sino porque parte de un ajuste genérico en lugar de meses de correcciones.
Los feeds de productos que siguen apuntando al esquema antiguo
Un feed de Google Shopping o de marketplace se construye sobre las URL y los identificadores de la plataforma de origen. Tras la migración, a menos que se reconstruya por completo el feed sobre el nuevo esquema de direcciones, cada anuncio sigue apuntando a una URL que devuelve una redirección o, peor, un 404: pasado cierto porcentaje de enlaces rotos, Google Merchant Center empieza a señalar el feed y puede suspender la emisión de los anuncios, lo que supone un perjuicio comercial directo e inmediato, no solo un problema de posicionamiento orgánico.
Una lista de comprobación para la primera semana
- Compare la lista de URL indexadas antes de la migración (desde Search Console) con lo que devuelve un 200 hoy: cada URL que falta necesita o bien una redirección permanente al contenido equivalente, o bien un cierre deliberado si el contenido ya no existe de verdad.
- Compruebe el banner de cookies en cada idioma y cada país activos, no solo en el idioma principal.
- Vuelva a revisar los datos de cumplimiento normativo de los productos (GPSR incluido) partiendo de la base de que la importación no los trasladó, porque casi con seguridad es así.
- Siga por separado las conversiones procedentes de la búsqueda interna durante las dos primeras semanas: es la señal más rápida para saber si hay que rehacer la configuración de la búsqueda.
- Reconstruya el feed de productos sobre el nuevo esquema de URL antes de relanzar las campañas, no después de haber constatado la caída.
En pocas palabras
La semana posterior a una migración no es un periodo tranquilo de rodaje: es el momento en que aparecen los problemas que el día del lanzamiento no podía mostrar. URL que nadie ha redirigido, ajustes sin campo de origen que copiar, meses de configuración (búsqueda, consentimiento, feeds) que nunca existieron como «dato» que migrar. Un gestor de redirecciones con seguimiento de los 404, como cll_seoredirect, ayuda a detectar esas lagunas en el momento en que se abren y no después de que los visitantes ya las hayan notado, pero la lista de comprobación anterior sigue siendo válida sea cual sea la herramienta utilizada.
