Migrar de PrestaShop 1.6 a la 8 sin perder posiciones

El riesgo principal no es el que se imagina

En una migración desde PrestaShop 1.6, la preocupación se dirige de forma espontánea a los datos: ¿se perderán pedidos, clientes, productos? En la práctica, esos datos suelen pasar bastante bien. Lo que sí se pierde, y no vuelve solo, es el tráfico orgánico.

La estructura de las URL cambia entre la 1.6 y las versiones modernas. Sin un plan de redirecciones, cada URL indexada se convierte en un 404. Google desindexa, las posiciones conseguidas desaparecen y luego hacen falta meses para recuperarlas. Por eso una migración técnicamente impecable puede ser un fracaso comercial.

La ruta de versiones es obligatoria

Primera regla: no existe ningún salto directo de la 1.6 a la 8. Los scripts de migración se aplican de forma incremental, y saltarse peldaños deja la base de datos en un estado incoherente.

La ruta es: 1.6.1.x → 1.7.8.x → 8.x (y después 9.x si procede).

Cada peldaño debe comprobarse antes de pasar al siguiente: el back-office carga, se puede hacer un pedido, los productos se muestran. Una base migrada con demasiada prisa produce errores que solo afloran varias semanas más tarde, en funcionalidades periféricas.

Las seis pérdidas clásicas

1. El tema. Un tema de la 1.6 no funciona en la 1.7 ni en versiones posteriores. El motor de plantillas cambió de versión y la estructura de los archivos de producto se rehízo por completo. No hay conversión automática: el tema se rehace o se sustituye.

2. Todos los overrides. La carpeta override/ debe empezar de cero. Las clases sobrecargadas han cambiado de firma, y conservar un override de la 1.6 provoca un error fatal. También es una oportunidad: la mitad de los overrides responden a necesidades abandonadas hace tiempo.

3. Los módulos de la 1.6. Los hooks se han renombrado (hookHeader pasa a ser hookDisplayHeader, por ejemplo) y la arquitectura de los módulos ha evolucionado. Cada módulo debe sustituirse por su versión moderna o reescribirse.

4. Las opiniones de producto. El módulo productcomments cambia de esquema. Las valoraciones de los clientes no se recuperan de forma automática: hay que migrarlas por script, tabla a tabla. Ese contenido tiene un valor real para el SEO, no lo deje de lado.

5. Las imágenes de producto. Regenerar las miniaturas desde Diseño > Configuración de imágenes supera el tiempo de ejecución permitido en cuanto hay más de unos miles de imágenes. Resultado: productos sin foto en el front-office. Hay que hacerlo por línea de comandos o por lotes.

6. Los bloques CMS y los contenidos estáticos. Páginas CMS, bloques de confianza, contenidos de la página de inicio: según los módulos usados en la 1.6, esos contenidos viven en tablas que ya no existen. Hay que exportarlos antes y volver a introducirlos después.

El plan SEO, paso a paso

Es la parte que más atención merece.

Antes de la migración

1. Exportar todas las URL indexadas. Cruce tres fuentes: un rastreo completo del sitio, la exportación de páginas de Search Console de los últimos 16 meses y su sitemap actual. Search Console es imprescindible: revela URL que el rastreo ya no encuentra pero que siguen recibiendo tráfico.
2. Anotar las posiciones. Una foto de las palabras clave posicionadas antes del cambio es su único punto de comparación objetivo después.
3. Construir la tabla de correspondencias. Cada URL antigua debe apuntar a su equivalente nueva. Los productos eliminados van a su categoría, nunca a la página de inicio: una redirección masiva a la portada Google la trata como un error blando.

Durante la migración

4. Implantar las redirecciones 301 en el servidor, no mediante un módulo, cuando el volumen es alto. Una redirección en PHP sobre 40 000 URL penaliza el rendimiento.
5. Revisar las etiquetas canónicas y el archivo robots.txt. Una preproducción en noindex que pasa a producción sin quitar la directiva es una catástrofe clásica y perfectamente evitable.

Después de la migración

6. Enviar el nuevo sitemap y vigilar a diario el informe de cobertura durante un mes.
7. Seguir los 404 reales en los logs del servidor, no solo en Search Console, que informa con retraso. Cada 404 recurrente en una URL que recibía tráfico es una redirección olvidada.

Cuánto tiempo hay que prever

Una migración de la 1.6 a la 8 con rehacer el tema y actualizar los módulos se cuenta en semanas, no en días. La partida más pesada es casi siempre el tema, seguida de la adaptación de los desarrollos a medida.

La mejor inversión sigue siendo la auditoría previa: inventario de módulos, de overrides, de plantillas sobrescritas y de URL indexadas. Convierte un presupuesto aproximado en un plan de carga y a menudo revela que el trabajo es más ligero de lo anunciado.

Si ya está en la versión 8 y duda sobre el siguiente paso, lea nuestro artículo sobre el fin de soporte de PrestaShop 8.

Migre su tienda con nosotros

Nos encargamos de la migración completa, plan de redirecciones incluido, con seguimiento del tráfico orgánico después del cambio. Consulte la página de migración de PrestaShop.