Migración de Django a WooCommerce sin perder SEO para una editorial jurídica

El reto

Una editorial jurídica vendía su catálogo en una tienda online hecha a medida con Django. Con los años, cada cambio dependía de un programador, y añadir funciones habituales en cualquier tienda se había vuelto caro y lento. La editorial quería una plataforma estándar que su equipo pudiera gestionar.

El riesgo era alto: miles de fichas de libros, ebooks y revistas, autores con nombres escritos de varias formas, una base de clientes con historial y un posicionamiento en buscadores trabajado durante años. Una migración mal hecha podía romper enlaces, duplicar autores y hacer caer las ventas.

Tampoco valía con copiar la base de datos. La estructura de Django no se parecía a la de WooCommerce y había relaciones entre obras, autores, ediciones y suscripciones a revistas que debían mantenerse intactas.

Y el cambio de plataforma no era el final. Un catálogo grande y público atrae robots que lo copian a todas horas, las campañas de email concentran las visitas en pocos minutos y bibliotecas universitarias acceden a los ebooks desde sus propios portales. La tienda nueva tenía que aguantar todo eso cada día.

La solución

Planteamos la migración a WordPress con WooCommerce como un proyecto de datos. Escribimos un importador propio con interfaz de línea de comandos que trabaja en paralelo, con entre 8 y 16 procesos simultáneos, para trasladar libros, ebooks, autores, revistas y clientes de forma repetible. Así pudimos ensayar la migración varias veces antes del cambio definitivo.

Durante la importación limpiamos las autorías para que cada autor tuviera una única ficha. Mapeamos las URL antiguas con las nuevas y configuramos las redirecciones, y después hicimos una auditoría de SEO técnico para comprobar que buscadores y usuarios llegaban donde debían.

La nueva tienda online funciona sobre PHP, MySQL y nginx, e incluye informes de ventas a medida. En el mismo proyecto migramos también el hosting de una segunda tienda de la editorial. El cambio se hizo con una ventana de corte corta y planificada, tras varios ensayos completos.

Después de la migración: mantenimiento continuo. Seguimos a cargo de la tienda con nuestro servicio de mantenimiento y soporte. Cuando la web se ralentiza o se cae, analizamos los registros del servidor hasta dar con la causa: un robot de copia masiva, una campaña o un fallo propio. Con eso se decide qué cambiar, en vez de ampliar el servidor a ciegas. Cada cambio se prueba antes en un entorno de pruebas y se deja documentado cómo deshacerlo.

Seguridad y control del tráfico. Pasamos el dominio a Cloudflare con un reto para el tráfico sospechoso. En el servidor dejamos una lista de robots permitidos (buscadores, vistas previas de redes y servicios útiles) y cerramos a visitantes anónimos las rutas de la API que la web pública no necesita. Un vigilante escrito en Python revisa los accesos, avisa por email de cada robot nuevo y bloquea los que se hacen pasar por un buscador sin serlo. Lo contamos con más detalle en por qué una web se cae al enviar la newsletter, donde también explicamos cómo hicimos que la caché ignore los parámetros de campaña.

Dentro de las mismas medidas de cloud y ciberseguridad vigilamos los certificados SSL, también los de servicios que aloja un tercero, y mantenemos el acceso de las bibliotecas universitarias por página de origen, comprobando que sigue funcionando a través de Cloudflare.

Datos de ventas para decidir. Con el histórico de pedidos de varios años preparamos comparativas e informes interactivos de business intelligence: evolución por año y por mes, por tipo de producto, papel frente a digital, materia y editorial, y los títulos más vendidos con filtros. La dirección ve dónde se gana y dónde se pierde, y si el cambio viene de clientes nuevos o de los que repiten.