La mayoría de los consejos sobre cómo instalar WordPress Multisite empiezan por el lado equivocado. Empiezan wp-config.php, te dicen dónde pegar una constante y tratan la red como si fuera una actualización técnica.
Eso está al revés.
La arquitectura multisitio es una apuesta de fondo. Puede simplificar la gestión, la publicación y el mantenimiento de la plataforma. Pero también puede hacer que sitios que no tienen nada que ver entre sí queden encadenados a un único modelo operativo, una única ruta de implementación y un único dominio de fallos. La instalación se hace en unos minutos. Pero vivir con esa decisión te lleva años.
Table of Contents
Esto es importante porque el propio WordPress opera a una escala enorme. WordPress da servicio al 43,5 % de todas las páginas web del mundo, y en marzo de 2025 había unos 1.19 mil millones de páginas web en línea, por lo que Multisite sigue siendo relevante para las empresas que gestionan entornos multilingües, con varios dominios o en varias ubicaciones en el CMS dominante (resumen de estadísticas de WordPress de Pantheon). La función está madura. La pregunta más importante es si tu organización también lo está.
Cuándo usar WordPress Multisite y cuándo evitarlo
Los equipos suelen recurrir a Multisite cuando lo que realmente necesitan es una mejor gestión, no una arquitectura compartida. Son problemas distintos.
Usa Multisite cuando necesites que muchos sitios funcionen dentro de una misma plataforma controlada. Suele ser ideal para franquicias, universidades, agencias, redes de editores y grupos empresariales con patrones de sitios repetitivos, requisitos de autenticación compartidos, sistemas de diseño comunes y una gestión centralizada de los plugins. WordPress Multisite se creó precisamente para ese tipo de escala. Una red puede alojar varios sitios web desde una sola instalación, y algunas organizaciones gestionan «cientos o incluso miles» de sitios web en una sola red (Fellowship sobre WordPress Multisite).
Evítalo cuando los sitios solo parezcan similares en una presentación. Si las unidades de negocio necesitan calendarios de lanzamiento independientes, diferentes conjuntos de plugins, decisiones de alojamiento independientes, una separación jurídica estricta o la libertad de alejarse de un sistema de temas compartido, Multisite se convierte en un obstáculo.
Señales de que te queda bien
- La gestión centralizada es importante: un equipo de la plataforma tiene que controlar los temas, los plugins y la política de usuarios en muchos sitios web.
- Los diseños de las instalaciones se repiten: las nuevas instalaciones son variaciones de un proyecto ya aprobado, no construcciones a medida.
- Las operaciones compartidas son una ventaja: la seguridad, el mantenimiento y las normas editoriales deben aplicarse de forma centralizada.
- Se prevé una expansión: los equipos que planean lanzamientos regionales o crean micrositios escalables suelen beneficiarse de un modelo de red repetible.
Señales de que no encaja bien
- Cada sitio web funciona como si fuera un producto independiente: las hojas de ruta independientes y las integraciones personalizadas suelen requerir instalaciones separadas.
- La autonomía de los plugins es fundamental: Multisite limita la libertad por su propia naturaleza.
- La organización está descentralizada políticamente: la centralización técnica rara vez sobrevive al caos en la gestión.
- La separación de datos es un requisito imprescindible: las instalaciones independientes suelen ser más claras, tanto desde el punto de vista operativo como contractual.
Regla práctica: si a tu equipo le interesa más el control compartido que la comodidad compartida, Multisite puede ser una buena opción. Si lo que buscan es comodidad compartida pero esperan excepciones locales en todas partes, normalmente no lo será.
Para los equipos de empresas que necesitan ayuda de expertos a la hora de sopesar esa disyuntiva antes de empezar a desarrollar, las soluciones de WordPress para empresas suelen ser más útiles que otra lista de comprobación de configuración.
Los subdominios frente a los subdirectorios: una decisión clave
Lo primero que hay que decidir en una instalación multisitio no es el código, sino la estructura de las URL.
La mayoría de los tutoriales se saltan este paso, aunque si te equivocas, esta decisión puede acarrear problemas de migración a largo plazo. El propio material de aprendizaje de WordPress deja un vacío en este aspecto. A los equipos se les enseña cómo habilitar la red, pero no cómo valorar si la opción del subdominio permanente o del subdirectorio se adapta a su modelo operativo (lección sobre la configuración de WordPress.org Multisite).
¿Qué cambia en cada estructura?
| Estructura | Es mejor cuando | Normalmente es más difícil cuando |
|---|---|---|
| Subdominios | Las páginas web necesitan una separación más clara, ritmos de lanzamiento distintos o, con el tiempo, dominios propios | DNS, planificación de SSL y configuración del entorno |
| Subdirectorios | Los sitios web deben estar asociados a una marca principal y dar la sensación de ser secciones de un mismo sitio web unificado | Separaciones futuras, cambios de dominio y algunos patrones de migración |
Los subdirectorios permiten que todo quede visiblemente bajo una misma marca principal. Esto suele resultar más claro para un equipo central de marketing. Además, reduce la cantidad de coordinación inicial relacionada con el DNS y suele simplificar el primer lanzamiento.
Los subdominios marcan límites más claros. Suelen ser la opción más segura para las redes empresariales en las que cada región, departamento o línea de negocio necesita ahora una identidad propia, aunque todo se gestione de forma centralizada entre bastidores.
SEO y sus implicaciones para la marca
Esta decisión nunca es solo técnica.
Los subdirectorios suelen tener sentido cuando el dominio principal es la marca y cada sitio web existe para reforzar esa marca. Las secciones por países, los centros de contenido de unidades de negocio o las áreas de campaña pueden funcionar bien en este modelo si la gestión es rigurosa y la experiencia del usuario está unificada. Los equipos que estén planteándose la estructura del sitio a ese nivel también deberían revisar cómo la navegación y el diseño de las URL afectan a la visibilidad en esta guía sobre el potencial SEO de las URL en la navegación web.
Los subdominios tienen más sentido cuando cada sitio web debe percibirse como algo independiente. Una red de franquicias, un programa de socios o una operación autónoma a nivel regional suelen beneficiarse de esa separación. Te permite tener una estructura más clara a la hora de asignar dominios más adelante y evitar compromisos incómodos a medida que los sitios web evolucionan.
Elige subdirectorios cuando la red sea una sola marca con muchas secciones. Elige subdominios cuando se trate de una sola plataforma con muchas identidades.
Consecuencias operativas que los equipos subestiman
Los subdominios aumentan el trabajo de infraestructura. Tienes que pensar bien en cómo funcionan los comodines, la cobertura SSL y cómo se resuelven los nuevos sitios antes de que los editores empiecen a usar el panel de control.
Los subdirectorios parecen más sencillos al principio, pero pueden salir caros si más adelante hay que trasladar el sitio a su propio dominio o sacarlo de la red. Ese es el coste oculto que la mayoría de las guías de inicio rápido pasan por alto.
Una prueba útil es esta: pregúntate si algún sitio web podría necesitar, en los próximos años, su propia marca, dominio o gestión semindependiente. Si la respuesta es sí, los subdominios suelen ser la opción más segura para empezar. Si la respuesta es no y la empresa quiere una presencia web muy unificada, los subdirectorios suelen funcionar mejor a largo plazo.
Cómo preparar tu entorno de alojamiento web y DNS
La implementación de un sitio multisitio falla mucho antes de que falle WordPress. Falla en el DNS, en la planificación de los certificados, en las suposiciones sobre el almacenamiento en caché y en la elección de un alojamiento deficiente.
Si esta red es para producción, considera la capa de alojamiento como parte del diseño de la aplicación. No la veas como algo secundario que ya resolverás más adelante.
¿Qué significa realmente «estar listo para la producción»?
Para una red seria, el entorno tiene que permitir un aprovisionamiento repetible, implementaciones controladas y un comportamiento de enrutamiento predecible. Eso significa que tu equipo de infraestructura y tu equipo de WordPress deben ponerse de acuerdo sobre cómo funcionan los dominios, los certificados, las redirecciones, las capas de caché y los entornos de prueba antes de que se active la red.
Una planificación deficiente suele hacer que muchos proyectos se descarrilen. Los desarrolladores pueden instalar WordPress Multisite correctamente, pero si nunca se han planificado los registros DNS, la cobertura de los certificados y el comportamiento del proxy inverso, el primer lanzamiento de un dominio en producción se convierte en una cadena interminable de incidencias de soporte técnico.
Lista de comprobación previa a la instalación
- Elige un alojamiento que conozca bien el funcionamiento de WordPress: el alojamiento compartido genérico no es la base adecuada para una red que tenga que dar soporte a varias marcas o mercados.
- Planifica con antelación cómo funcionarán los comodines: si usas subdominios, la infraestructura tiene que ser compatible con la forma en que se resolverán los nuevos sitios web.
- Define quién se encarga de los certificados SSL: decide si los certificados los gestiona el proveedor de alojamiento, el equipo de la plataforma o un equipo de operaciones externo.
- Comprueba que la reescritura sea compatible: las reglas de Apache o Nginx tienen que ajustarse a cómo WordPress va a redirigir los sitios de la red.
- Separa el entorno de pruebas de las expectativas de producción: una red de pruebas debería reflejar el comportamiento del dominio y de la caché con suficiente precisión como para detectar los problemas de lanzamiento antes de que lleguen a los usuarios.
La puesta en escena no es opcional
Una configuración de entorno de pruebas multisitio no sirve solo para probar el código. Es donde validás todo el proceso, desde la creación del sitio hasta la asignación del dominio y la puesta en marcha segura. Sin eso, tu primer lanzamiento real se convierte en una prueba de fuego.
Los equipos que aún no hayan formalizado esto deberían, al menos, seguir un proceso claro para el entorno de pruebas, de modo que las configuraciones de DNS, el aprovisionamiento de SSL y el orden de implementación se prueben en condiciones controladas.
Si el equipo de tu proveedor de alojamiento te dice «podemos solucionar la asignación de dominios después de la instalación», detén el proyecto. Las correcciones en la infraestructura tras la instalación son donde los planes de Multisite bien organizados empiezan a complicarse.
Qué debes decidir antes de ponerte con WordPress
| Área | Decisión de imponer el confinamiento |
|---|---|
| Dominios | ¿Qué sitios usarán primero las URL de la red y cuáles se lanzarán en dominios asignados? |
| Certificados | Cómo se emiten, renuevan y validan los certificados SSL en toda la red |
| Almacenamiento en caché | Si las reglas de caché se comparten o están aisladas por sitio |
| Entornos | Cómo gestionan los dominios asignados los entornos de prueba, la preproducción y la producción |
| Modelo de asistencia | ¿Quién se encarga de los cambios en el DNS, los plazos de lanzamiento y las decisiones de reversión? |
Una instalación Multisite estable depende menos de la define() línea de código de lo que se suele creer. Lo difícil es conseguir que el entorno sea lo suficientemente predecible como para que cada lanzamiento de un nuevo sitio siga el mismo patrón operativo.
Activación y configuración de la red de WordPress
La instalación en sí es sencilla. Lo importante es el orden de los pasos.
Una instalación multisitio de WordPress es un proceso en dos fases. Primero, activa la función añadiendo define('WP_ALLOW_MULTISITE', true); a wp-config.php. A continuación, ve a Herramientas → Configuración de la red para elegir la estructura de la red y generar el código final necesario tanto para wp-config.php y .htaccess (guía de instalación de MultilingualPress).
Empieza haciendo una copia de seguridad y abriendo una sesión de administrador limpia. Desactiva los plugins antes de habilitar la red. Así reduces los problemas durante la configuración y evitas tener que solucionar fallos en el comportamiento de los plugins que no tienen nada que ver con Multisite en sí.
Primera fase: activación de la función
Edita wp-config.php y añade:
define('WP_ALLOW_MULTISITE', true);
Colócalo encima de la línea que dice /* That's all, stop editing! */.
Esa línea no crea la red por sí sola. Lo que hace es mostrar la pantalla de configuración de la red en el panel de administración de WordPress para que la aplicación pueda generar el resto de la configuración según la estructura que hayas elegido.
Segunda fase: generar la configuración de la red
En el panel de administración, ve a Herramientas → Configuración de red.
Elige subdominios o subdirectorios, introduce el título de la red y los datos de administrador, y deja que WordPress genere los fragmentos de código necesarios. Obtendrás un bloque para wp-config.php y otro para .htaccess.
Las reglas generadas no son meramente decorativas. Le indican a WordPress cómo reconocer las solicitudes de la red, enrutarlas correctamente y gestionar la estructura de URL reescrita de la que depende la red.
Este es el proceso que funciona bien:
- Haz primero una copia de seguridad: de los archivos y de la base de datos.
- Desactiva los plugins: sobre todo los relacionados con redireccionamientos, seguridad o almacenamiento en caché de páginas.
- Añade la constante Multisite: Guarda
wp-config.php. - Ejecuta la configuración de red: elige el modelo de URL que ya hayas decidido.
- Pega el código generado con cuidado: coloca cada bloque en el archivo correcto.
- Vuelve a iniciar sesión: WordPress actualiza los permisos y muestra la nueva interfaz de red.
Un vídeo tutorial puede ayudarte si quieres comparar tus pasos con un flujo de configuración visual:
Errores comunes durante la instalación
- Dejar plugins activos: esto suele provocar falsas alarmas durante el primer inicio de sesión tras la conversión.
- Pegar el código en el lugar equivocado:
wp-config.phpy.htaccesshacen cosas diferentes. No los mezcles. - Ignorar las reglas de reescritura existentes: si la web ya tenía un comportamiento de servidor personalizado, fusiona con cuidado en lugar de sobrescribir a ciegas.
- Considerar la actualización del inicio de sesión como un error: es normal que tengas que volver a autenticarte tras la configuración.
Qué hace el código generado
Los valores añadidos wp-config.php le indican a WordPress que el sitio ahora es una red y definen cómo debe comportarse esa red. Las .htaccess reglas se encargan de reescribir las URL para que las solicitudes lleguen al sitio correcto dentro de la red.
No hace falta que te aprendas de memoria todas las directivas, pero sí debes respetar el orden y los límites del archivo. La mayoría de las instalaciones fallidas se deben a que alguien ha copiado el fragmento de código correcto en el lugar equivocado o ha generado la estructura antes de que se decidiera la infraestructura.
Cómo dominar el panel de administración de la red
El primer día tras la instalación te dirá si la red se mantendrá en orden.
Un superadministrador inicia sesión, abre «Mis sitios» y ve un nuevo plano de control. Ese es el momento en el que Multisite deja de ser un simple ejercicio de configuración y empieza a convertirse en un modelo operativo.
Prioridades del primer día
La primera tarea no es crear más sitios. Es definir qué pueden hacer los administradores de los sitios.
Crea la estructura inicial de los sitios. Añade uno o dos sitios representativos, no veinte. Instala solo los temas y plugins que la red esté preparada para soportar. Decide qué plugins se activan a nivel de red y cuáles están disponibles para su activación en cada sitio local. Si te saltas ese paso de gestión, los editores y los administradores de los clientes empezarán a tratar la red como si fuera una instalación normal de WordPress de un solo sitio, y te pasarás el mes siguiente solucionando excepciones que se podrían haber evitado.
Una secuencia disciplinada para el primer día sería algo así:
- Crea los sitios básicos: la marca principal, un sitio regional y un sitio de prueba.
- Limita el catálogo de plugins: instala solo lo que la red haya acordado admitir.
- Establece los roles de usuario con cuidado: separa inmediatamente los poderes de superadministrador de los de administrador de sitio.
- Revisa la configuración de registro: no dejes vías abiertas para la creación de sitios o usuarios a menos que sea intencionado.
El panel de control cambia cómo funcionan las responsabilidades
En una instalación estándar, cada administrador de sitio puede sentirse con total autonomía. En Multisite, esa autonomía es parcial.
El administrador de la red se encarga de la instalación de plugins, la disponibilidad de temas y la política general de usuarios. Los administradores de sitio gestionan el contenido, los menús, los widgets y la configuración local dentro de los permisos que se les han otorgado. Esa división es saludable cuando está documentada. Es caótica cuando se da por sentada.
Una red Multisite estable tiene menos libertades que un conjunto disperso de sitios individuales. Eso es una ventaja, no un defecto.
Un modelo práctico de gestión
Un modelo útil es tratar la red como un producto de plataforma:
| Función | Posee |
|---|---|
| Superadministrador | Actualizaciones del núcleo, temas, inventario de plugins, configuración de red |
| Administrador del sitio | Contenido, medios, menús y activación de plugins locales, si está permitida |
| Responsable de la plataforma | Normas, autorizaciones de lanzamiento, política de publicación |
| Noticias destacadas | Taxonomías, flujos de trabajo, calidad del contenido |
Esa estructura ayuda a las agencias y a los equipos empresariales a evitar el error más común en los paneles de control. Instalan Multisite para centralizarlo todo, pero luego conceden permisos que vuelven a provocar la fragmentación.
Otro hábito que vale la pena mantener desde el primer día es la disciplina en la denominación. Los slugs de los sitios web, la asignación de direcciones de correo electrónico de administración, las etiquetas de los entornos y los planes de dominios deberían seguir todos un patrón. Si no es así, incluso una red técnicamente sólida se vuelve difícil de auditar y mantener.
Asignación de dominios SSL y puesta en marcha de sitios web en producción
En este punto, la mayoría de las guías de instalación dejan de ser útiles.
Habilitar la red es fácil. Lo que realmente importa es poner en marcha sitios web reales en dominios reales sin redireccionamientos erróneos, problemas con los certificados, confusiones con la caché ni daños en el SEO. Para los equipos de agencias y empresas, el principal reto no es solo habilitar Multisite. Se trata de ponerlo en marcha de forma segura en distintos mercados y dominios, incluyendo el DNS, el SSL, el aislamiento de la caché y la planificación de la migración (Pagely en operaciones de WordPress Multisite).
La asignación de dominios es un proceso de puesta en marcha, no una casilla que hay que marcar
Una vez que la red está en marcha, cada sitio web en producción sigue necesitando sus propias configuraciones de dominio. En la práctica, eso significa que el dominio tiene que apuntar al entorno correcto, que el sitio mapeado tiene que estar asignado correctamente dentro de la red y que el certificado SSL tiene que ser válido antes del lanzamiento.
Parece sencillo hasta que hay varios equipos involucrados. El departamento de marketing se encarga del dominio de la marca. El de TI se encarga del DNS. El proveedor de alojamiento se encarga de los certificados. El equipo de WordPress actualiza la configuración de la web. Si no se siguen estos pasos en el orden correcto, el día del lanzamiento se complica enseguida.
Un orden de lanzamiento repetible
Crea la web en «Network Admin
». Empieza por crear la web con una URL de red temporal. Comprueba el tema, los plugins y la estructura del contenido antes de pasar al dominio definitivo.Prepara el dominio
personalizado. El dominio debe estar listo para apuntar al entorno donde está alojada la red. No programes ventanas de congelación de contenido hasta que quede claro quién es el propietario.Asigna el dominio asignado al sitio
. En la red, conecta el dominio que quieras a la página correcta. Asegúrate bien de que no estás asignando el dominio equivocado a una subpágina con un nombre similar.Configurar el SSL antes del lanzamiento
público. Un dominio asignado sin un HTTPS válido no está listo para el lanzamiento. Hay que comprobar el estado del certificado antes de activar las redirecciones.Comprueba que todo funcione
correctamente incluso fuera del escenario ideal. Revisa la interfaz de usuario, el inicio de sesión de administrador, las URL de los archivos multimedia, el comportamiento canónico, las acciones de los formularios y cualquier referencia codificada que siga apuntando a la URL de red temporal.
Los errores de asignación de dominios casi nunca se deben a WordPress en sí. Se deben a que los equipos cambian la configuración de DNS, SSL y de la aplicación en el orden incorrecto.
Migrar un sitio independiente ya existente a la red
Esta es la parte que a menudo se subestima. Una web independiente ya tiene su propio historial. Cuenta con URL indexables, redireccionamientos, supuestos sobre plugins, recursos codificados de forma estática y un patrón de implementación diseñado para funcionar de forma independiente.
Antes de la migración, decide si vas a integrar el sitio en la red por motivos de gestión o simplemente por comodidad. Si es solo por comodidad, déjalo independiente. Integrar un sitio ya establecido en Multisite conlleva dependencias en cuanto a las URL, los dominios y el funcionamiento que deben justificarse.
Una lista práctica de cosas que hay que hacer para la migración:
- Revisión de contenidos y archivos multimedia: Comprueba que las importaciones mantengan la estructura y las referencias.
- Revisión de plugins: Algunos plugins se comportan de forma diferente en Multisite o requieren una gestión a nivel de red.
- Plan de redireccionamiento: Conservar las rutas antiguas donde sea importante.
- Revisión de «Buscar y reemplazar»: detecta problemas con las URL de entorno, las referencias a archivos multimedia y los datos serializados.
- Definición de «rollback»: Averigua qué significa «abortar y revertir» antes de cambiar el tráfico en producción.
El SSL y el aislamiento de la caché requieren una propiedad explícita
La gestión de los certificados SSL se complica cuando la red aloja muchos dominios con fechas de lanzamiento diferentes. Alguien tiene que encargarse de la emisión de certificados, del seguimiento de las renovaciones y de la validación. Si no se designa a nadie para ello, el jefe de proyecto acaba asumiendo el papel de coordinador de certificados sin quererlo.
El aislamiento de la caché también es importante. La lógica de caché de un sitio web no debería provocar comportamientos inesperados en otro sitio con cookies, reglas de localización o patrones de tráfico de usuarios registrados diferentes. Si el servidor o la capa de caché tratan la red de forma demasiado general, la depuración en un mercado puede afectar a otro.
La lista de comprobación para el lanzamiento que te ahorra tiempo
| Comprueba | Qué hay que comprobar |
|---|---|
| Resolución de dominios | El dominio asignado llega al entorno previsto |
| HTTPS | El certificado es válido y no aparecen problemas de contenido mixto |
| Acceso de administrador | Los editores pueden iniciar sesión a través de la ruta de dominio correcta |
| Redirecciones | Las URL heredadas y las URL canónicas preferidas funcionan como se espera |
| Activos | Los archivos multimedia, los scripts y los formularios se cargan desde el dominio correcto |
Las implementaciones de Multisite más limpias se consiguen cuando la asignación de dominios se trata como un proceso de lanzamiento controlado, y no como una opción que activas al final.
Rendimiento, seguridad y escalabilidad de tu red
Lo complicado de Multisite empieza después de la instalación.
Una red cambia el modelo operativo de WordPress. Los problemas de rendimiento dejan de ser locales. Las decisiones de seguridad dejan de ser específicas de cada sitio web. Cada excepción que permitas para una marca, una región o un cliente supone más trabajo para el equipo responsable del resto de la red.
Los fallos de rendimiento casi nunca se quedan solo ahí
Un plugin que no funciona bien, un patrón de consulta que consume muchos recursos o una importación masiva pueden reducir el rendimiento del panel de administración en varios sitios web. En una web corporativa, eso es solo una molestia. Pero en una red con editores activos, tráfico de campañas y publicaciones programadas, se convierte en un incidente operativo.
Planifica la infraestructura compartida desde el primer día. Eso suele implicar el uso de caché de objetos persistente, reglas de caché de páginas bien definidas, un comportamiento controlado de las tareas cron y la supervisión de las consultas en el entorno de prueba antes de que nada se active en red. También significa ser realista sobre la rentabilidad de los plugins. Un plugin que resulta aceptable en un sitio web independiente puede resultar demasiado costoso cuando se multiplica por docenas de sitios y miles de solicitudes.
Una estrategia de escalabilidad que se mantenga en la fase de producción suele incluir:
- Aprobación centralizada de plugins: Trata cada plugin como una dependencia de la plataforma, con todo lo que eso implica en cuanto a soporte, actualizaciones y reversión.
- Reglas de caché adaptadas al sitio: tienen en cuenta las cookies, los estados de inicio de sesión, las variantes de idioma y el comportamiento específico de cada dominio.
- Control de tareas en segundo plano: pon en cola o limita las importaciones, las tareas de sincronización y la indexación de búsquedas para que una carga de trabajo no acabe agotando los recursos del resto.
- Un tema concreto y un estándar de bloques: al haber menos patrones compatibles, las pruebas, los lanzamientos y la respuesta ante incidencias son más rápidos.
- Disciplina en el mantenimiento de bases de datos: las opciones que se cargan automáticamente, las tablas huérfanas y los registros demasiado grandes acaban convirtiéndose, con el tiempo, en un lastre para toda la red.
La seguridad empieza por el diseño de los permisos
La seguridad de los sitios múltiples suele verse comprometida por una mala gestión antes incluso de que se produzca un ataque avanzado. El acceso de superadministrador es el riesgo más evidente, pero un diseño poco riguroso de los roles genera tantos problemas como ese. Los editores tienen permisos que no deberían tener. Los administradores de los sitios instalan soluciones provisionales que no cumplen con la política. Las agencias ceden una red sin un modelo claro de privilegios y, seis meses después, nadie sabe explicar quién puede hacer qué.
Establece los límites desde el principio. Limita el acceso de superadministrador al pequeño grupo encargado de los cambios en la plataforma. Decide qué temas y plugins están disponibles. Revisa las normas de subida de archivos, el comportamiento del registro, la exposición de la API y cualquier código personalizado que traspase los límites del sitio. El registro de eventos también es importante. Si la red no puede determinar quién ha cambiado una configuración, activado un plugin o creado un sitio, la respuesta ante incidentes se ralentiza rápidamente.
Las herramientas de seguridad también deben adaptarse a la arquitectura. La limitación de tráfico, el análisis de malware, las reglas del WAF y el registro de auditoría deben configurarse teniendo en cuenta la asignación de dominios y la propiedad de múltiples sitios, y no añadirse a posteriori como si se tratara de una instalación sencilla.
Las copias de seguridad solo sirven de algo si la recuperación se adapta al modelo de red
Muchos equipos dicen que tienen copias de seguridad, cuando en realidad lo único que tienen es una casilla marcada del proveedor y ninguna ruta de restauración probada.
Las configuraciones multisitio obligan a plantearse cuestiones más complejas. ¿Se puede restaurar un sitio sin que afecte a los demás? ¿Se pueden recuperar los archivos multimedia, las tablas y la configuración de los dominios asignados de una sola propiedad tras una implementación fallida? ¿Cuánto tiempo tarda una restauración completa de la red y quién la aprueba cuando varias unidades de negocio comparten la misma infraestructura?
Los equipos que se encargan de gestionar sitios de WordPress en varios entornos suelen darse cuenta de que la recuperación del diseño es más importante que la copia de seguridad de la imagen de marca. Anota los procedimientos de recuperación. Pruébalos. Ten en cuenta que la solución debe ser diferente si se trata de un error de contenido en un solo sitio o de un fallo que afecta a toda la red.
La escalabilidad tiene que ver tanto con la moderación como con la infraestructura
Las redes sanas no crecen diciendo que sí a todas las excepciones. Crecen controlando la variación.
Utiliza un proceso de lanzamiento que compruebe los componentes compartidos antes de la implementación. Revisa los sitios inactivos y archiva aquellos que ya no cumplan una función empresarial. Haz un seguimiento de las personalizaciones que generan costes de soporte a largo plazo. Si un sitio necesita plugins poco habituales, un comportamiento de alojamiento especial o flujos de trabajo editoriales atípicos, replantéate si realmente tiene sentido que forme parte de la red.
Los entornos multisitio más sólidos tienen en común algunas características:
- Control estricto de los cambios en la configuración a nivel de red
- Una pequeña selección de plugins de confianza
- Titularidad documentada de dominios, SSL, almacenamiento en caché y DNS
- Procedimientos claros de incorporación y salida para los centros
- Auditorías periódicas para detectar propiedades inactivas, código obsoleto y la ampliación progresiva de privilegios
Multisite puede servir de base para una plataforma empresarial o de agencia de gran envergadura. Pero también puede concentrar el riesgo en un único código fuente, un único nivel de base de datos y un único modelo de gobernanza. Los equipos que lo utilizan con éxito tratan la red como si fuera un producto, con normas, responsables y disciplina operativa.
Si estás valorando si Multisite es la arquitectura adecuada o necesitas ayuda para convertir una red ya instalada en una plataforma operativa estable, IMADO te ofrece soporte para proyectos de WordPress que requieran conocimientos técnicos avanzados en materia de Multisite, implementación multilingüe, gestión, planificación de migraciones y mantenimiento continuo.
