Descubre cómo funciona el multisite WordPress, sus casos de uso reales, limitaciones técnicas y criterios para decidir si te conviene activarlo.
Tabla de contenidos
- Qué es WordPress Multisite y por qué existe
- Arquitectura técnica: cómo se estructura una red multisite
- Roles de usuario en multisite: el Super Admin
- Plugins y temas: cómo se gestionan en una red
- Comparativa: multisite vs. instalaciones independientes
- Casos de uso donde multisite tiene sentido real
- Cuándo NO usar multisite: señales claras
- Multisite vs. soluciones multiidioma: una confusión frecuente
- Implicaciones de hosting y rendimiento
- Checklist: criterios para decidir si multisite es viable
- Preguntas frecuentes sobre WordPress Multisite
Qué es WordPress Multisite y por qué existe
Antes de entender cómo funciona el multisite WordPress, conviene saber qué problema resuelve. WordPress Multisite es una funcionalidad nativa del core de WordPress —no es un plugin ni un add-on— que permite gestionar múltiples sitios web desde una única instalación. Comparten el mismo conjunto de archivos del core, la misma base de datos (con tablas separadas por sitio) y el mismo panel de administración de red.
Esta funcionalidad existe desde WordPress 3.0, lanzado en 2010, cuando se fusionó el proyecto WordPress MU (Multi-User) con el core principal. La idea era dar respuesta a organizaciones que necesitaban operar decenas o cientos de sitios sin mantener instalaciones independientes para cada uno. Universidades, redes de franquicias, grupos editoriales y empresas con presencia en múltiples países fueron los primeros en adoptarlo.
WordPress.com, la plataforma de Automattic, funciona internamente como una red multisite masiva que aloja millones de blogs. Eso da una idea de la escala que puede alcanzar esta arquitectura cuando se configura correctamente.
Arquitectura técnica: cómo se estructura una red multisite
La clave para entender cómo funciona una red multisite en WordPress está en su arquitectura de base de datos y archivos. A nivel de sistema de archivos, existe una única carpeta wp-content, un único wp-config.php y un único conjunto de archivos del core. Todos los sitios de la red comparten esos recursos.
Base de datos: tablas compartidas y tablas por sitio
Cuando activas multisite, WordPress crea un conjunto de tablas globales y luego genera tablas específicas para cada subsitio. Las tablas globales incluyen wp_users, wp_usermeta, wp_blogs, wp_site, wp_sitemeta y wp_signups. Estas tablas son comunes a toda la red.
Para cada subsitio nuevo, WordPress genera un prefijo numérico. El sitio principal usa wp_posts, wp_options, wp_postmeta, etc. El segundo sitio usa wp_2_posts, wp_2_options, wp_2_postmeta. El tercer sitio, wp_3_posts, y así sucesivamente. En una red con 50 sitios, la base de datos puede contener fácilmente más de 600 tablas.
Este diseño tiene implicaciones directas en rendimiento. Las consultas entre sitios no son triviales, y las migraciones individuales de subsitios requieren herramientas específicas como WP-CLI o plugins diseñados para multisite.
Subdominios vs. subdirectorios
Al configurar la red, WordPress te obliga a elegir entre dos estructuras de URL:
- Subdirectorios:
ejemplo.com/sitio-a/,ejemplo.com/sitio-b/ - Subdominios:
sitio-a.ejemplo.com,sitio-b.ejemplo.com
Esta decisión es permanente una vez activada la red. No se puede cambiar después sin reconstruir toda la configuración. Los subdirectorios funcionan mejor para proyectos donde los sitios son secciones temáticas de una marca. Los subdominios encajan cuando cada sitio necesita identidad propia o cuando se va a usar mapeo de dominios independientes (sitio-a.com, sitio-b.com).
Si la instalación de WordPress ya tiene más de un mes de vida, WordPress solo permite subdominios. Esta restricción técnica existe para evitar conflictos con permalinks ya indexados.
Roles de usuario en multisite: el Super Admin
En una instalación estándar de WordPress, el rol más alto es «Administrador». En una red multisite aparece un nuevo rol por encima: el Super Admin (o administrador de red). Este rol es el único que puede:
- Crear y eliminar subsitios
- Instalar y activar temas y plugins a nivel de red
- Gestionar usuarios en toda la red
- Configurar ajustes globales de la red
- Actualizar el core de WordPress
Los administradores de cada subsitio tienen un rol más limitado que el administrador de una instalación normal. Por ejemplo, no pueden instalar plugins ni temas por su cuenta; solo pueden activar los que el Super Admin ha puesto a disposición de la red. Tampoco pueden editar archivos de temas o plugins, ni acceder al editor de código desde el panel.
Esta jerarquía es una ventaja para organizaciones que necesitan dar autonomía parcial a equipos internos sin comprometer la estabilidad de toda la red. Pero también genera fricción cuando los administradores de subsitios necesitan funcionalidades que requieren un plugin específico y deben esperar a que el Super Admin lo autorice.
Plugins y temas: cómo se gestionan en una red
Uno de los aspectos más importantes para entender el funcionamiento del multisite en WordPress es la gestión centralizada de plugins y temas. Todos los plugins se instalan una sola vez y se almacenan en la carpeta wp-content/plugins/ compartida. El Super Admin puede activarlos de dos formas:
- Activación a nivel de red: el plugin queda activo en todos los subsitios automáticamente. Ningún administrador de subsitio puede desactivarlo.
- Disponibilidad individual: el plugin queda disponible para que cada administrador de subsitio lo active o desactive según necesite.
Con los temas ocurre algo similar. Se instalan una vez, y el Super Admin decide cuáles están disponibles para la red. Cada subsitio puede usar un tema diferente de los autorizados.
La trampa de la compatibilidad
No todos los plugins de WordPress son compatibles con multisite. Algunos guardan opciones en wp_options asumiendo que es la única tabla de opciones, sin considerar que en multisite cada subsitio tiene su propia tabla wp_N_options. Otros plugins no distinguen entre el contexto de red y el contexto de subsitio, lo que genera comportamientos inesperados.
Antes de activar cualquier plugin a nivel de red, es necesario verificar explícitamente que sea «multisite compatible» o «network activated compatible». Plugins de caché, SEO y seguridad son los que más problemas suelen dar en redes multisite, porque muchos de ellos escriben reglas en .htaccess o en wp-config.php asumiendo una instalación estándar.
Comparativa: multisite vs. instalaciones independientes
Esta es probablemente la decisión más relevante que hay que tomar. La siguiente tabla compara ambos enfoques en los criterios que más importan en un contexto profesional:
| Criterio | WordPress Multisite | Instalaciones independientes |
|---|---|---|
| Actualizaciones del core | Una sola actualización para toda la red | Una actualización por cada instalación |
| Gestión de plugins | Centralizada (el Super Admin controla) | Cada sitio elige sus propios plugins |
| Aislamiento de errores | Un fallo en un plugin afecta a toda la red | Cada sitio es independiente |
| Flexibilidad por sitio | Limitada (mismo core, mismos plugins disponibles) | Total (cada sitio es autónomo) |
| Rendimiento | Base de datos compartida, posible cuello de botella | Recursos dedicados por instalación |
| Migración individual | Compleja (requiere herramientas específicas) | Sencilla (exportar e importar) |
| Coste de mantenimiento | Menor (una sola instalación que mantener) | Mayor (multiplicado por número de sitios) |
| Hosting | Requiere configuración específica | Cualquier hosting estándar |
La conclusión que se extrae de esta comparativa es que multisite reduce coste operativo a cambio de flexibilidad y aislamiento. Funciona bien cuando los sitios son similares entre sí y comparten necesidades técnicas. Funciona mal cuando cada sitio necesita plugins diferentes, versiones de PHP distintas o tiene requisitos de rendimiento muy dispares.
Casos de uso donde multisite tiene sentido real
Entender el funcionamiento técnico del multisite de WordPress es solo la mitad de la ecuación. La otra mitad es saber cuándo usarlo y cuándo evitarlo.
Redes de sitios corporativos por país o idioma
Una empresa con presencia en España, Francia y Alemania puede gestionar empresa.es, empresa.fr y empresa.de desde una sola red multisite con mapeo de dominios. El core, los plugins y el tema se mantienen una vez. Cada equipo local gestiona su contenido de forma independiente. Este es uno de los casos de uso más comunes y donde más valor aporta la centralización.
Universidades y organizaciones con departamentos
Universidades que necesitan un sitio por facultad, departamento o proyecto de investigación encuentran en multisite una forma de mantener coherencia visual y control técnico sin gestionar 40 instalaciones separadas. La Universidad de Harvard, entre otras, utiliza redes WordPress multisite para parte de su infraestructura web.
Redes de franquicias con marca unificada
Franquicias donde cada punto de venta necesita su propia página con contenido local (horarios, equipo, ofertas) pero manteniendo el diseño corporativo. El Super Admin controla el tema y los plugins; cada franquicia gestiona su contenido.
Entornos de desarrollo y staging
Agencias que necesitan mantener múltiples sitios de desarrollo o staging temporal pueden usar multisite para crearlos y destruirlos rápidamente sin provisionar nuevas instalaciones.
Cuándo NO usar multisite: señales claras
Hay situaciones donde activar multisite genera más problemas de los que resuelve. Estas son las señales más habituales:
- Los sitios necesitan plugins incompatibles entre sí. Si un sitio necesita un plugin de caché que entra en conflicto con el que usa otro subsitio, multisite se convierte en un problema.
- Cada sitio tiene requisitos de rendimiento muy diferentes. Un blog con 200 visitas al mes y un e-commerce con 10.000 pedidos mensuales no deberían compartir base de datos.
- Necesitas migrar sitios individuales con frecuencia. Extraer un subsitio de una red multisite para convertirlo en instalación independiente es un proceso técnico delicado.
- Solo tienes 2 o 3 sitios. El overhead de configurar y mantener una red multisite no compensa cuando tienes pocos sitios. Es más práctico mantener instalaciones separadas.
- Los equipos de cada sitio necesitan autonomía total. Si los administradores necesitan instalar sus propios plugins o gestionar su propio hosting, multisite les limita demasiado.
Multisite vs. soluciones multiidioma: una confusión frecuente
Muchos equipos consideran multisite para gestionar un sitio en varios idiomas. Es posible hacerlo —un subsitio por idioma—, pero no siempre es la mejor opción. Plugins como WPML o Polylang permiten gestionar múltiples idiomas dentro de una sola instalación estándar, sin la complejidad adicional de una red.
La diferencia clave está en el modelo de contenido. Con multisite multiidioma, cada subsitio tiene su propio contenido completamente separado. Con un plugin de traducción, el contenido está vinculado: un artículo en español y su versión en inglés están conectados en la misma base de datos, lo que facilita la sincronización y el SEO hreflang.
Multisite multiidioma tiene sentido cuando cada versión del sitio es realmente diferente en estructura, contenido y funcionalidades. Si los sitios son traducciones casi literales del mismo contenido, un plugin multiidioma es más eficiente.
Implicaciones de hosting y rendimiento
No todos los proveedores de hosting soportan WordPress Multisite. Necesitas un hosting que permita configurar subdominios wildcard (si usas subdominios) y que no tenga restricciones en el número de dominios mapeados. Algunos hostings compartidos bloquean multisite explícitamente.
A nivel de rendimiento, la base de datos compartida puede convertirse en cuello de botella si la red crece mucho. Con 50+ subsitios activos, la tabla wp_users compartida y las consultas cross-site pueden ralentizar el panel de administración. Soluciones como object caching con Redis y la separación de la base de datos en servidor dedicado ayudan, pero añaden complejidad operativa.
Las copias de seguridad también son diferentes. Hacer backup de una red multisite significa respaldar toda la red de golpe. No puedes hacer backup selectivo de un solo subsitio con las herramientas estándar; necesitas soluciones que entiendan la estructura multisite.
Checklist: criterios para decidir si multisite es viable
Antes de activar multisite, responde a estas preguntas. Si la mayoría de respuestas son «sí», la arquitectura multisite probablemente encaje:
- ¿Los sitios comparten el mismo conjunto de plugins y temas?
- ¿La gestión centralizada de actualizaciones es una prioridad?
- ¿Los sitios tienen requisitos de rendimiento similares?
- ¿No necesitas migrar subsitios individuales con frecuencia?
- ¿Tu hosting soporta multisite y subdominios wildcard?
- ¿Tienes más de 5 sitios que mantener?
- ¿Los administradores de cada sitio no necesitan instalar sus propios plugins?
- ¿Tu equipo técnico (o tu desarrollador) tiene experiencia con multisite?
Si tres o más respuestas son «no», las instalaciones independientes probablemente sean una opción más segura y flexible. La decisión no es binaria ni universal: depende del contexto operativo de cada proyecto.
Preguntas frecuentes sobre WordPress Multisite
¿Puedo convertir una instalación normal de WordPress en multisite?
Sí, es posible activar multisite en una instalación existente añadiendo la constante define('WP_ALLOW_MULTISITE', true); en wp-config.php. Después, WordPress muestra un asistente de configuración de red en el panel de administración. Sin embargo, si la instalación tiene más de un mes, solo podrás usar subdominios (no subdirectorios).
¿Se puede desactivar multisite y volver a una instalación normal?
Técnicamente sí, pero no hay un botón para hacerlo. Requiere editar manualmente wp-config.php, .htaccess y limpiar las tablas de red de la base de datos. Si la red tiene subsitios con contenido, ese contenido se pierde a menos que lo migres previamente. Es un proceso que debería hacer un desarrollador con experiencia en multisite.
¿WordPress Multisite afecta al SEO?
No directamente. Google trata cada subsitio como un sitio independiente a efectos de rastreo e indexación. Si usas subdominios, cada subsitio tiene su propio dominio a ojos de Google. Si usas subdirectorios, Google los trata como secciones del mismo dominio. La elección entre subdominios y subdirectorios tiene las mismas implicaciones SEO que tendría en cualquier otra arquitectura web.
¿Cuántos sitios puede soportar una red multisite?
No hay un límite técnico definido por WordPress. WordPress.com opera millones de sitios en multisite. En la práctica, el límite lo marca el hardware del servidor y la optimización de la base de datos. Redes de 10-50 sitios funcionan bien en hosting de calidad. Redes de 100+ sitios necesitan infraestructura dedicada y optimización seria.
¿Puedo usar WooCommerce en multisite?
Sí, pero cada subsitio tiene su propia tienda independiente con su propio catálogo, pedidos y configuración. No hay un catálogo compartido entre subsitios de forma nativa. Existen plugins de terceros que permiten sincronizar productos entre subsitios, pero añaden complejidad y puntos de fallo.
Si estás evaluando la arquitectura técnica de un proyecto WordPress complejo —ya sea multisite u otra configuración—, puede ser útil contar con un desarrollador WordPress especializado que analice los requisitos concretos antes de tomar una decisión estructural difícil de revertir.
Mi opinión como desarrollador WordPress
Desde mi experiencia, la decisión de usar multisite rara vez debería tomarse solo por comodidad. He visto redes multisite que funcionan como relojería durante años en contextos corporativos bien definidos, y he visto otras que se convierten en un lastre técnico porque se activaron sin evaluar si los sitios realmente compartían necesidades. Lo que más me preocupa cuando alguien me consulta sobre multisite no es la configuración inicial —que es relativamente directa—, sino la proyección a medio plazo: qué pasa cuando un subsitio crece más que los demás, cuando un plugin crítico deja de ser compatible, o cuando necesitas sacar un sitio de la red. Esas son las preguntas que deberían responderse antes de escribir la primera línea en wp-config.
¿Necesitas ayuda con tu proyecto? Trabajo con negocios y agencias en WordPress, WooCommerce, IA e integraciones. Escríbeme y lo vemos juntos.
