Escalando WordPress Multisite en 2026 - Gestionando más de 100 sitios web

Gestionar un puñado de sitios web es fácil. Gestionar más de 100 sitios web para un grupo internacional o una red de franquicias es un problema logístico, a menos que utilices la arquitectura adecuada. En 2026, WordPress Multisite sigue siendo la forma integrada en WordPress de gestionar una gran flota de sitios desde una sola instalación.

A continuación, te explicamos cómo diseñar, gobernar y escalar una red de 100 sitios.

Respuesta corta: WordPress Multisite sigue funcionando muy bien en 2026 cuando necesitas control centralizado, código compartido y una gobernanza coherente en muchos sitios. Se convierte en la opción equivocada cuando necesitas un aislamiento estricto de los datos, una infraestructura radicalmente distinta para cada sitio o autonomía total para cada equipo.

Conoce más sobre el desarrollo WordPress profesional en WPPoland.

#Actualizar 100 sitios WordPress desde un solo código base

La principal ventaja de Multisite es tener un único código base del núcleo que gestionar. Todo lo demás en esta guía se apoya en ello.

#Actualizaciones centralizadas

Cuando se publica un parche de seguridad, lo actualizas una vez a nivel de red y el nuevo código queda activo en los 100 sitios en el mismo momento. Con 100 instalaciones separadas, el mismo parche supone 100 actualizaciones, y cada sitio que espera su turno queda expuesto durante más tiempo.

A esta escala importa un detalle: una actualización del núcleo también puede cambiar el esquema de la base de datos. El código es compartido, pero cada sitio tiene sus propias tablas, así que después de una actualización del núcleo WordPress te pide ejecutar Actualizar la red. El manual del Administrador de la red lo describe así: la función Actualizar la red «recorrerá cada sitio, de cinco en cinco, y se asegurará de que se apliquen todos los cambios en la base de datos» (traducción propia). Los sitios desactivados se omiten y reciben su actualización cuando un administrador de ese sitio inicia sesión después de reactivarlo.

#Biblioteca compartida

Los temas y los plugins son compartidos. Si quieres actualizar los colores corporativos de la marca, modificas un solo tema y el cambio se refleja en todos los sitios regionales que lo usan.

Gestión de los recursos compartidos:

• Tema corporativo: un tema padre, con las variaciones de cada marca como temas hijo
• Plugins principales: SEO, seguridad, caché y analítica, instalados una sola vez por el Super Admin
• Plugins de uso obligatorio: los archivos de mu-plugins se cargan en todos los sitios y no se pueden desactivar sitio por sitio

#Coherencia de marca y su límite

Las fuentes, los colores y los espaciados definidos en el theme.json del tema se aplican a todos los sitios que usan ese tema. El límite está en la base de datos: según el manual de administración de la red, «los cambios de estilo realizados en el Editor del sitio afectan solo a sitios individuales» (traducción propia), porque se guardan en las tablas de ese sitio. Si la coherencia de marca es importante, mantén el sistema de diseño en los archivos del tema bajo control de versiones y restringe quién puede editar estilos en el Editor del sitio.

#Cómo crear una red WordPress Multisite

El procedimiento oficial es breve, y la guía Create a Network fija el orden:

1. Haz una copia de seguridad de la base de datos y de los archivos, comprueba que los enlaces permanentes amigables funcionan y desactiva todos los plugins activos.
2. Si WordPress se ejecuta desde su propio directorio, configúralo antes de activar Multisite.
3. Añade define( 'WP_ALLOW_MULTISITE', true ); a wp-config.php por encima de la línea que indica el fin de la edición. Así se habilita Herramientas > Configuración de la red.
4. En la pantalla Configuración de la red, elige subdominios o subdirectorios e instala.
5. Añade las líneas que genera WordPress a wp-config.php y .htaccess, y vuelve a iniciar sesión.

El manual de administración de la red añade un punto que ahorra tiempo en los entornos actuales: WordPress puede generar las reglas de reescritura de Apache e IIS, «pero no puede generar la configuración de Nginx» (traducción propia). En Nginx, escribes las reglas de Multisite a partir de los ejemplos documentados.

