Drupal multisite en 2026. Cuándo funciona, cuándo no, y con qué compararlo.

Gestionar varios sitios web con un solo equipo y una sola plataforma siempre ha sido un problema mal resuelto. Cada CMS popular ha intentado su variante —Multisite en WordPress, contenedores en JAMstack, tenants lógicos en la mayoría de SaaS— y todos tienen sus costes ocultos.

Drupal multisite es una de las soluciones más antiguas y a la vez más sólidas. Tan antigua que algunas generaciones de desarrolladores la han dado por muerta varias veces. Pero en 2024 la decisión oficial del núcleo de Drupal dejó claro que se mantiene como funcionalidad de primer nivel, y con la llegada de Drupal 11, Drupal CMS y Recipes (enero de 2025) ha ganado herramientas nuevas que la hacen más práctica que en cualquier momento anterior.

Esta guía repasa el estado real de Drupal multisite en 2026: arquitectura, casos de uso, comparación con WordPress, alternativas modernas (Pantheon Custom Upstreams, Acquia Site Factory, contenedores), guía técnica compacta con Drupal 11.3 y criterios para decidir si encaja con tu proyecto.

Qué es Drupal multisite

Drupal multisite es una característica nativa del core que permite servir múltiples sitios web independientes con una sola base de código. Una única instalación de Drupal (core, módulos y temas) ejecuta varios sitios; cada uno con su configuración, su contenido y, normalmente, su propia base de datos, pero compartiendo el mismo código fuente.

Drupal decide qué sitio cargar según el dominio solicitado: lee el HTTP_Host, busca dentro de sites/ la carpeta con ese nombre, carga su settings.php y conecta con la base de datos correspondiente.

Es importante entender desde el principio que existen dos arquitecturas completamente diferentes para servir múltiples sitios con una sola instalación de Drupal. La confusión entre ambas es la fuente de la mayoría de malas decisiones arquitectónicas.

Multisite tradicional (bases de datos separadas). Es la funcionalidad nativa del core. Se comparte la base de código pero cada sitio tiene su propia base de datos, configuración, usuarios y contenido totalmente aislados. Los sitios no comparten nada automáticamente. Es lo que se corresponde literalmente con "multisite" en la documentación oficial.

Multidominio con Domain (base de datos compartida). Una solución con el módulo contribuido Domain, que en 2026 tiene versiones 2.x y 3.x estables compatibles con Drupal 11. Aquí hay un solo sitio Drupal lógico con una sola base de datos, pero se sirve bajo varios dominios con control sobre qué contenido aparece en cada uno. Los usuarios están compartidos por defecto, el contenido también salvo que lo limites explícitamente. Domain 3.x ha migrado a usar Config Collections del core para gestionar overrides de configuración, y ha introducido soporte experimental para path prefix, que permite que varios "dominios" compartan hostname distinguiéndose por el primer segmento de la URL.

La elección entre las dos es casi siempre la decisión más importante del proyecto, y no tiene nada que ver con preferencias personales: depende de si los sitios comparten contenido/usuarios (Domain) o son proyectos radicalmente diferentes que solo comparten infraestructura técnica (multisite tradicional).

Cuándo multisite tiene sentido en 2026

Tras una década viendo implementaciones multisite —algunas brillantes, muchas desastrosas— el patrón está bastante claro.

Encaja bien cuando:

• Una organización publica muchos sitios con la misma estructura técnica pero aislados: portales universitarios por facultad, sitios municipales por departamento, sistemas de webs corporativas por filial, redes de medios con cabeceras independientes.
• Se quiere un solo equipo manteniendo el código pero se necesita que cada sitio tenga su propio ciclo editorial, sus usuarios, sus permisos y potencialmente su propio hosting.
• Los sitios comparten suficientes similitudes funcionales para justificar una base común, pero suficientes diferencias para no poder ser un único sitio multilingüe.
• Se quiere lanzar micrositios o campañas rápidamente con una estructura preconfigurada.

