Multisite centraliza usuarios y parches pero aumenta el riesgo de movimiento lateral. Instalaciones separadas aíslan datos y facilitan restores, aunque suben costes y gestiones.
Esta guía compara ambos enfoques y da pasos prácticos para decidir y migrar.
Variables críticas para elegir arquitectura y seguridad
La decisión se basa en cuatro variables medibles. Las variables son: número de alumnos concurrentes, peso multimedia, modelo de administración y si cada academia es entidad legal distinta.
Estas variables dan un criterio objetivo para elegir Multisite o instalaciones separadas. Permiten cuantificar costes y riesgos.
Mida antes de decidir con pruebas reales y reportes.
Número de alumnos concurrentes
Use umbrales claros: 100, 1.000 y 5.000 usuarios concurrentes como referencia operativa. Las pruebas de carga deben simular esos picos y medir latencia p95 y errores 5xx.
El peso medio por curso condiciona almacenamiento y CDN. Para cursos con más de 500 MB por alumno, se debe separar el almacenamiento.
También hay que usar buckets por sitio o instalaciones separadas.
Modelo de usuarios y responsabilidad
Si varias academias tienen distintos responsables legales, separar los sitios clarifica responsabilidades del DPO. Esto facilita las auditorías RGPD.
Coste operativo y tolerancia a fallos
Multisite reduce tareas repetidas.
- Un parche actualiza todos los sitios.
- Las instalaciones separadas multiplican tareas.
- Calcule el coste mensual por sitio y el tiempo de operaciones.
- En entornos homogéneos con un solo responsable legal, Multisite suele ahorrar costes desde 20 hasta 30 sitios.
- El umbral cambia según el peso multimedia, la necesidad de PHP distinto y las reglas legales.
- Por eso debe hacer pruebas de carga.
- También debe elaborar un inventario de plugins.
La elección depende de métricas claras: número de sitios, concurrencia prevista y si existe obligación legal de segregar datos. Si hay duda, medir con una prueba de carga y un inventario de plugins reduce el riesgo.
Un caso: academias con gestión centralizada y responsabilidad centralizada
Si todas las academias pertenecen a la misma empresa y comparten políticas, suele ser más eficiente y manejable. La red comparte core, themes y muchos plugins.
Eso reduce el tiempo de mantenimiento y los despliegues.
Compruebe siempre permisos y roles antes de activar plugins.
Riesgos técnicos en este caso
El principal riesgo es el movimiento lateral si se compromete un plugin o una cuenta con privilegios. El error más frecuente en este punto es asumir que Multisite aísla subsites por defecto.
Multisite no aísla subsites por defecto.
Mitigaciones operativas
Medidas prácticas incluyen 2FA para superadmins, forzar roles mínimos, instalar WAF con reglas por hostname y usar CDN para offload de media, lo que mejora la resiliencia. Un threat model debe detallar vectores y alcance del compromiso.
- Por ejemplo, un plugin vulnerable que escribe en opciones globales (wp_sitemeta/wp_options) permite movimiento lateral.
- Una escalada de privilegios en un administrador local puede dar acceso a tablas compartidas.
- Aplicar 2FA a superadmins y administradores de alto riesgo.
- Reducir roles y permisos al mínimo necesario.
- Segmentar acceso a la REST API según origen.
- Habilitar WAF por hostname para bloquear payloads dirigidos.
- Activar logging de consultas y alertas por anomalías.
También conviene definir reglas de detección. Ejemplos: alertas por creación masiva de roles, cambios en capabilities y accesos desde IPs geográficas inusuales.
Todo ello forma parte del threat model para academias. Esto aplica cuando manejan muchos usuarios concurrentes y contenido multimedia.
Un caso: academias como entidades legales independientes
Cuando cada academia es una entidad legal distinta, instalaciones separadas simplifican cumplimiento y responsabilidad. Separar instalaciones facilita mostrar al regulador la segregación técnica de datos.
La segregación técnica facilita auditorías y reduce riesgos legales.
Implicaciones RGPD y LOPDGDD
RGPD exige que el responsable documente tratamientos y demuestre medidas técnicas y organizativas. Cuando las academias son distintas, esto suele implicar instalaciones separadas o contenedores con claro aislamiento entre datos.
PCI DSS y procesamiento de pagos
Si alguna academia procesa tarjetas, PCI DSS puede ampliar el alcance de controles. Aislar sistemas que tocan datos de tarjetas reduce el alcance del cumplimiento y el coste de auditoría.
Errores y advertencias prácticas sobre seguridad y operativa
Multisite puede parecer la opción administrativa obvia, pero conlleva riesgos concretos que suelen pasarse por alto. No planear backups por subsite ni ensayar restores parciales es un fallo común que convierte un incidente en desastre.
Probar restores salva muchas horas y reduce costes.
Error: confiar en backups de
Los backups completos de la instalación no equivalen a restores parciales sencillos. Restaurar un único subsite exige extraer archivos en /uploads/sites/{ID} y tablas wp_{blogid}_* de la copia SQL.
Error: ignorar privilegios de plugins
Muchos plugins declaran compatibilidad con Multisite y crean opciones globales. La mayoría de guías omite revisar cada capability que el plugin añade.
Esa revisión debe incluir qué roles y permisos cambia.
Advertencia operativa
Probar una restauración parcial en staging cada 6 meses reduce el tiempo de recuperación real. Los ejercicios DR revelan dependencias externas que no aparecen en inventarios.
Matriz comparativa para academias: criterios y decisión
Esta tabla resume criterios medibles para decidir entre Multisite e instalaciones separadas. Léala sin contexto y deberá servir para una decisión inicial.
| Criterio |
|
Instalaciones separadas |
| Aislamiento de datos |
Medio (compartido por defecto) |
Alto (DB y ficheros separados) |
| Restauración por sitio |
Compleja; requiere micro-backups |
Sencilla; restaura sitio independiente |
| Complejidad operativa |
Baja para parches |
Alta (multiplica tareas) |
| Coste mensual (hosting, ES) |
€€ (compartido) |
€€€–€€€€ (por sitio) |
| Apto para multimedia pesado |
Medio; requiere CDN y buckets por site |
Alto; storage dedicado por sitio |
| Cumplimiento (RGPD/PCI) |
Complicado si hay múltiples responsables |
Más sencillo de justificar en auditoría |
Decisión rápida
Si tiene más de 20 sitios iguales y un solo responsable legal, Multisite suele ahorrar costes de operación.
Riesgo a controlar
Un plugin con privilegios globales puede escalar a Superadmin y afectar a todos los subsites.
Backup/DR
Planear micro-backups por subsite o elegir instalaciones separadas si necesita restores por entidad.
Backups y restores: qué hace falta en multisite
Restaurar un subsite desde un backup network-level no suele ser directo y necesita pasos específicos. La estrategia debe combinar snapshots de ficheros y export SQL selectivo para las tablas del subsite.
Planifique restores y mida los tiempos de recuperación reales.
Qué copiar para un subsite
Copiar la carpeta uploads del subsite, las tablas wp_{blogid}_* y los options/meta relacionados es imprescindible. No olvidar archivos generados por plugins y caches externas.
Herramientas y tiempos
Usar WP-CLI y soluciones de hosting que soporten restauración parcial acelera el proceso. Planear ensayos de restauración cada 6 meses y documentar tiempos reales.
Defina objetivos RPO y RTO por subsite; por ejemplo, RPO 1 hora para sites con datos de pago y RTO menor de 2 horas para cursos críticos. Haga micro-backups periódicos que incluyan dumps incrementales de las tablas wp_{blogid}_*.
Sincronice /uploads/sites/{ID} a object storage con versionado. Use snapshots puntuales del filesystem para restoraciones rápidas.
Combine retenciones diaria, semanal y mensual con cifrado en reposo y en tránsito. Gestione claves con KMS.
Herramientas prácticas: WP-CLI para export/import, restic o borg para deduplicación y retención. Use scripts cron con rsync u objcopy para multimedia pesado.
Ensaye restores por subsite cada trimestre, midiendo tiempos reales de recuperación.
Migración entre multisite e instalaciones separadas
Mover un subsite fuera de Multisite exige exportar archivos, tablas y usuarios y resolver colisiones de IDs. El proceso es técnico y debe incluir pruebas antes del corte en producción.
Verifique dominios, certificados y webhooks antes del corte.
Preparación: inventario y checklist
Enumerar plugins, themes, usuarios compartidos y conexiones externas. El error concreto que provoca mayor fricción es no identificar usuarios con roles compartidos entre subsites.
Ejecución: exportar, ajustar y validar
Exportar wp-content/uploads/sites/{ID} y tablas wp_{blogid}_*. Ejecutar search-replace para dominios y validar certificados TLS y webhooks.
Probar logins de profesor y alumno.
Una guía práctica de migración desde Multisite hacia instalaciones separadas (y retorno inverso) debe contener pasos reproducibles:
- Inventario y bloqueo en lectura del subsite
- Volcado de tablas específicas del subsite con mysqldump --single-transaction --skip-lock-tables mi_bd wp_12_* > subsite12.sql (reemplazar 12 por blogid)
- Exportar uploads con rsync -a /var/www/html/wp-content/uploads/sites/12/ /newsite/wp-content/uploads/
- Exportar usuarios filtrando por usermeta y remapear IDs si hay colisiones
- Importar SQL en la nueva base de datos. Ejecutar wp search-replace para ajustar dominios y GUID:
wp search-replace 'old.example.com' 'new.example.com' --skip-columns=guid --path=/newsite --precise
- Regenerar salts, revisar certificados TLS y configurar CDN para cursos pesados.
- Pruebas funcionales: logins de profesor/alumno, pruebas de carga y validación de webhooks y pasarelas de pago.
Documentar cada paso y disponer de un rollback con snapshot de origen.
Contenerización y separación de base de datos
Separar bases de datos y usar contenedores por servicio reduce el blast radius en caso de intrusión. La mayoría de guías no incluyen esta capa y eso produce vulnerabilidades evitables.
Contenedores bien configurados reducen riesgos de seguridad importantes.
DB por sitio o per-schema
Mantener bases de datos separadas o schemas por sitio limita el acceso en caso de credenciales comprometidas. Esto requiere más operaciones, pero reduce impacto.
Contenedores y orquestación
Desplegar cada sitio en contenedor con red aislada y políticas IAM mejora seguridad. Incorporar CI/CD con pruebas SAST y DAST antes del despliegue completa la cadena.
La evidencia práctica y normativa muestra que WordPress concentra mucha superficie de ataque. WordPress atiende cerca del 43% de los sitios web, según W3Techs.
La Directiva NIS2 se aprobó recientemente y amplía las obligaciones de seguridad para los proveedores de servicios digitales. El RGPD exige medidas técnicas y organizativas documentadas.
Un caso habitual: una academia con 1.200 alumnos concurrentes y cursos de 800 MB por alumno. Migró de Multisite a instalaciones separadas tras un incidente.
Resultado: redujeron el tiempo de contención de 3 horas a 45 minutos. La auditoría de privacidad quedó resuelta para cada entidad.
Funciona bien en teoría; en la práctica la migración exige planificación de usuarios y pruebas de restore para evitar pérdida de datos.
Opinión con criterio práctico para operativa
Para academias que comparten propietario legal y contenidos comunes, Multisite funciona bien porque reduce horas de mantenimiento y despliegues. La excepción es cuando se necesita aislamiento legal o cada academia procesa pagos o datos sensibles.
En esos casos, las instalaciones separadas protegen frente a auditorías y facilitan restores. La recomendación es medir concurrencia y tamaño de media.
Probar restores parciales y elegir la opción que minimice riesgo legal y tiempo de recuperación.
No aplique Multisite cuando cada academia sea entidad legal separada o requiera reglas distintas de GDPR/LOPDGDD. Ni si procesa datos de pago o salud, o necesita versiones PHP o configuración distinta por sitio.
Es posible solicitar un diagnóstico al equipo de mantenimiento. El diagnóstico debe incluir tiempos y costes estimados según la matriz anterior.
Preguntas frecuentes
¿Me conviene multisite si tengo 10 academias?
Puede convenir si una sola entidad legal gestiona las diez academias. Multisite reduce el trabajo de actualizaciones y despliegues. Si cada academia tiene un DPO distinto o reglas RGPD separadas, instalar por separado es más seguro.
¿Se puede restaurar solo una academia en multisite?
Sí, se puede, pero no es inmediato. Requiere extraer uploads del sitio y las tablas wp_{blogid}_* y luego importar y ajustar URLs. Hacer ensayos de restore semestrales da tiempos reales de recuperación.
¿Qué pasa si un plugin se compromete en multisite?
Puede afectar a varios subsites si tiene capacidades globales. Forzar 2FA en superadmins, revisar capabilities y aplicar WAF reduce el alcance. Auditar plugins antes de activarlos evita muchas intrusiones.
¿Instalaciones separadas reducen costes a largo plazo?
No siempre reducen costes a largo plazo. Aumentan horas de mantenimiento y hosting por sitio. Pero bajan costes indirectos tras un incidente por menor alcance legal.
¿Qué umbrales de concurrencia recomiendan probar?
Probar con 100, 1.000 y 5.000 usuarios concurrentes. Medir p95 y p99 de latencia y tasa de errores. Estos escenarios muestran si hace falta CDN o autoescalado.
¿Cómo afecta el RGPD a la elección arquitectónica?
Si las academias son entidades distintas, RGPD exige segregación de datos. Instalar sitios separados o usar aislamiento fuerte con logging facilita auditorías. Documentar tratamientos y acuerdos de encargado es obligatorio.
¿Qué opciones de hosting recomiendan para cada caso?
Para Multisite, hosts gestionados con soporte para Multisite son prácticos. Ejemplos: SiteGround, WP Engine y Kinsta ofrecen WAF y snapshots integrados. Para instalaciones separadas, use contenedores en cloud y buckets por sitio con IAM.
El plan concreto
Elegir arquitectura exige un plan con pasos medibles. Incluya inventario, pruebas de carga y ensayos de restores antes de decidir.
Paso 1: inventario técnico
Listar plugins, themes, tamaños de uploads y dependencias externas. Sin inventario no se puede estimar riesgo ni coste.
Paso 2: pruebas y backup
Realizar pruebas de carga en 100/1.000/5.000 concurrencia y ensayos de restore parcial. Mantener micro-backups por subsite o separar instalaciones según resultado.
Paso 3: decidir y ejecutar migración
Si decide migrar, prepare scripts WP-CLI, export SQL selectivo y un plan de rollback. Validar en staging y medir tiempo de corte.
Referencias y lecturas útiles: la documentación oficial de Multisite describe la estructura y las tablas. Ver WordPress.org - Crear una red y las guías de la AEPD para tratamientos y responsabilidades.