Desde la línea de comandos, WP-CLI hace la misma conversión con wp core multisite-convert, que crea las tablas de Multisite y añade las constantes a wp-config.php. Añade --subdomains para una red basada en dominios.

#Multisite con subdominios o con subdirectorios

La elección decide cómo se ven las URL de los sitios y qué debe admitir el servidor. La guía de preparación de la red enumera las reglas:

No se puede crear una red cuando la dirección de WordPress usa un puerto distinto de 80 o 443. Cambiar de tipo más adelante es posible, pero costoso: modificar SUBDOMAIN_INSTALL y las reglas de reescritura «no migra las direcciones de los sitios existentes ni configura DNS, hosts virtuales, certificados TLS, redirecciones y cookies», según el manual de administración de la red (traducción propia). Para un plan de 100 sitios, decide una sola vez y prueba en staging.

#WordPress con varias redes y sharding de la base de datos

Para las organizaciones que se han quedado pequeñas con una sola red, las configuraciones multirred agrupan los sitios en varias redes dentro de una misma instalación. El núcleo admite el modelo de datos, pero la interfaz de gestión la aportan plugins como WP Multi Network.

#Agrupación regional

Puedes tener una red para Europa, otra para las Américas y otra para APAC, todas dentro de una sola instalación. Cada red tiene sus propios ajustes y su propia lista de plugins activados para la red.

En WP-CLI cada red tiene un ID numérico. wp site create --network_id=2 añade un sitio a la segunda red, y wp site list --network=2 muestra solo sus sitios.

#Sharding con un drop-in db.php

Para evitar que la base de datos se convierta en un cuello de botella, un drop-in db.php como HyperDB reparte las tablas de los sitios entre varios servidores de base de datos y envía las lecturas a réplicas.

Estrategias de sharding:

• Por región: cada red regional tiene su propio servidor de base de datos
• Por volumen: los sitios con mucho tráfico reciben servidores dedicados
• Híbrida: una combinación de ambas, basada en la carga medida

#Qué se comparte y qué es propio de cada sitio

El manual de administración de la red añade que activar un plugin para la red «no cambia el lugar donde el plugin guarda sus datos» (traducción propia). Que los ajustes sean de toda la red o de cada sitio depende de cómo esté escrito cada plugin, así que compruébalo antes de aprobar un plugin para la red.

#SSO y roles de usuario en WordPress Multisite

Con 100 sitios, es probable que tengas cientos de usuarios. No puedes gestionarlos a mano.

#Integración de SSO

Integra tu Multisite con un proveedor de identidad como Okta o Microsoft Entra ID (antes Azure AD). Cuando un empleado deja la empresa, su acceso a los 100 sitios web se revoca en un solo lugar. Así se cierra el hueco de las cuentas huérfanas, una vía de entrada habitual a los sitios antiguos.

#Controles del Super Admin

Define qué sitios pueden activar qué plugins. Un equipo regional de marketing no debería poder instalar un plugin arriesgado que pueda romper toda la red. WordPress aplica parte de esto por defecto: en una red, los administradores de sitio «no pueden instalar temas ni plugins nuevos y no pueden editar los perfiles de los usuarios de su sitio», según el manual de administración de la red (traducción propia). Solo puede hacerlo el Super Admin.

Jerarquía de roles recomendada:

Los roles personalizados, como un responsable de SEO con acceso solo a los metacampos, son posibles con un plugin de roles o con código, y se definen sitio por sitio.

#Acceso a plugins para los administradores de sitio

Por defecto, los administradores de sitio no ven la pantalla Plugins. La pantalla Ajustes de la red tiene la opción Ajustes del menú, que la habilita. Aun así, los administradores de sitio solo pueden activar o desactivar los plugins que ha instalado el Super Admin; los plugins activados para la red aparecen como «Activo para la red», sin opción de desactivarlos.