No encaja cuando:

• Los sitios comparten mucho contenido o usuarios y solo se diferencian por branding (es el caso clásico para Domain, no multisite).
• Cada sitio tiene necesidades técnicas radicalmente diferentes que requieren versiones de módulos incompatibles entre sí (mejor instalaciones separadas).
• El equipo no tiene experiencia con Composer, Drush y despliegues controlados (multisite multiplica los problemas operativos si no se tiene el proceso bajo control).
• Se busca una solución donde cada sitio pueda escalar y fallar independientemente a nivel de infraestructura (hay que ir a contenedores por sitio o plataformas como Pantheon o Acquia).

Ventajas reales de un multisite bien hecho

El argumentario habitual de "menos trabajo, más resultado" es cierto, pero las ventajas concretas merecen un poco de precisión.

Mantenimiento centralizado. Una sola actualización de core o de un módulo se aplica a todos los sitios a la vez. Si descubres que un módulo personalizado tiene un bug, lo corriges una vez y todos los sitios reciben el patch en el siguiente despliegue. Para equipos que han gestionado 10 instalaciones Drupal separadas, el ahorro es sustancial. Para equipos que gestionan 50 o 100, es la diferencia entre viable e inviable.

Costes de infraestructura más bajos. Un solo servidor puede alojar decenas de sitios porque comparten código y, según la configuración, también recursos de PHP, OPcache y caches. Comparado con tener N instalaciones separadas cada una con su infraestructura, la reducción es evidente. Comparado con plataformas especializadas tipo Acquia Site Factory, los costes también son sensiblemente más bajos porque no tienes el coste de licencia ni de plataforma gestionada.

Reutilización de código y configuración. Con la aparición de Recipes en Drupal 11 (enero de 2025), el patrón de reutilización ha mejorado radicalmente. Los Recipes son paquetes preconfigurados de funcionalidad —tipos de contenido, vistas, bloques, permisos, módulos— que se pueden aplicar a cualquier instalación de Drupal 11.2 o superior. En un multisite, puedes crear un Recipe propio para "blog corporativo base" y aplicarlo a todos los sitios nuevos de una vez. Sustituyen a los antiguos install profiles con una sintaxis mucho más limpia y componible. Drupal CMS 1.0 y 2.0 se construyen enteramente sobre Recipes.

Escalabilidad horizontal en lanzamientos. Añadir un sitio nuevo a un multisite bien configurado es prácticamente instantáneo: nueva base de datos vacía, nueva carpeta bajo sites/, settings.php apuntando a la BD, instalación vía Drush con el perfil o Recipe elegido. Puedes tener un nuevo sitio funcionando en minutos.

Consistencia de seguridad. Un punto subestimado: con 50 instalaciones separadas es estadísticamente casi imposible mantenerlas todas al día de parches de seguridad. Con un multisite es imposible no hacerlo —la misma actualización de código protege toda la flota a la vez. El aviso de seguridad crítico de Drupal del 20 de mayo de 2026 (PSA-2026-05-18) habría sido una pesadilla para cualquier agencia con 30 sitios separados; para un multisite, una sola actualización.

Compartición de contenido (solo con Domain). Si optas por Domain en lugar de multisite tradicional, puedes tener contenido único publicado simultáneamente en varios dominios, con el control fino para asignar qué nodo se ve en cuál. Es una funcionalidad que no tiene equivalente nativo en la mayoría de CMS.

Drupal multisite vs WordPress multisite

Ambos sistemas existen y resuelven necesidades reales, pero la filosofía es lo bastante diferente para justificar compararlos con precisión.

Configuración inicial. En Drupal, activar multisite no requiere modificar el core: creas una carpeta con el nombre del dominio bajo sites/, le pones un settings.php con la conexión a la nueva BD, y Drupal lo detecta automáticamente. En WordPress hay que editar wp-config.php para definir constantes específicas (WP_ALLOW_MULTISITE, después MULTISITE), tocar .htaccess, ejecutar la instalación de red desde el panel, y decidir entre subdominios o subdirectorios en ese momento —decisión difícil de cambiar después.

