Cuándo NO usar WordPress Multisite (y qué usar en su lugar)
WordPress Multisite parece la respuesta obvia la primera vez que miras diez instalaciones de clientes y diez ciclos de actualización. Un dashboard, un solo inicio de sesión, un lugar para gestionar todo. La propuesta es perfecta.
El problema aparece más tarde, usualmente en el peor momento posible: una actualización de plugin tumba todos los sitios de clientes a la vez, o un cliente pide llevarse su sitio a otro lado y te das cuenta de que la extracción es un proyecto de todo el fin de semana. Multisite optimiza para una red que actúa como una sola. La mayoría del trabajo con clientes es lo opuesto: propietarios separados, necesidades separadas, salidas separadas.
Aquí tienes las situaciones específicas donde Multisite es la decisión equivocada, qué se rompe en cada una, y la configuración centrada en el aislamiento que evita el problema.
1. Cuando cada cliente necesita un stack diferente de plugin y theme
Multisite comparte un solo directorio wp-content en todos los subsitios. Los plugins se instalan a nivel de red, y luego se activan en la red o se habilitan por sitio, pero todos viven en los mismos archivos y cargan desde el mismo lugar. Un plugin que un cliente necesita y que otro cliente nunca debe ejecutar, sigue estando en el código base compartido para ambos.
Esa limitación pelea contigo constantemente en el trabajo con clientes, donde el punto principal es que el Cliente A obtiene un plugin de reservas, el Cliente B obtiene un stack de membresías, y ninguno debería heredar la carga o la superficie de ataque del otro.
La alternativa: aislamiento verdadero por tenant. GrabWP Tenancy Pro le da a cada tenant su propio directorio wp-content, por lo que los themes y plugins están genuinamente separados por cliente en lugar de estar compartidos y alternados. El conjunto de plugins de un cliente no tiene impacto en el de otro.
2. Cuando un cliente podría irse en algún momento
Esta es la que más cuesta silenciosamente. En Multisite, el sitio de un solo cliente está enredado en la database de la red con tablas e IDs de blog compartidos. Sacar un subsitio para entregarlo a un cliente, o para moverlo a su propio hosting, es un trabajo de exportación y cirugía de múltiples pasos, y las herramientas de exportación de Multisite son famosamente frágiles.
Si alguna parte de tu negocio implica terminar un sitio y entregarlo, Multisite ha creado una atadura con la que tendrás que lidiar cada vez.
La alternativa: exportación limpia por tenant. GrabWP Tenancy Pro hace un backup de un tenant individual como un archivo autosuficiente, y el plugin gratuito GrabWP Restore reconstruye ese tenant como un sitio WordPress completamente independiente en cualquier host. Restore transmite la importación de la database, reescribe los prefijos de las tablas para que coincidan con el destino, y ejecuta una búsqueda y reemplazo de URLs en toda la database que maneja correctamente los datos serializados, para luego auto-actualizar la URL del sitio. El cliente se va con una instalación normal de WordPress y sin depender de ti.
3. Cuando el problema de un cliente no debe convertirse en el problema de todos
Multisite es una arquitectura de destino compartido por diseño. Una database, un árbol de archivos, un core. Una mala actualización de plugin, una tabla corrupta, o un subsitio comprometido no está contenido: reside dentro de la misma database y sistema de archivos que cualquier otro cliente. No hay un radio de impacto natural alrededor de un solo sitio.
Para una red de hobby eso es un intercambio aceptable. Para un grupo de clientes, cada uno pagando por su propio uptime, es una responsabilidad que estás cargando en su nombre.
La alternativa: databases dedicadas y puntos de restore por tenant. GrabWP Tenancy Pro permite que cada tenant funcione en un prefijo MySQL compartido, una database MySQL completamente dedicada, o su propia database SQLite, de modo que los datos del tenant pueden estar completamente separados con cero tablas compartidas. Su flujo de trabajo de restore por tenant de 8 pasos revierte el sitio de un cliente desde el propio backup de ese cliente sin tocar a ningún otro tenant. El mal día de un sitio sigue siendo el mal día de un solo sitio.
4. Cuando tu host hace que Multisite sea un dolor (o lo prohíbe)
Muchos hostings administrados de WordPress no soportan Multisite, lo restringen, o cobran más por él. Incluso donde funciona, un Multisite basado en subdominios arrastra una configuración de DNS comodín y SSL que convierte una tarea de cinco minutos en un ticket de soporte.
La alternativa: enrutamiento que no necesita malabares de DNS. GrabWP Tenancy soporta dominios personalizados completos por tenant y enrutamiento basado en rutas, donde un tenant vive en yoursite.com/site/client-a sin ningún cambio de DNS por cliente. Obtienes hosting multi-sitio en un hosting normal de un solo sitio.
5. Cuando en realidad solo quieres la eficiencia de una sola instalación sin el acoplamiento
La verdadera razón por la que la gente acude a Multisite no son las características de red. Es que no quieren actualizar el core de WordPress diez veces. Ese es un objetivo legítimo, pero Multisite lo empaqueta con databases compartidas, plugins compartidos, y un offboarding doloroso que nunca pediste.
La alternativa: desacoplar ambos. El multi-tenancy te da la victoria en la gestión de una sola instalación, actualizar el core una vez, un solo dashboard, clonar un tenant inicial para cada nuevo cliente, mientras mantienes el aislamiento de las instalaciones separadas. Obtienes la eficiencia sin el acoplamiento.
Multisite vs instalaciones separadas vs multi-tenancy, de un vistazo
| WordPress Multisite | Instalaciones separadas | GrabWP Tenancy | |
|---|---|---|---|
| Actualizaciones del core | Una vez | Por instalación | Una vez |
| Aislamiento de datos | Database compartida (prefijo + blog ID) | Completo | Completo con Pro (database dedicada) |
| Plugins/themes por cliente | wp-content compartido | Total | Total con Pro (wp-content aislado) |
| Offboarding de clientes | Extracción compleja | Simple | Simple (exportación Pro + Restore gratuito) |
| Radio de impacto de una falla | Todos los sitios | Un sitio | Un sitio |
| Requisitos de hosting | Frecuentemente restringidos | Estándar | Estándar (enrutamiento por ruta o dominio) |
Entonces, ¿cuándo es correcto usar Multisite?
Para ser justos: Multisite es una buena opción cuando la red genuinamente se comporta como una sola cosa. Una universidad ejecutando docenas de sitios de departamentos en un mismo set compartido de theme y plugin, una empresa de medios ejecutando ediciones regionales de la misma publicación, una intranet interna de sitios casi idénticos bajo un solo equipo de TI. Marca compartida, stack compartido, un solo propietario administrativo, baja rotación. Si eso te describe, Multisite está haciendo exactamente aquello para lo que fue construido.
El trabajo con clientes casi nunca es así. Diferentes clientes quieren plugins diferentes, son dueños de sus propios datos, y eventualmente se van. En el momento en que es verdad la frase “estos sitios son en realidad negocios separados que casualmente administro juntos”, la arquitectura compartida de Multisite está trabajando en tu contra.
La configuración que la mayoría de freelancers y agencias realmente quieren
Para gestionar múltiples sitios de clientes independientes, el multi-tenancy da en el punto medio que Multisite y las instalaciones separadas fallan en alcanzar: gestión centralizada como Multisite, aislamiento genuino como instalaciones separadas, y una salida limpia para cualquier cliente en cualquier momento.
El plugin base GrabWP Tenancy es gratuito y te da uploads aislados, prefijos de tabla, y enrutamiento por dominio o ruta. El plan Pro añade databases dedicadas, wp-content por tenant, y backup y restore por tenant desde $9.99/month.
Si quieres el desglose arquitectónico completo, lee WordPress Multisite vs Multi-Tenancy. Si estás listo para sacar un sitio de una red existente, mira cómo aislar sitios de clientes de WordPress sin Multisite.
Preguntas frecuentes
- ¿Es WordPress Multisite alguna vez la opción correcta?
- Sí, para una red de sitios que genuinamente comparten un solo stack de theme y plugin, y un solo equipo administrativo, como la red de un departamento universitario o una cadena de sitios de sucursales casi idénticos. Multisite es la opción incorrecta cuando cada sitio necesita plugins diferentes, datos separados, o una entrega limpia a un propietario distinto, lo cual es la norma en el trabajo con clientes.
- ¿Cuál es el riesgo principal de alojar sitios de clientes en WordPress Multisite?
- El destino compartido. Todos los subsitios comparten una database y un directorio wp-content, por lo que una mala actualización de plugin, una tabla corrupta, o un problema de seguridad puede afectar a todos los sitios a la vez. No hay un radio de impacto por sitio, que es lo opuesto a lo que quieres cuando diferentes clientes están pagando por su uptime.
- ¿Cómo se obtiene la gestión centralizada sin la database compartida de Multisite?
- Con multi-tenancy. GrabWP Tenancy ejecuta cada cliente como un tenant aislado desde una sola instalación de WordPress. Mantienes un solo dashboard y un core para actualizar, pero cada tenant tiene su propio prefijo de tabla y directorio uploads, y con Pro, una database completamente dedicada y su propio directorio wp-content.
Editorial standards: Our content is written by WordPress experts with hands-on multi-tenancy experience. Articles are fact-checked and regularly updated to ensure accuracy.