Tu red Multisite acaba de llegar a 80 subsitios. ¿Y ahora qué?

WordPress Multisite era una buena idea en 2012

WordPress Multisite tenía sentido en 2012. En 2026, cada subsitio que añades hace más difícil la migración que inevitablemente necesitarás. Las tablas con prefijo crecen. Los datos serializados se acumulan. El plugin de mapeo de dominios añade otra dependencia. Cada año en Multisite es un año de deuda técnica que pagarás durante la migración.

La pregunta no es si migrarás. Es cuándo.

Hemos migrado redes Multisite con 5 subsitios y redes con más de 80. El patrón técnico es siempre el mismo: extraer tablas con prefijo, deserializar años de datos de opciones acumulados, mapear usuarios compartidos a un sistema de autenticación moderno y construir una arquitectura multitenant que realmente escale. La diferencia es el alcance, no la complejidad.

Por qué abandonar WordPress Multisite

Las redes Multisite acumulan categorías específicas de deuda técnica que se agravan con el tiempo.

Proliferación de tablas con prefijo

Cada subsitio crea su propio conjunto de tablas: wp_2_posts, wp_2_postmeta, wp_2_options, wp_3_posts, y así sucesivamente. Una red de 25 sitios tiene más de 250 tablas. Consultar entre subsitios requiere uniones en todas ellas. No existe búsqueda nativa entre sitios, ni una API de contenido unificada, ni forma de agregar datos sin SQL personalizado.

Datos serializados por todas partes

WordPress almacena datos complejos como cadenas serializadas de PHP. Grupos de campos ACF, configuraciones de widgets, URLs del sitio, ajustes de plugins: todo serializado. Estas cadenas codifican longitudes de texto (s:23:"https://old-domain.com"), lo que significa que no puedes hacer un simple buscar-y-reemplazar en las URLs sin romper la serialización. Cada migración que toca datos serializados necesita una deserialización, transformación y re-serialización correctas. Sin atajos.

Usuarios compartidos, roles fragmentados

La tabla wp_users abarca toda la red. Un usuario puede ser administrador en el subsitio 2, editor en el subsitio 5 y suscriptor en el subsitio 12. Esos roles viven como arrays serializados en wp_usermeta bajo claves como wp_2_capabilities. Extraer eso en un modelo de autenticación coherente implica analizar el rol de cada usuario por subsitio, lo cual es tan tedioso como suena.

Fragilidad de plugins y actualizaciones

Los plugins activados en red afectan a todos los subsitios simultáneamente. Una actualización de plugin que rompe un subsitio rompe el panel de administración de todos. Los plugins específicos por sitio generan conflictos de versiones. La base de código compartida significa que cada cambio es una potencial interrupción en toda la red.

Degradación del rendimiento a escala

Las redes Multisite con más de 10 subsitios presentan cargas de página un 40-60 % más lentas en comparación con instalaciones WordPress independientes. El análisis de datos serializados, las conexiones de base de datos compartidas y la sobrecarga de los plugins se acumulan. Las puntuaciones móviles en Lighthouse suelen situarse entre 35 y 55. No es precisamente bueno.

Lo que obtienes: arquitectura multitenant con Next.js + Supabase

La arquitectura de destino reemplaza toda la red Multisite con una única aplicación Next.js respaldada por Supabase, usando Row Level Security para el aislamiento de tenants.

Multitenancy basada en rutas

En lugar de subdominios o subdirectorios gestionados por WordPress, cada ubicación obtiene una ruta limpia: /locations/[slug]. Los componentes compartidos (barra de navegación, pie de página, elementos de marca) se renderizan desde un único layout. El contenido específico de cada ubicación se obtiene de Supabase filtrado por location_id. Un único código base, un único despliegue, ubicaciones ilimitadas.

RLS de Supabase para el aislamiento de datos

Las políticas de Row Level Security garantizan que los gestores de cada ubicación solo vean sus propios datos, mientras que los administradores de red lo ven todo. Sin hacks de filtrado a nivel de aplicación. La propia base de datos impone el acceso:

CREATE POLICY "location_isolation" ON posts
  FOR ALL USING (
    auth.uid() IN (
      SELECT user_id FROM user_locations
      WHERE location_id = posts.location_id
    )
  );

Esto elimina toda una categoría de errores de autorización que plagan las configuraciones WordPress multitenant.

Panel de administración moderno

Los gestores de cada ubicación disponen de un panel diseñado específicamente para ellos: añadir ubicaciones, editar contenido por ubicación y gestionar medios. Se acabó hacer clic en el conmutador de administración de red de WordPress. Se acabó la confusión entre «Super Admin» y «Administrador del sitio».

Nuestro proceso de migración en 7 fases

Fase 1: Auditoría de la red (1-2 semanas)

Mapeamos cada subsitio de tu red: estructura de URLs, volumen de contenido, plugins utilizados, tipos de contenido personalizados, campos personalizados y configuración de mapeo de dominios. Consultamos wp_blogs para enumerar los subsitios y luego rastreamos cada uno mediante la API REST y consultas directas a la base de datos.

Identificamos el contenido compartido (a nivel de red) frente al contenido específico de cada sitio. Plugins compartidos frente a plugins específicos por sitio. Código personalizado en temas hijo, mu-plugins y plugins activados en red con funcionalidad propia.

El resultado es un documento de especificación de migración con un inventario de contenido por subsitio.

Fase 2: Diseño de la arquitectura (1 semana)

Diseñamos el esquema de Supabase: tabla locations, tablas de contenido con claves foráneas location_id y políticas RLS por tabla. Diseñamos la estructura de rutas de Next.js y mapeamos cada URL antigua a su equivalente nueva para las redirecciones 301.