Un plugin también puede declarar Network: true en su cabecera, lo que lo hace exclusivo de la red.

#Temas por sitio

Habilitar un tema para la red no cambia ningún sitio a ese tema. Solo lo pone a disposición. Un tema también se puede habilitar para un único sitio desde la pantalla Editar el sitio, pestaña Temas. Los sitios nuevos reciben el tema por defecto más reciente, salvo que definas WP_DEFAULT_THEME en wp-config.php con el nombre de la carpeta de tu tema corporativo, lo que ahorra un paso manual en cada sitio nuevo.

#Cómo sindicar contenido en una red WordPress Multisite

Los sitios de una red no comparten contenido por defecto. El manual de administración de la red compara una red con «una versión en miniatura de WordPress.com» (traducción propia) y remite a plugins para compartir contenido. Planifica la sindicación como una función que se añade, no como una que viene incluida.

#Publicar un comunicado en todos los sitios

Los plugins de difusión permiten publicar un comunicado corporativo global una sola vez y copiarlo en los 100 sitios. Los casos típicos son notas de prensa, novedades de producto, avisos de seguridad y de cumplimiento normativo y campañas de temporada.

#Búsqueda global

Usa Elasticsearch (mediante ElasticPress) para ofrecer una barra de búsqueda capaz de encontrar contenido en todos los sitios de la red. La búsqueda nativa de WordPress consulta las tablas de un solo sitio.

#Leer contenido de otros sitios

Cada sitio expone su propia API REST, así que un sitio central puede obtener entradas de los sitios regionales por HTTP. Dentro de PHP, switch_to_blog() y restore_current_blog() permiten que el código lea directamente las tablas de otro sitio, y así funcionan la mayoría de los plugins de sindicación.

#Lista de rendimiento de WordPress Multisite para más de 100 sitios

#Redis para Multisite

• Claves por sitio: la caché de objetos indexa los datos por ID de sitio, así que los sitios no sobrescriben la caché de los demás
• Grupos globales: los usuarios y las opciones de red se guardan en caché una sola vez para toda la red
• Alertas de memoria: un sitio grande puede llenar la caché compartida

#Límites de subida por sitio

Los Ajustes de la red también controlan el almacenamiento. Por defecto, el espacio de subida de cada sitio está limitado a 50 MB y el tamaño máximo de archivo a 1500 KB, y ambos se pueden editar. Los tipos de archivo permitidos son una lista de la red; añadir un tipo ahí «NO funcionará» si no se permite también mediante el filtro upload_mimes, según la pantalla Ajustes de la red (traducción propia). Con 100 sitios, fija estos límites a propósito en lugar de ampliarlos cada vez que alguien se queje.

#Automatizar WordPress Multisite con WP-CLI y CI/CD

#Despliegues automatizados

En una red de más de 100 sitios, los despliegues manuales no escalan:

• Pipeline CI/CD: cada cambio de código pasa pruebas automatizadas en staging
• Despliegue gradual: si gestionas varias redes o instalaciones, publica primero en el grupo más pequeño
• Reversión: ten lista la versión anterior para restaurarla

#WP-CLI a escala

WP-CLI es la herramienta principal para gestionar una red desde la línea de comandos. Los comandos siguientes proceden de la referencia oficial de comandos de WP-CLI:

# Actualizar el núcleo una vez y después la base de datos en cada sitio
wp core update
wp core update-db --network

# Activar un plugin para toda la red
wp plugin activate my-plugin --network

# Activar un plugin solo en cada sitio de la red 2
wp site list --network=2 --field=url | xargs -I {} wp plugin activate my-plugin --url={}

# Contar las entradas publicadas de cada sitio
wp site list --field=url | while read url; do
  echo "$url $(wp post list --post_type=post --post_status=publish --format=count --url="$url")"
done

#Comandos para el ciclo de vida de los sitios

Archivar y desactivar son reversibles, y en la práctica el Administrador de la red trata el archivado igual que la desactivación. Marcar como spam deja el sitio inaccesible para todos. Eliminar borra el sitio, así que en tus scripts usa --keep-tables hasta tener una copia de seguridad verificada.