Gestión de dominios. Drupal multisite está diseñado para dominios completamente independientes desde el primer día. WordPress multisite por defecto asume subdominios o subdirectorios de un dominio base; para dominios personalizados hace falta domain mapping (hoy ya en el core, pero con particularidades según hosting).

Estructura de bases de datos. Drupal permite base de datos separada por sitio (la opción habitual y recomendada) o BD compartida con prefijos. WordPress multisite impone una sola BD compartida con prefijo por sitio. El aislamiento de Drupal significa que un sitio con mucho tráfico no degrada la BD de los demás, que los backups por sitio son triviales y que un error de corrupción afecta solo a un sitio, no a toda la red.

Aislamiento funcional. En Drupal cada sitio puede tener módulos activados y configuración completamente diferente, incluso versiones de tema diferentes. En WordPress multisite todos los sitios comparten los archivos de plugins y themes; puedes desactivarlos por sitio, pero los archivos son comunes. WordPress tiene el concepto de "super admin de red" que puede limitar la autonomía de los admins de cada sitio; Drupal multisite no tiene esta jerarquía porque cada sitio es esencialmente independiente.

Portabilidad. Sacar un sitio de un multisite Drupal es relativamente sencillo (se copia la carpeta, la BD y se aísla la instalación). En WordPress multisite, separar un sitio de la red es complejo por la forma en que la estructura de BD compartida almacena las referencias.

Filosofía. WordPress multisite nació para habilitar redes de blogs estilo WordPress.com. Drupal multisite es una herramienta de arquitectura para gestionar flotas de sitios generalmente más complejos. Si el caso de uso es "habilitar 200 blogs simples con auto-registro", WordPress multisite puede ser perfectamente adecuado. Si es "una universidad con 40 portales con workflows editoriales propios", Drupal multisite es prácticamente la única opción open source razonable.

Configuración práctica con Drupal 11.3

Esta sección da una pasada compacta por el caso típico: quieres añadir un segundo sitio a una instalación Drupal 11 existente (gestionada con Composer, como debería ser en 2026).

1. Preparación del servidor y dominios. Cada dominio que servirá un sitio del multisite debe apuntar al mismo servidor a nivel de DNS, y el webserver (Nginx o Apache) debe tener un server block o virtual host que sirva todos esos dominios desde la misma raíz de Drupal. Para desarrollo local, la opción recomendada en 2026 sigue siendo DDEV, que tiene soporte nativo de multisite vía el flag --additional-hostnames.

2. Crear la carpeta del nuevo sitio. Bajo web/sites/, crea una carpeta con el nombre exacto del dominio:

mkdir -p web/sites/segundo-dominio.com/files
chmod 755 web/sites/segundo-dominio.com
chmod 775 web/sites/segundo-dominio.com/files

3. Generar el settings.php específico. Copia la plantilla y edita la conexión a la nueva BD:

cp web/sites/default/default.settings.php web/sites/segundo-dominio.com/settings.php

Dentro del nuevo settings.php, configura el $databases['default']['default'] apuntando a una BD vacía creada previamente. En Drupal 11 es buena práctica externalizar credenciales con variables de entorno y cargarlas con getenv(), sobre todo si trabajas con plataformas como Pantheon, Platform.sh/Upsun o Lando.

4. (Opcional) sites.php para mapeos avanzados. Drupal detecta el sitio por coincidencia de nombre de carpeta con HTTP_Host. Si necesitas alias (por ejemplo, www.segundo-dominio.com y segundo-dominio.com apuntando al mismo sitio) o entornos staging con dominios diferentes al de producción, edita web/sites/sites.php:

$sites['www.segundo-dominio.com'] = 'segundo-dominio.com';
$sites['staging.segundo-dominio.com'] = 'segundo-dominio.com';