El panel de administración se diseña con wireframes: gestión de ubicaciones, edición de contenido por ubicación y control de acceso basado en roles. Cada decisión queda documentada antes de escribir una sola línea de código.

Fase 3: Exportación de contenido (1-2 semanas)

Aquí es donde las migraciones de Multisite se vuelven técnicas. Extraemos el contenido a través de dos canales:

WP REST API para contenido estándar: solicitudes autenticadas por subsitio, gestionando la paginación a través de miles de entradas.

Consultas directas a la base de datos para todo lo que la API no puede exponer: campos ACF almacenados en wp_2_postmeta, tablas personalizadas creadas por plugins y opciones serializadas que contienen configuración crítica.

Los datos serializados se procesan mediante unserialize() de PHP o la librería phpserialize de Python. Las referencias de dominio embebidas en las opciones serializadas (siteurl, home) se actualizan antes de la re-serialización. Un buscar-y-reemplazar directo en cadenas serializadas corrompe los prefijos de longitud y rompe todo — hemos visto cómo esto sale mal, y limpiar el desastre es brutal.

Los archivos multimedia se descargan iterando /wp-content/uploads/sites/[id]/ por subsitio. Los usuarios se exportan desde la tabla wp_users a nivel de red, con las capacidades por sitio analizadas desde las entradas serializadas de wp_usermeta.

Resultado: archivos JSON y CSV por subsitio con todo el contenido, usuarios y medios inventariados.

Fase 4: Construcción (2-6 semanas)

La aplicación Next.js toma forma con multitenancy basada en rutas. Las tablas de Supabase se crean con políticas RLS aplicadas. Los componentes de layout compartidos garantizan la coherencia de marca. Las plantillas de página por ubicación renderizan zonas de contenido localizadas.

El panel de administración permite añadir ubicaciones, editar contenido por ubicación y visualizar datos agregados de todas las ubicaciones. Los formularios de contacto, integraciones de reservas e incrustaciones de terceros se reconstruyen o migran.

El plazo depende de la complejidad: una red de 5 subsitios con páginas estándar lleva 2 semanas. Una red de 40 subsitios con sistemas de reservas personalizados, áreas de membresía y layouts complejos de ACF lleva 6.

Fase 5: Importación de contenido (1-2 semanas)

Todo el contenido se importa por lotes a Supabase con el mapeo de location_id. Cada tabla con prefijo wp_2_ se mapea al location ID 2. Las URLs de los medios se reescriben de /uploads/sites/23/image.jpg a rutas de Supabase Storage o nuevas URLs de CDN mediante transformaciones de expresiones regulares en todos los campos de contenido.

Los usuarios de WordPress se mapean a Supabase Auth. Los hashes de contraseñas se preservan: el rehashing con bcrypt ocurre en el primer inicio de sesión, por lo que los usuarios no necesitan restablecer sus contraseñas.

Validamos comprobando manualmente el 10 % del contenido por subsitio frente al original.

Fase 6: Mapeo de redirecciones (1 semana)

Cada URL antigua de todos los subsitios se mapea a su nueva URL. En el caso de subsitios con dominio propio mapeado, el dominio antiguo redirige a la nueva ruta /locations/[slug] con un 301. Los subdominios antiguos (site2.example.com) redirigen a /locations/site2.

Rastreamos cada sitemap antiguo y verificamos que existe un 301 para cada URL. Los nuevos sitemaps se envían a Google Search Console por cada dominio anterior.

Fase 7: Lanzamiento y monitorización

La transferencia de DNS se realiza dominio a dominio. Los certificados SSL se aprovisionan automáticamente a través de Vercel. Google Search Console recibe nuevas propiedades de dominio con sitemaps actualizados. Monitorizamos durante 30 días: progreso de indexación, métricas base de Core Web Vitals y seguimiento de errores 404.

La base de datos de WordPress antigua se archiva. El alojamiento se cancela tras un período de monitorización de 60 días que confirma la estabilidad de todo.

Estrategia de preservación del SEO

Las migraciones de Multisite conllevan un riesgo real para el SEO: potencialmente estás cambiando URLs en decenas de dominios a la vez. Nuestro enfoque:

• Mapeo exhaustivo de redirecciones 301 — cada URL, cada subsitio, cada dominio. Sin errores 404.
• Envío de sitemap por dominio — cada dominio anterior obtiene su propio sitemap enviado a Google Search Console.
• Coherencia de etiquetas canónicas — las nuevas páginas llevan canonicals correctos desde el primer día.
• Verificación de paridad de contenido — comparación automatizada para garantizar que ningún contenido se pierda o trunque durante la importación.
• Preservación de backlinks — auditamos los backlinks por subsitio y nos aseguramos de que las redirecciones 301 capturen toda la autoridad de los enlaces entrantes.

Los clientes suelen ver una mejora del 25-50 % en el tráfico orgánico en los primeros 90 días, principalmente gracias a las mejoras en Core Web Vitals.

Plazos y precios

Tamaño de red	Subsitios	Plazo	Inversión
Pequeña	5-10	4-6 semanas	$15.000 - $30.000
Mediana	10-25	6-8 semanas	$30.000 - $60.000
Grande	25-50	8-12 semanas	$60.000 - $100.000
Enterprise	50+	10-16 semanas	$80.000 - $150.000+

El precio escala con el volumen de datos serializados, los tipos de contenido personalizados, la complejidad de los roles de usuario y las integraciones de terceros por subsitio. Las redes con uso intensivo de ACF o funcionalidad de plugins personalizados tienden hacia el extremo más alto.

Cada proyecto comienza con una auditoría de migración gratuita. Mapeamos tu red, estimamos el alcance y te entregamos una propuesta a precio fijo antes de que comience ningún trabajo.