Drupal multisite: estrategias para gestionar múltiples webs desde una sola plataforma

Drupal multisite: gestionar múltiples webs desde una sola instalación

Drupal ofrece varias estrategias para gestionar múltiples sitios web desde una infraestructura compartida. Para organizaciones que operan varias marcas, filiales o micrositios, esta capacidad reduce significativamente los costes de mantenimiento, hosting y gestión técnica frente a mantener instalaciones independientes.

En nuestra experiencia con proyectos como la gestión de múltiples sites para Grupo Damm, donde operamos más de 10 sitios web para diferentes marcas del grupo, hemos probado y refinado las distintas aproximaciones que Drupal permite. Desde nuestro servicio de desarrollo y mantenimiento Drupal gestionamos arquitecturas multisitio para varios clientes.

Multisite nativo vs instalaciones independientes

Drupal incluye de serie la capacidad multisite: una sola base de código compartida que sirve múltiples sitios, cada uno con su propia base de datos y configuración. El directorio sites/ alberga la configuración específica de cada sitio, y Drupal determina qué configuración cargar según el dominio de la petición.

La ventaja principal es el mantenimiento: una sola actualización del core y de los módulos contribuidos se aplica a todos los sitios simultáneamente. La desventaja es que todos los sitios comparten las mismas versiones de módulos, lo que puede ser problemático si un sitio necesita una versión específica de un módulo que es incompatible con otro.

Domain Access: multisitio con base de datos compartida

El módulo Domain Access ofrece una alternativa al multisite nativo donde todos los sitios comparten una misma base de datos. El contenido se etiqueta con el dominio al que pertenece, permitiendo compartir contenido entre sitios o mantenerlo exclusivo de uno. Esto es ideal cuando los sitios comparten parcialmente catálogos, noticias o recursos.

Este enfoque funciona bien para redes de sitios con contenido solapado, como cadenas de tiendas con información corporativa compartida pero contenido local específico, o grupos editoriales con secciones temáticas que comparten ciertos artículos.

Gestión de configuración en entornos multisitio

La gestión de configuración es donde los proyectos multisitio se complican. El sistema de Configuration Management de Drupal (config export/import) está diseñado para una sola instalación. En entornos multisitio, necesitas herramientas adicionales como Config Split o Config Ignore para gestionar la configuración que es común a todos los sitios y la que es específica de cada uno.

Una buena práctica es definir tres capas de configuración: configuración base compartida por todos los sitios, configuración por tipo de sitio (si hay plantillas) y configuración específica de cada sitio individual. Esto permite aplicar cambios globales de forma eficiente sin afectar las personalizaciones locales.

Rendimiento y escalabilidad

En arquitecturas multisitio, el rendimiento requiere atención específica. Cada sitio necesita su propia estrategia de caché (Varnish con VCLs diferenciados por dominio), su propio índice de búsqueda (Solr core o Elasticsearch index por sitio) y su propia configuración de CDN si sirve assets desde dominios diferentes.

La monitorización también se multiplica: no basta con saber que la infraestructura está sana — necesitas métricas por sitio para identificar cuál está consumiendo recursos excesivos o cuál tiene problemas de rendimiento específicos. Si gestionas o planeas gestionar múltiples sitios Drupal, podemos ayudarte a diseñar la arquitectura que mejor equilibre eficiencia operativa y flexibilidad.

Cómo elegir: multisite nativo, Domain Access o instalaciones separadas

La decisión de arquitectura es la más cara de revertir en todo el proyecto, así que merece responderse con criterio y no por inercia. La primera pregunta es cuánta funcionalidad comparten realmente los sitios: si todos usan el mismo theme, los mismos módulos y flujos editoriales similares, el multisite nativo maximiza el ahorro. Si lo que comparten es contenido —noticias corporativas, catálogo, recursos— más que código, Domain Access encaja mejor. Y si cada sitio tiene ciclos de vida, equipos y requisitos técnicos distintos, forzarlos a convivir en una sola plataforma acaba costando más que mantener instalaciones separadas.

La segunda pregunta es organizativa: ¿quién decide cuándo se actualiza? En un multisite, una actualización del core afecta a todos los sitios a la vez, de modo que necesitas una ventana de mantenimiento común y pruebas de regresión que cubran el conjunto. Si una de las marcas no puede permitirse esa dependencia —por ejemplo, porque tiene campañas críticas en fechas distintas al resto— es una señal de alarma. También pesa la integración con sistemas externos: cuando cada sitio conecta con CRMs o ERPs diferentes, conviene revisar cómo se gestionan las integraciones en Drupal con APIs, CRMs y sistemas externos para que la arquitectura compartida no se convierta en un cuello de botella.