5. Instalación vía Drush con un Recipe. En lugar de ir al navegador y seguir el instalador, en 2026 el patrón limpio es:

drush --uri=https://segundo-dominio.com site:install \
  --site-name="Segundo Dominio" \
  --account-name=admin \
  -y
drush --uri=https://segundo-dominio.com recipe ../recipes/blog-corporativo-base

El segundo comando aplica un Recipe propio que tienes guardado fuera de web/ (por ejemplo en recipes/). Este paso es el que sustituye la configuración manual repetida sitio por sitio.

6. Gestión de módulos y temas. Todo lo que vive bajo web/modules/ y web/themes/ está disponible para todos los sitios, pero cada sitio decide qué activa vía su propia configuración. Si necesitas un módulo específico de un solo sitio (caso raro pero posible), puedes ponerlo bajo web/sites/segundo-dominio.com/modules/.

7. Workflow de actualización. Los updates de código los haces una vez:

composer update drupal/core-recommended drupal/core-composer-scaffold drupal/core-project-message -W

Los updates de BD los ejecutas por cada sitio:

drush --uri=https://primer-dominio.com updb -y
drush --uri=https://segundo-dominio.com updb -y

Para flotas grandes vale la pena envolver este paso con un script o con Drush aliases.

Alternativas modernas al multisite "clásico"

Drupal multisite no es la única manera de servir múltiples sitios con infraestructura compartida. En 2026 hay alternativas maduras que conviene conocer antes de decidir.

Pantheon Custom Upstreams. Pantheon permite definir un repositorio "upstream" que sirve de base para N sitios Drupal independientes. Cada sitio tiene su propia instalación, pero comparten la misma base de código mantenida en un solo lugar. Los cambios en el upstream se propagan a todos los sitios con un clic. Es similar en filosofía al multisite, pero con cada sitio en infraestructura separada (BD propia, instancias PHP propias, escalado independiente). Buena opción para agencias con muchos clientes que comparten tecnología pero no infraestructura.

Acquia Site Factory. La solución empresarial pura: una plataforma SaaS específicamente diseñada para gestionar cientos o miles de sitios Drupal con código compartido. Tiene toda la maquinaria de governance, deployment workflows multinivel, gestión de usuarios global y SLA contractual. Cara, pero para organizaciones tipo gran corporación, gobierno o universidad con requerimientos serios de auditoría, suele ser la respuesta correcta. Drupal multisite "casero" no escala bien a esa dimensión a nivel operativo (no técnico).

Container-per-site (Docker / Kubernetes). El enfoque moderno de microservicios: cada sitio vive en su propio contenedor con su instalación de Drupal, su BD y su ciclo de vida. Comparten base de imagen Docker (que puedes actualizar de manera centralizada), pero son operativamente independientes. Ventaja clara: aislamiento total de rendimiento y fallos. Desventaja: más consumo de recursos y complejidad operativa (Kubernetes tiene una curva de aprendizaje real). Buena opción cuando el aislamiento es más importante que la eficiencia de recursos, o cuando los sitios tienen patrones de carga muy diferentes.

Drupal CMS con Recipes. Para casos donde cada sitio puede ser una instalación separada pero queremos uniformidad funcional, Drupal CMS 2.0 (octubre de 2025) y su ecosistema de Recipes es una alternativa ligera al multisite. Defines tu "stack" en un Recipe propio y aplicarlo a cada sitio nuevo es cuestión de un comando Drush.

La pregunta no es "qué es mejor". Es qué encaja con tu caso concreto. Multisite tradicional es imbatible en eficiencia de recursos y centralización de mantenimiento. Container-per-site es imbatible en aislamiento. Plataformas gestionadas son imbatibles en operaciones a escala empresarial. Pantheon Upstreams es un término medio elegante.

SEO en un entorno multisite

La parte SEO es más sencilla de lo que parece, porque cada sitio de un multisite Drupal es, a todos los efectos prácticos, un sitio independiente para Google. Pero hay cinco puntos que hay que vigilar.

