De WordPress a Strapi y Astro: consolidar 50 sitios en una única pila
Una cadena minorista migró más de cincuenta tiendas web de WordPress a una arquitectura basada en Strapi y Astro para centralizar catálogos y acelerar despliegues.
El cliente, un grupo minorista que crece mediante adquisiciones, heredó más de cincuenta sitios web, todos en WordPress, con plugins desactualizados y catálogos de productos dispersos. Cada nueva compra traía al menos un sitio con su propio motor, lo que obligaba a mantener versiones distintas de WordPress, temas en Elementor y una maraña de plugins que dificultaba cualquier cambio a escala.
El equipo de mantenimiento actualizó WordPress y los plugins en todas las instancias, pero pronto se dio cuenta de que la verdadera limitación no era la calidad del código sino la ausencia de una gestión centralizada de productos. Probaron decenas de herramientas de gestión múltiple de WordPress, desde SaaS hasta soluciones auto‑hosted, pero ninguna ofrecía una forma práctica de sincronizar catálogos entre sitios.
Como solución provisional intentaron exportar catálogos a CSV, modificarlos y volver a importarlos mediante WP‑CLI. El proceso requería intervención de un desarrollador en cada paso, no permitía control de quién publicaba qué y consumía mucho tiempo. La conclusión fue clara: el problema no se resolvería dentro del ecosistema WordPress.
La propuesta final consistió en separar datos y presentación. Se eligió Strapi como CMS headless para almacenar productos, contenido y metadatos de forma centralizada. Cada tienda pasó a tener un frontend estático generado por Astro, que consumía la API de Strapi. La primera migración mantuvo los templates originales, arrastrando solo las librerías necesarias, lo que redujo costos y riesgos.
Con Strapi se construyeron plugins específicos para la gestión de catálogos, permitiendo activar o desactivar productos por tienda mediante una vista de marcas y productos. Un “builder” de línea de comandos observaba cambios en Strapi, disparaba reconstrucciones de Astro y notificaba los resultados. Las plantillas se modularizaron en componentes reutilizables con soporte multilingüe, de modo que agregar un nuevo sitio implicaba principalmente ajustes de estilo y selección de productos.
Paralelamente, el grupo sigue operando su canal de ventas en Shopify Plus. Se desarrolló un sincronizador que exporta el inventario de Shopify a Strapi, y viceversa, para que los catálogos estáticos reflejen siempre la disponibilidad real.
La migración dejó cinco sitios funcionando con un único repositorio de productos, capacidad de personalizar la oferta por tienda y despliegues de nuevas tiendas en cuestión de días en lugar de meses. El enfoque demostró que centralizar datos y generar frontends estáticos es una ruta rentable para organizaciones que agregan sitios con cada adquisición.
Por qué importa: la experiencia muestra que, frente a una proliferación de sitios WordPress, una arquitectura headless con generación estática puede eliminar la carga operativa, mejorar la seguridad y acelerar el time‑to‑market. Queda por ver cómo escalará la solución cuando el número de tiendas supere los cincuenta y cómo se gestionarán futuras integraciones con otros canales de venta.
