Por qué Multisite en lugar de N instancias WordPress separadas
Una agencia que gestiona quince sitios WordPress en quince instalaciones distintas se enfrenta a un problema de escala: quince paneles de control que supervisar, quince ciclos de actualización que coordinar, quince configuraciones de servidor web que mantener. Si un plugin crítico publica un parche de seguridad, hay que aplicarlo quince veces — una por una, manualmente o mediante herramientas de orquestación externas.
WordPress Multisite resuelve este problema de raíz. Una sola instalación WordPress ejecuta una red de sitios (network). Cada cliente tiene su propio subdominio (client1.example.com, client2.example.com), su propio contenido, sus propios usuarios y su propia configuración de tema. Pero los archivos del núcleo de WordPress, los plugins y los temas se comparten y gestionan centralmente por el superadministrador de la red.
En un VPS dedicado, este modelo tiene pleno sentido: el aislamiento de red contiene la superficie de ataque y mantienes el control completo sobre PHP, MariaDB y Nginx sin pasar por un panel de control de terceros.
Lo que ganas en la práctica
- Una sola actualización del núcleo de WordPress, plugins y temas de red — aplicada simultáneamente a todos los sitios de la cartera.
- Un solo punto de entrada de administración: el superadministrador de red supervisa todos los sitios desde
/wp-admin/network/. - Almacenamiento compartido de medios opcional por sitio — agrupa recursos o aisla según tus contratos con clientes.
- Ahorro de recursos del servidor: un solo proceso PHP-FPM, una sola instancia de caché de objetos, una sola conexión MariaDB que ajustar.
- Incorporación más rápida: crear un subsitio consiste en rellenar un formulario en la red, no en aprovisionar un servidor.
- Copias de seguridad centralizadas: un solo volcado MariaDB cubre todos los sitios, programable con una sola regla cron.
Requisitos previos: recursos VPS recomendados para 5 a 15 sitios activos
Los recursos necesarios dependen del tráfico y la complejidad de los sitios — no del número de instalaciones. Para una red de 5 a 15 sitios WordPress activos (sitios escaparate o blogs con tráfico moderado, sin WooCommerce intensivo), la recomendación editorial basada en la documentación de WordPress y Nginx/MariaDB es:
- CPU: 2 vCPU como mínimo; 4 vCPU en cuanto combinas caché de páginas con tráfico simultáneo.
- RAM: 4 GB como base; 8 GB recomendados si activas una caché de objetos Redis junto con PHP-FPM.
- Almacenamiento: SSD NVMe, 40 GB mínimo para archivos WordPress + medios + logs de MariaDB; ajustar según el volumen de medios de los clientes.
- PHP: PHP 8.2 o 8.3 (PHP 8.1 llegó al final de soporte activo a finales de 2024).
- MariaDB: 10.6 LTS o 10.11 LTS.
- Servidor web: Nginx con bloques server por subdominio y DNS comodín.
Si tu cartera supera los 15 sitios o incluye tiendas WooCommerce, considera dividir la red Multisite en dos particiones o empezar con 8 GB / 4 vCPU.
Activar WordPress Multisite y configurar Nginx para subdominios
Configurar el DNS comodín
Antes de hacer ningún cambio en WordPress, añade un registro DNS comodín en tu dominio principal:
*.example.com A <IP_DE_TU_VPS>Esta entrada dirige todos los subdominios a tu VPS. Sin ella, los subsitios de la red permanecerán inaccesibles desde el navegador, aunque WordPress los cree correctamente.
Permitir el modo red en wp-config.php
Edita
wp-config.phpen la raíz de tu instalación WordPress y añade la siguiente línea antes de/* That's all, stop editing! */:define( 'WP_ALLOW_MULTISITE', true );Esta constante es la condición documentada en la documentación oficial de WordPress para activar el asistente de instalación de red.
Crear la red desde el panel de administración
Inicia sesión en
/wp-admin/, ve a Herramientas → Instalación de la red. Elige Subdominios (DNS comodín obligatorio). Introduce el título de la red y el correo electrónico del administrador, luego haz clic en Instalar.WordPress te proporcionará dos bloques de código para insertar en
wp-config.phpy en.htaccess(Apache) o en tu archivo de configuración Nginx. Cópialos exactamente.Adaptar la configuración de Nginx para subdominios comodín
En Nginx, el bloque
.htaccessproporcionado por WordPress no se lee. Reemplázalo con un bloqueserverdedicado. Esta es la configuración mínima para una red de subdominios:server { listen 80; server_name example.com *.example.com; root /var/www/wordpress; index index.php; # Multisite subdomain rewrite if (!-e $request_filename) { rewrite /wp-admin$ $scheme://$host/wp-admin/ permanent; rewrite ^(/[^/]+)?(/wp-.*) $2 last; rewrite ^(/[^/]+)?(/.*\.php) $2 last; } location / { try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { fastcgi_pass unix:/run/php/php8.3-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }Recarga Nginx:
systemctl reload nginx. Luego pasa a HTTPS generando un certificado comodín con Certbot usando el desafío DNS-01 — un certificado SAN*.example.comcubre todos los subsitios de la red.Finalizar la configuración de WordPress Multisite en wp-config.php
Añade las constantes proporcionadas por el asistente a
wp-config.php(adapta los valores a tu instalación):define( 'MULTISITE', true ); define( 'SUBDOMAIN_INSTALL', true ); define( 'DOMAIN_CURRENT_SITE', 'example.com' ); define( 'PATH_CURRENT_SITE', '/' ); define( 'SITE_ID_CURRENT_SITE', 1 ); define( 'BLOG_ID_CURRENT_SITE', 1 );Cierra sesión y vuelve a iniciarla. El panel de control muestra ahora el menú Red en la barra de administración. Desde Red → Sitios → Añadir nuevo, crea tu primer subsitio de cliente:
client1.example.com.Activar plugins de red y asignar temas
En Red → Plugins, activa los plugins para toda la red (Activar en la red) o deja que los administradores de los subsitios los activen por su cuenta. Los temas funcionan igual: el superadministrador los pone a disposición y cada subsitio elige el suyo.
Nota importante: algunos plugins no son compatibles con el modo red. Verifica la compatibilidad en la documentación del plugin antes de activarlo en la red — un plugin incompatible puede bloquear el panel de control de todos los subsitios simultáneamente.
Multisite vs instancias WordPress separadas: tabla comparativa
Desplace la tabla
| Criterio | WordPress Multisite | Instancias separadas |
|---|---|---|
| Actualización del núcleo WordPress | 1 operación para N sitios | N operaciones manuales |
| Actualización de un plugin | 1 operación de red | N operaciones, riesgo de desincronización |
| Aislamiento de datos del cliente | Parcial (misma base MariaDB, prefijos distintos) | Total (bases de datos distintas, procesos PHP distintos) |
| Almacenamiento de medios | Compartido por defecto, aislable con plugin | Aislado de forma nativa |
| Recursos del servidor | Compartidos — ahorro de RAM y CPU | Aditivos — cada instancia consume su parte |
| Plugin incompatible con la red | Potencialmente bloquea todos los sitios | Afecta solo a una instancia |
| Incorporar un nuevo sitio | Formulario en la red — segundos | Aprovisionamiento completo — minutos a horas |
| Certificado SSL comodín | 1 certificado `*.example.com` | 1 certificado por dominio de cliente |
Seguridad de Multisite en VPS: contener el impacto de una vulnerabilidad
La objeción más común sobre WordPress Multisite es válida: si un plugin vulnerable es comprometido, la superficie de ataque potencial cubre toda la red, no solo un sitio. En un VPS dedicado, varias medidas contienen este impacto:
Copias de seguridad diarias automatizadas. Un volcado MariaDB programado cada noche (cron + mysqldump o mariabackup) te da un punto de restauración reciente para cada subsitio. Almacena los volcados fuera del VPS — en un bucket compatible con S3 o en un volumen remoto.
Firewall de aplicaciones. Un WAF Nginx (ModSecurity o reglas OWASP) filtra las solicitudes maliciosas antes de que lleguen a PHP. Combínalo con fail2ban para bloquear las IPs que intenten fuerza bruta en /wp-login.php.
Actualizaciones sin demora. La fortaleza de Multisite — una actualización para toda la cartera — es también tu mejor defensa: aplica los parches de seguridad de WordPress y los plugins el día de su publicación. Sin Multisite, el retraso en actualizar una instancia olvidada es la vulnerabilidad más explotada.
Superadmin con acceso limitado. La cuenta de superadministrador de la red tiene derechos sobre todos los sitios. Usa autenticación de dos factores en esta cuenta y crea cuentas de administrador de subsitio separadas para cada cliente.
Solución de problemas: tres errores frecuentes en una red WordPress Multisite
1. Plugin reportado como «incompatible con el modo red».
Algunos plugins comprueban explícitamente si WordPress está funcionando en modo Multisite y se niegan a activarse en la red. La causa suele ser el uso de $wpdb->blogid u opciones almacenadas de forma incompatible con las tablas prefijadas de cada subsitio. Solución: revisa los issues de GitHub del plugin, busca una alternativa compatible, o activa el plugin solo en los subsitios que lo necesiten (si el plugin lo permite) en lugar de a nivel de red.
2. Página de administración de red inaccesible (/wp-admin/network/ redirige al panel de control estándar).
El superadmin no es el mismo usuario que el administrador del sitio principal. Al crear la red, WordPress añade un indicador super_admin al usuario activo. Si creaste la red con una cuenta y luego inicias sesión con otra, esa segunda cuenta no verá el menú de red. Comprueba en MariaDB:
SELECT meta_value FROM wp_usermeta
WHERE meta_key = 'wp_user_level'
AND user_id = <ID_DE_TU_CUENTA>;Para elevar a un usuario a superadmin: usa la función grant_super_admin( $user_id ) desde un archivo en mu-plugins.
3. Subdominios inaccesibles: el DNS comodín no se propaga inmediatamente.
Después de añadir *.example.com A <IP>, el TTL del registro determina el tiempo de propagación. Durante este período, los sitios creados en la red devuelven un error DNS en el navegador — WordPress los ha creado correctamente, pero el resolvedor todavía no conoce el subdominio. Si trabajas localmente con un VPS de desarrollo, añade una entrada en /etc/hosts en tu equipo para cada subdominio que quieras probar: <IP_VPS> client1.example.com.
Un cuarto caso se produce con configuraciones mixtas www / sin www: si tanto example.com como www.example.com apuntan al VPS, asegúrate de que DOMAIN_CURRENT_SITE en wp-config.php coincida exactamente con el dominio principal sin el prefijo www, y que Nginx redirija la forma www a la forma canónica antes de pasar la solicitud a WordPress.
Migrar sitios existentes a una red Multisite
Si ya gestionas sitios WordPress separados y quieres consolidarlos en una red Multisite, el plugin WordPress Importer (plugin oficial) exporta contenidos, comentarios y usuarios desde cada instancia origen, y luego los importa en un subsitio de la red.
Tres puntos a vigilar antes de migrar:
- Los uploads no se migran automáticamente. Copia la carpeta wp-content/uploads/ de cada sitio origen a wp-content/uploads/sites/<ID>/ en la red (el ID lo asigna WordPress al crear el subsitio).
- Comprueba la compatibilidad de plugins de red antes del cambio: un plugin activo en el sitio antiguo puede no funcionar en modo red. Haz una lista de los plugins de cada sitio origen y crúzala con la lista de plugins de red disponibles.
- Prueba las redirecciones de dominio. Si el sitio migrado tenía su propio dominio (www.client1.com), configura el módulo WordPress MU Domain Mapping o la funcionalidad nativa de dominio personalizado para que client1.example.com redirija a www.client1.com — o viceversa según tu elección.
Puesta en producción: pasos de validación antes de abrir a tus clientes
Antes de migrar tus primeros sitios de clientes a la red, revisa estos puntos:
- Prueba la creación de un subsitio desde client1.example.com y verifica que sea accesible desde un navegador externo.
- Verifica que el certificado comodín cubre *.example.com: openssl s_client -connect client1.example.com:443 -servername client1.example.com | grep subject.
- Simula una actualización de plugin de red y comprueba que todos los subsitios siguen funcionando.
- Planifica y prueba la restauración de un subsitio a partir de un volcado MariaDB: la restauración no probada no es una copia de seguridad.
- Documenta el procedimiento de incorporación para tus clientes: URL de administración, credenciales, permisos concedidos a su cuenta de administrador de subsitio.
Un VPS ServOrbit dimensionado para tu cartera WordPress te da el control sobre toda la pila — PHP, MariaDB, Nginx, copias de seguridad — sin capa de abstracción que oculte los errores.