#Monitorización y alertas por sitio

Cada sitio de la red necesita sus propias alertas:

• Disponibilidad de cada sitio (el sitio principal puede estar activo mientras un subsitio está caído)
• Core Web Vitals de cada sitio
• Errores de PHP de cada sitio (un plugin activado en un sitio puede provocar errores solo en ese sitio)
• Crecimiento de la base de datos de cada sitio

#Cómo asignar un dominio propio a un sitio de multisite

El mapeo de dominios es nativo desde WordPress 4.5, según la guía de mapeo de dominios. Los pasos:

1. Apunta el DNS del dominio al servidor y apárcalo sobre el dominio principal de la red.
2. Instala un certificado TLS para cada dominio; la guía recomienda SNI para los dominios adicionales.
3. En el Administrador de la red, abre Sitios, edita el sitio y configura la Dirección del sitio (URL) con el dominio completo, por ejemplo https://example.com.
4. Si el inicio de sesión falla con un error de cookies, añade define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); a wp-config.php.

Con 100 marcas en 100 dominios, la renovación de certificados se convierte en la tarea recurrente, así que automatízala en el servidor.

#Cuándo no usar multisite

Multisite no siempre es la respuesta. El propio manual lo advierte: si planeas sitios que «compartan datos o compartan usuarios» de forma muy estrecha, «una red multisitio podría no ser la mejor solución», según la guía de preparación de la red (traducción propia). Evítalo si:

1. Requisitos únicos: el sitio A necesita una configuración de servidor completamente distinta o una versión de PHP diferente a la del sitio B.
2. Reputación de la IP: si un sitio de la red envía spam, puede afectar a la reputación de todos los demás sitios en esa misma IP. Esto importa sobre todo para los sitios que dependen de la entregabilidad del correo electrónico.
3. Aislamiento de datos: un cliente exige, por motivos legales, que sus datos estén en una base de datos completamente separada.
4. Autonomía de los equipos: cada equipo necesita elegir e instalar sus propios plugins.
5. Un sitio dominante: un sitio concentra la mayor parte del tráfico y necesita su propia infraestructura.

#Alternativas a Multisite

#Cómo migrar a WordPress Multisite paso a paso

#Fase 1: auditoría

• Inventario de todos los sitios existentes
• Análisis de los plugins y temas en uso, y de si cada uno funciona en Multisite
• Requisitos de datos y de aislamiento
• Integraciones de cada sitio

#Fase 2: arquitectura

• Estructura de la red (una red o varias)
• Subdominio o subdirectorio, decidido una sola vez
• Estrategia de base de datos
• Roles y permisos

#Fase 3: implementación

• Entorno Multisite en staging
• Migración del contenido sitio por sitio
• SSO y gobernanza
• Caché y CDN

#Fase 4: optimización

• Pruebas de carga
• Ajuste de la caché y de la base de datos
• Formación para los administradores de la red
• Procedimientos escritos para las actualizaciones y los sitios nuevos

El manual de administración de la red advierte que mover un Multisite «es más complicado que mover una instalación individual» (traducción propia), así que prueba la ruta de migración en staging antes del cambio en producción.

#Conclusión

WordPress Multisite es una herramienta sólida para cualquiera que gestione una flota de sitios. Ofrece la eficiencia de la gestión centralizada con la flexibilidad de la creación de contenido descentralizada.

Si buscas escalar de 10 sitios a 100 o 1.000, diseñar tu Multisite correctamente desde el primer día es la decisión técnica más importante que tomarás.

Si necesitas escalar tu red de sitios WordPress, contacta con WPPoland para diseñar tu arquitectura Multisite empresarial.

#Recursos relacionados

• Desarrollo WordPress profesional
• Optimización de velocidad WordPress
• Auditoría de seguridad WordPress
• Mantenimiento WordPress
• Desarrollo WooCommerce
• Contactar con WPPoland