¿Necesitamos Multisitio o simplemente varios sitios WordPress?

La prueba es la gobernanza compartida, no la cantidad de sitios. Lo definen cuatro preguntas: ¿Los sitios comparten un tema o un sistema de diseño? ¿Las mismas personas administran más de uno de ellos? ¿Necesitan parchearse y actualizarse en el mismo ciclo? ¿Alguien necesita una vista única de quién tiene acceso a qué? Tres o más respuestas afirmativas y una red suele pagarse sola. Una o ninguna, y las instalaciones separadas son la recomendación honesta.

¿Qué plugins se rompen en una red Multisitio?

No hay una lista fija, y ese es el problema. Los patrones, en cambio, son consistentes: Plugins que asumen un único set de opciones y escriben la configuración de toda la red en un solo subsitio. Plugins cuya licencia está atada a un dominio y no logra resolver una red. Plugins que traen su propio manejo de usuarios o roles, que después compite con la tabla de usuarios compartida de la red. Validamos el set de plugins contra una instalación de red antes de que algo se vuelva una dependencia, y donde algo no se sostiene lo reemplazamos o movemos la función a la capa del tema.

¿Cómo comparten medios y contenido los subsitios?

Por defecto no lo hacen, y en general está bien así: las bibliotecas de medios por sitio mantienen las subidas acotadas y los permisos simples. Cuando hace falta compartir, hay dos problemas distintos. Los medios compartidos necesitan una solución dedicada, para que un activo de marca viva en un solo lugar en vez de subirse once veces. El contenido dinámico compartido, un feed combinado de posts de todos los subsitios o un listado de eventos de toda la red, necesita lógica propia sobre la REST API. Qué se comparte, qué se replica y qué queda local se define de entrada y se documenta. Si además cada subsitio corre en su propio idioma, esa decisión va junto con la arquitectura multilingüe y no después.

¿Puede cada equipo manejar su propio sitio sin romper la red?

Para eso está el plan de gobernanza, escrito antes de que exista cualquier subsitio. Cada subsitio tiene una respuesta explícita sobre quién puede publicar, quién puede cambiar la navegación, quién puede cambiar el branding y quién tiene super admin. El detalle está en la gestión de usuarios y permisos. La instalación de plugins y temas queda a nivel red. No es una cuestión de confianza, es una cuestión de radio de impacto: un plugin activado en toda la red afecta a todos los sitios. Los editores tienen autoridad real sobre el contenido, sobre el branding dentro del sistema de bloques y sobre su propia navegación. Lo que no tienen es la capacidad de cambiar la plataforma que sostiene a los demás subsitios.

¿Qué hosting soporta Multisitio?

WordPress VIP, WP Engine y Kinsta soportan instalaciones de red. No todas las plataformas enterprise lo hacen, así que lo confirmamos antes de aprobar la arquitectura. Una red sobre un host que no la soporta bien es el tipo de retrabajo más caro que existe, y cuando WordPress VIP no es el camino elegido, elegimos el host por compliance y presencia regional, no por precio.

Multisitio

WordPress Multisitio enterprise: infraestructura compartida, autonomía delegada, control central

Q: ¿Subdominios, subdirectorios o dominios mapeados?

Las tres opciones funcionan. No son intercambiables. Los subdirectorios (ejemplo.com/legal/) mantienen todos los subsitios en un mismo hostname, lo que concentra la autoridad de búsqueda y la analítica. Los subdominios (legal.ejemplo.com) le dan a cada unidad una identidad más clara y una separación más limpia de cookies y de tracking. Los dominios mapeados (revistalegal.org) son para unidades que tienen que ser su propia marca en público, con dominio propio y no con un subdominio del tuyo. Esto lo definimos en la fase de descubrimiento y no durante el desarrollo, por una razón: cambiarlo cuando ya hay contenido es una migración de URLs, con redirecciones y un período en el que la búsqueda vuelve a aprender el sitio.

Un solo core de WordPress corriendo muchos sitios, con la estrategia de dominios, la compatibilidad de plugins y los límites de cada rol definidos antes de encender la red. Multisitio es una decisión de arquitectura, no una línea en wp-config.

Inicio
Capacidades
Multisitio

Lo que definimos primero

Cinco decisiones que determinan si la red se sostiene

Una red elimina trabajo duplicado y concentra riesgo: un core, un set de plugins, una tabla de usuarios compartida. Estas son las decisiones que separan una red que escala de una que después hay que desarmar.

Subdominios, subdirectorios o dominios mapeados

sitio.ejemplo.com, ejemplo.com/sitio/ o un dominio registrado aparte, como revistalegal.org. Se comportan distinto en búsqueda, SSL, analítica y alcance de cookies, y revertir la elección cuando ya hay contenido significa una migración de URLs. Lo definimos en la fase de descubrimiento, contra cómo está estructurada realmente la organización.

Compatibilidad de plugins en toda la red

No todos los plugins se comportan bien en una instalación de red: algunos asumen un único set de opciones, otros traen su propio manejo de usuarios y otros directamente no se pueden activar a nivel red. Validamos el set de plugins contra una red antes de que se convierta en una dependencia.

Roles y límites de permisos por subsitio

Super admin, admin de sitio y todo lo que está debajo, escrito antes de que exista el primer subsitio. Cada equipo recibe autoridad explícita sobre su propio sitio y un límite explícito en el borde de la red.

Qué se comparte, qué se replica y qué queda local

Las bibliotecas de medios son por sitio de forma predeterminada, y compartirlas entre sitios exige una solución deliberada. Compartir contenido dinámico entre subsitios exige lógica propia sobre la REST API. Definimos las reglas una vez y las dejamos documentadas.

Un tema base con sobrescrituras por subsitio

Un solo sistema de bloques en toda la red, con branding, navegación y configuración sobrescribibles por subsitio. Los sitios nuevos salen de una plantilla en lugar de arrancar de cero, y de ahí sale el ahorro operativo.

Prueba

Gobernanza central y publicación local, a escala enterprise

Commvault opera una plataforma global sobre WordPress VIP donde los equipos de marketing regionales publican por su cuenta, dentro de permisos por rol y un único sistema de bloques compartido. Multisitio es una de las formas de conseguir esa estructura; estos son los resultados con los que se la mide.

2.5x

Más rápido para publicar tras pasar a un sistema de bloques gobernado

65%

De reducción en la dependencia del equipo de desarrollo para el contenido de rutina

5 regiones

Publican contenido desde una única arquitectura central

Cuándo no usarlo

Tres casos en los que te decimos que no uses Multisitio

Multisitio es la decisión correcta lo bastante seguido como para que se proponga por reflejo, y el costo de darse cuenta tarde es una migración. Estas son las situaciones en las que recomendamos otra cosa.

Los sitios son realmente independientes

Si las propiedades no comparten tema, ni set de plugins, ni usuarios, ni ciclo de actualizaciones, una red agrega acoplamiento y no devuelve nada. Un release pasa a tocar sitios que no tenían por qué verse afectados. Las instalaciones separadas son la respuesta honesta, aunque salgan más caras de mantener.

El stack de plugins no sobrevive a una red

Hay funcionalidad que solo existe en plugins que nunca fueron pensados para una instalación de red. Si un plugin crítico para el negocio es uno de esos, la opción es reconstruir esa función o quedarse con instalaciones separadas.

Nadie se hace cargo del plan de gobernanza

Una red necesita a alguien con autoridad para decidir quién administra qué. Sin eso, el modelo de permisos se negocia sitio por sitio y la red termina siendo más difícil de operar que los sitios separados que reemplazó.