Dominios vs subdominios vs subrutas. Para sitios que tienen que construir autoridad independiente (marcas diferentes, mercados diferentes), dominios separados. Para sitios que comparten marca y autoridad (misma empresa, idiomas o regiones diferentes), subdominios o subrutas. Drupal multisite gestiona perfectamente dominios y subdominios; subrutas es técnicamente posible pero complicado, y la solución natural con subrutas suele ser un solo sitio Drupal multilingüe (no un multisite). Domain 3.x ha añadido soporte experimental de path prefix que cambia un poco esto, pero con prudencia.

Contenido duplicado. Si usas Domain para compartir contenido entre dominios, tendrás que configurar canonical tags con el módulo Metatag apuntando a la versión principal. En multisite tradicional el contenido vive en bases de datos diferentes, así que el riesgo de duplicado solo existe si físicamente copias contenido entre sitios, cosa rara.

Sitemaps y robots.txt independientes. Cada sitio debe tener su sitemap.xml y su robots.txt. El módulo Simple XML Sitemap funciona de forma natural con multisite —cada sitio genera el suyo sin interferir con los demás. Robots es parte del código base y se aplica a todos, pero a menudo se quiere diferenciar (por ejemplo, evitar indexación de sitios internos); para eso existe el módulo RobotsTxt que permite versión por sitio.

Hreflang. Si los sitios corresponden a idiomas/regiones de la misma organización, configura hreflang adecuadamente con Metatag o Hreflang Multilingual. Multisite no automatiza esta relación porque los sitios son independientes; hay que definirla explícitamente. Una alternativa más limpia para casos claramente multilingües es un solo sitio Drupal con la traducción nativa del core.

Rendimiento compartido. Una optimización a nivel de código (caches, CDN, lazy loading de imágenes, formato AVIF/WebP) se propaga a todos los sitios a la vez. Esto es una ventaja directa de SEO técnico: todos los sitios se benefician de cada mejora de Core Web Vitals que apliques.

Decisión: tres preguntas para descartar opciones rápidamente

Si has leído hasta aquí y aún dudas entre Drupal multisite, Domain, instancias separadas o plataformas especializadas, estas tres preguntas resuelven la mayoría de casos.

1. ¿Los sitios comparten contenido o usuarios?

• Sí, a menudo → Domain.
• No, nunca → multisite tradicional o instancias separadas.

2. ¿Cuántos sitios prevés mantener simultáneamente?

• Hasta unos 15-20, con el mismo equipo → multisite tradicional es ideal.
• 20-100, con requerimientos de aislamiento → Pantheon Custom Upstreams o container-per-site.
• 100+ con governance empresarial → Acquia Site Factory o equivalente.

3. ¿Necesitas que los sitios escalen y fallen independientemente?

• Sí → container-per-site, Pantheon o Acquia.
• No, todos tienen patrones de carga similares → multisite tradicional.

Estas tres preguntas resuelven el 90% de los casos. El resto son matices de equipo, presupuesto y governance que no se resuelven leyendo un artículo.

Lo que hay que recordar

Drupal multisite en 2026 no es una solución antigua que sobrevive por inercia. Es una herramienta madura, soportada oficialmente, bien mantenida y compatible con las novedades más importantes del ecosistema (Recipes, Drupal CMS, Drupal 11). Para equipos técnicos con experiencia en Drupal que tienen que servir decenas de sitios con una misma base tecnológica, sigue siendo una de las soluciones más eficientes y sólidas del panorama open source.

Lo que ha cambiado es el contexto. Hoy multisite compite no solo con instalaciones separadas, sino también con plataformas especializadas, contenedores orquestados y workflows basados en Recipes. La decisión ya no es "multisite o no"; es qué patrón multitenant encaja con tu equipo, escala y presupuesto. Y para una buena parte de los casos, la respuesta sigue siendo multisite, ahora potenciado con las herramientas nuevas que la versión 11 y Drupal CMS han aportado.