Un matiz importante: estas opciones no son excluyentes entre sí. Es habitual combinar un multisite nativo para el grueso de las marcas con una instalación separada para el sitio que tiene requisitos especiales, o con un frontend desacoplado en un caso concreto. Si te planteas esa vía, nuestra guía sobre cuándo desacoplar el frontend en Drupal te ayudará a valorar si el coste extra se justifica.

Despliegues, CI/CD y operaciones en multisite

Operar diez sitios desde una plataforma exige industrializar el despliegue. El fichero sites/sites.php mapea dominios a directorios de sitio, y herramientas como Drush permiten ejecutar operaciones por sitio con la opción --uri: actualizar la base de datos, importar configuración o vaciar cachés de forma selectiva. En la práctica, cualquier despliegue serio recorre todos los sitios en bucle —drush @site updb, drush @site cim, drush @site cr— y falla en bloque si alguno de ellos no completa el proceso, porque dejar la mitad del parque actualizado y la otra mitad no es la peor situación operativa posible.

El pipeline de CI/CD debe reflejar esa realidad: entornos de desarrollo y staging que repliquen la estructura multisite (no basta con probar en un solo sitio), smoke tests por dominio tras cada despliegue y una estrategia de rollback ensayada. Las ventanas de actualización se planifican para el conjunto, y conviene automatizar la verificación posterior: un script que pida la portada y una página interior de cada dominio y compruebe códigos 200 detecta en segundos lo que de otro modo descubriría un cliente. Este tipo de disciplina es la misma que aplicamos en proyectos Drupal para Grupo Damm como Alfil Logistics, donde la fiabilidad del despliegue es parte del servicio.

Las migraciones de versión mayor merecen mención aparte: en un multisite se migra la plataforma entera, no un sitio suelto. Si todavía tienes sitios en Drupal 10, el proceso descrito en nuestra guía de migración a Drupal 10: estrategia, herramientas y plazos aplica multiplicado por el número de sitios, y el calendario de fin de vida de diciembre de 2026 no deja margen para improvisar.

Seguridad en arquitecturas multisite

La seguridad es el arma de doble filo del multisite. A favor: un parche de seguridad del core o de un módulo contribuido se aplica una sola vez y protege a todos los sitios simultáneamente, lo que reduce drásticamente la ventana de exposición típica de los parques de sitios dispersos donde siempre hay alguno olvidado. En contra: la base de código compartida es también superficie de ataque compartida. Una vulnerabilidad explotada en el core, o un módulo comprometido, afecta potencialmente a todos los dominios a la vez, y un atacante que consiga ejecución de código en la plataforma puede moverse entre sitios si el aislamiento no está bien hecho.

Por eso las buenas prácticas son innegociables: bases de datos separadas por sitio (o al menos prefijos y credenciales distintas), directorios de ficheros aislados con permisos correctos, cuentas de administración independientes por sitio —nada de reutilizar el mismo usuario y contraseña en todos— y monitorización de los avisos de seguridad de Drupal (PSA) con un procedimiento claro de aplicación urgente. Los backups deben poder restaurarse por sitio: si un solo dominio sufre un incidente, restaurar la plataforma entera a un estado anterior penaliza a los sitios sanos. Para organizaciones que quieren formalizar estas prácticas, nuestro pilar sobre la certificación ISO 27001 explica cómo convertirlas en un sistema de gestión auditable, y un pentesting periódico sobre la plataforma valida que el aislamiento entre sitios resiste un ataque real.

SEO y analítica cuando gestionas muchos dominios

Cada sitio del multisite es, a ojos de Google, una propiedad independiente: necesita su propio sitemap XML, su propia verificación en Search Console y su propia configuración de robots. El error clásico es generar un único sitemap desde el sitio «principal» y olvidar el resto. Con módulos como Simple XML Sitemap la generación por sitio es directa, pero hay que verificar dominio a dominio que el sitemap se sirve y se indexa.

Cuando los sitios comparten contenido —el escenario típico de Domain Access— el riesgo es el contenido duplicado: la misma noticia accesible desde tres dominios sin canonical definido diluye el posicionamiento de todos. La regla es decidir qué dominio es el canónico de cada pieza y marcarlo de forma consistente. Si además los sitios sirven idiomas o mercados distintos, el etiquetado hreflang entre dominios se vuelve obligatorio. Y en rendimiento, recuerda que las Core Web Vitals se miden por origen: un sitio lento no «contagia» su métrica a los demás, pero sí comparte la infraestructura que lo hace lento, así que las técnicas de nuestra guía de optimización de rendimiento en Drupal con caché, BigPipe y Varnish conviene aplicarlas a nivel de plataforma y medirlas por dominio.

Drupal en 2026: qué significa para un multisite

El calendario de versiones condiciona cualquier plataforma compartida. A julio de 2026, la versión estable es Drupal 11.4 (publicada el 1 de julio), y la semana del 7 de diciembre de 2026 llegarán Drupal 12.0 y Drupal 11.5. La fecha crítica es el 9 de diciembre de 2026: fin de vida de Drupal 10. Un multisite que siga en Drupal 10 ese día tendrá todos sus sitios sin soporte de seguridad de golpe — el riesgo se multiplica por el número de dominios. Si es tu caso, la migración a Drupal 11 debería estar ya planificada, y las novedades que trajo la rama 11 —Recipes, hooks como clases, Symfony 7— están explicadas en nuestro análisis de Drupal 11: Recipes, hooks como clases y Symfony 7.

Dos novedades recientes juegan a favor del multisite. Las Recipes permiten empaquetar configuración y funcionalidad reutilizable —exactamente lo que un multisite necesita para estandarizar «tipos de sitio» (la capa intermedia de configuración que mencionábamos arriba). Y Drupal CMS, la distribución orientada a builders lanzada sobre esa base, marca la dirección del ecosistema: plataformas que se montan por composición de piezas probadas en lugar de configuración artesanal sitio a sitio. Para quien opera decenas de webs, ese enfoque reduce el coste marginal de cada sitio nuevo, que es en última instancia la métrica que justifica un multisite.

Errores comunes en proyectos multisite

Tras años operando plataformas multisitio, estos son los fallos que más se repiten en las auditorías. Uno: elegir multisite solo por ahorro de hosting, cuando los sitios no comparten casi nada — el ahorro se evapora en coordinación. Dos: no ensayar la restauración por sitio; el primer incidente real descubre que el backup solo se puede restaurar en bloque. Tres: permitir que cada sitio instale módulos «solo para él» sin gobernanza; en dos años la plataforma arrastra decenas de módulos que nadie sabe quién usa y las actualizaciones se vuelven rusa roulette. Cuatro: probar los despliegues en un único sitio de referencia y asumir que el resto se comportará igual, ignorando las diferencias de configuración local. Cinco: olvidar la capa de SEO por dominio (sitemaps, Search Console, canonicals) porque «la plataforma ya funciona». Ninguno de estos errores es técnico en origen: todos nacen de tratar el multisite como un proyecto de infraestructura en lugar de como un producto compartido con reglas de convivencia.

Preguntas frecuentes sobre Drupal multisite

¿Cuántos sitios puede soportar un multisite de Drupal?

No hay límite técnico práctico: existen plataformas con cientos de sitios. El límite real es operativo — la capacidad del equipo para probar y desplegar cambios que afectan a todos a la vez. A partir de unas decenas de sitios, la automatización de pruebas y despliegues deja de ser opcional.

¿Multisite significa que todos los sitios comparten servidor?

Comparten base de código, pero la infraestructura puede escalar horizontalmente como cualquier Drupal: varios servidores web tras un balanceador, réplicas de base de datos y CDN por dominio. Lo que no puedes separar es la versión del código: eso es lo que define al multisite.

¿Puedo migrar un sitio del multisite a una instalación independiente?

Sí. Cada sitio tiene su propia base de datos (en multisite nativo), así que extraerlo consiste en desplegar el mismo código como instalación individual y apuntarla a esa base de datos. Es la vía de escape natural cuando un sitio desarrolla requisitos incompatibles con el resto.

¿Qué pasa con los módulos de pago o licencias en multisite?

Depende del proveedor: algunas licencias se venden por instalación (una licencia cubre todos los sitios) y otras por dominio. Conviene revisarlo antes de asumir que el ahorro aplica también al software comercial.

¿Domain Access sigue siendo buena opción en 2026?

Sigue mantenido y es válido cuando la necesidad central es compartir contenido entre dominios. Pero si el proyecto es nuevo y los sitios no comparten contenido, el multisite nativo o las Recipes para estandarizar instalaciones suelen ser caminos más limpios y con menos acoplamiento.

¿Qué coste de mantenimiento tiene un multisite frente a sitios separados?

Como orden de magnitud, el mantenimiento evolutivo y correctivo de una plataforma multisite bien construida crece de forma casi plana con cada sitio adicional: la actualización de core y módulos se hace una vez, y el coste incremental se concentra en las pruebas por dominio y en las personalizaciones locales. Con instalaciones separadas, ese mismo trabajo se repite íntegro por cada web. En parques de más de tres o cuatro sitios similares, la diferencia suele justificar por sí sola la migración a una plataforma compartida.

Conclusión

Drupal multisite sigue siendo, en 2026, una de las formas más eficientes de operar un parque de webs corporativas: menos coste de mantenimiento, parcheo de seguridad centralizado y un coste marginal por sitio nuevo que ninguna colección de instalaciones sueltas puede igualar. Pero solo funciona con disciplina: arquitectura elegida por las razones correctas, configuración en capas, despliegues automatizados con verificación por dominio, seguridad con aislamiento real y SEO gestionado sitio a sitio. Si tu organización opera —o va a operar— varias webs sobre Drupal, ese es exactamente el tipo de plataforma que ayudamos a diseñar, construir y mantener.