Cómo construir un portal corporativo multisite con gestión centralizada de contenidos y branding consistente en Drupal

Llevo años viendo el mismo escenario repetirse. Grupos empresariales, franquicias, redes de centros educativos, cadenas hoteleras, organismos públicos con delegaciones por todo el territorio... Todos llegan con el mismo dolor: necesitan una web diferenciada por cada unidad de negocio, pero con un gobierno central que garantice coherencia de marca, eficiencia operativa y control real sobre el ciclo de vida de los contenidos. La realidad es que Drupal ofrece un ecosistema maduro para resolver esto a escala. Pero solo si eliges la arquitectura correcta y los módulos adecuados.

En esta guía te cuento cómo diseñar, implementar y operar un portal corporativo multisite en Drupal con gestión centralizada de contenidos y branding consistente. Va dirigida a directores de TI y responsables digitales que están evaluando esta solución para su organización. Vamos al grano.

Cuándo tiene sentido un multisite (y cuándo no)

La decisión entre multisite y múltiples instancias separadas no es trivial. Te lo digo porque condiciona toda la evolución futura de la plataforma. Un enfoque multisite aporta valor real cuando se cumplen varias de estas condiciones a la vez:

Indicadores a favor del multisite:

• Más de cinco sitios que comparten al menos el 60% de la funcionalidad (tipos de contenido, workflows, integraciones).
• Necesidad de compartir contenidos entre sitios sin duplicación manual ni feeds RSS intermedios.
• Equipo técnico reducido que no puede mantener N instalaciones con sus respectivos ciclos de actualización de seguridad.
• Requisito de branding corporativo uniforme con variaciones controladas por unidad de negocio.
• Gobierno corporativo que exige auditoría unificada de publicaciones y roles.

Indicadores a favor de instalaciones separadas:

• Sitios con requisitos funcionales radicalmente distintos (un e-commerce con Drupal Commerce frente a un portal institucional puro).
• Regulaciones que exigen aislamiento de datos a nivel de infraestructura (no solo lógico).
• Equipos locales con autonomía total y sin voluntad de coordinación técnica.
• Diferencias de escala extremas: un sitio con 50 millones de visitas mensuales junto a otro con 5.000.

Traducido: la mayoría de grupos empresariales españoles con entre 5 y 50 sitios corporativos se benefician de un enfoque multisite bien implementado. El coste total de propiedad (TCO) se reduce entre un 30% y un 50% respecto a instalaciones independientes. ¿La razón principal? Reducción del esfuerzo de mantenimiento, actualizaciones de seguridad centralizadas y reutilización de desarrollos custom. Punto.

Arquitecturas multisite en Drupal: opciones y sus trade-offs

Drupal permite múltiples aproximaciones al multisite. Cada una implica compromisos distintos entre aislamiento, complejidad operativa y capacidad de compartir recursos. Te las desgrano.

Drupal Multisite nativo (sites/*)

La funcionalidad multisite nativa de Drupal permite ejecutar múltiples sitios desde un único codebase, cada uno con su propia base de datos y directorio de configuración bajo sites/. Lo que te da:

• Comparte código PHP y módulos contribuidos, reduciendo el mantenimiento de actualizaciones.
• Aísla datos a nivel de base de datos (cada sitio tiene la suya).
• Dificulta compartir contenido entre sitios sin módulos adicionales.
• Complica los despliegues cuando un sitio necesita una versión diferente de un módulo.

Este modelo funciona bien para organizaciones donde los sitios son estructuralmente idénticos y las diferencias se limitan a contenido y tema visual. Ni más ni menos.

Domain Access: multisite en una sola instalación

El módulo Domain Access opera desde una única instalación Drupal con una sola base de datos, asignando contenidos y configuraciones a dominios específicos. Sus ventajas:

• Compartir contenido entre sitios es nativo: un nodo puede publicarse en uno, varios o todos los dominios simultáneamente.
• Una sola base de datos simplifica backups, búsquedas transversales y reporting.
• Los roles y permisos pueden segmentarse por dominio.
• La gestión editorial se centraliza de forma natural.

Las contrapartidas: un fallo en la aplicación afecta a todos los sitios, la escalabilidad horizontal es más compleja, y la personalización profunda por sitio requiere disciplina en el uso de condiciones de dominio.

Domain Access es la opción preferida para portales corporativos multisite con gestión centralizada. Te lo digo claro: maximiza la capacidad de compartir contenidos y unificar la administración.

Config Split + instalaciones con codebase compartido

Para organizaciones que necesitan mayor aislamiento pero quieren mantener coherencia en el desarrollo, Config Split permite gestionar configuraciones específicas por entorno o por sitio dentro de un mismo repositorio de código. Combinado con un pipeline CI/CD robusto, cada sitio despliega desde el mismo repositorio pero con su propio config/sync segmentado.

Este enfoque híbrido es ideal cuando se requiere aislamiento de base de datos por regulación pero se desea mantener la uniformidad del codebase. Lo he visto funcionar especialmente bien en sector financiero y sanitario.

Gestión centralizada de contenidos: compartir sin duplicar

Aquí está el valor diferencial real de un multisite bien construido. En Drupal, esto se implementa combinando varios patrones que se complementan entre sí.

Contenido federado con Domain Access

Con Domain Access activado, cada nodo lleva asociado un campo que indica en qué dominios es visible. El flujo editorial típico que recomiendo:

1. El equipo central crea contenido corporativo (noticias del grupo, políticas, comunicados) y lo publica en todos los dominios.
2. Los equipos locales crean contenido específico de su sitio.
3. Un contenido local puede "promoverse" a otros dominios mediante un cambio de asignación de dominio, sin duplicación.

Módulos complementarios para esta capa:

• Domain Content: vistas filtradas por dominio activo para la gestión editorial.
• Domain Config: sobreescritura de configuraciones por dominio (nombre del sitio, logo, slogan, configuración de módulos).
• Entity Share: para escenarios donde se necesita sincronización entre instalaciones separadas que comparten cierto contenido.

Taxonomías y vocabularios compartidos

Las taxonomías actúan como columna vertebral de la organización de contenidos transversal. Un vocabulario de categorías corporativas compartido por todos los sitios permite:

• Navegación consistente en todo el ecosistema.
• Agregación de contenidos por categoría independientemente del sitio de origen.
• Reporting corporativo sobre producción editorial por temática.

Parece un detalle menor, pero llevo años viendo proyectos multisite fracasar porque cada sitio creó sus propias taxonomías sin coordinación. No cometas ese error.

Media Library centralizada

La biblioteca de medios de Drupal, combinada con Domain Access, permite gestionar un repositorio de activos digitales (imágenes, vídeos, documentos) compartido. El equipo de marca sube los recursos aprobados una sola vez y quedan disponibles para todos los editores del ecosistema. Los permisos granulares de la Media Library permiten restringir quién puede subir, editar o eliminar activos corporativos frente a activos locales.

Branding consistente: sistema de temas y Design System en Drupal

Mantener la coherencia visual en un ecosistema multisite requiere un enfoque sistemático en la capa de presentación. La estrategia que recomiendo se basa en un tema base corporativo con subtemas por sitio.

Arquitectura de temas

themes/custom/
├── corporativo_base/         # Tema base con Design System completo
│   ├── css/
│   │   ├── tokens.css        # Variables CSS (colores, tipografías, espaciados)
│   │   ├── components/       # Componentes reutilizables
│   │   └── layouts/          # Grids y layouts corporativos
│   ├── templates/            # Templates Twig base
│   └── corporativo_base.info.yml
├── sitio_madrid/             # Subtema: hereda de corporativo_base
│   ├── css/
│   │   └── overrides.css     # Solo sobreescrituras de tokens
│   └── sitio_madrid.info.yml
└── sitio_barcelona/          # Subtema: hereda de corporativo_base
    ├── css/
    │   └── overrides.css
    └── sitio_barcelona.info.yml

Cada subtema hereda toda la funcionalidad del tema base y solo sobreescribe las variables de diseño permitidas: paleta de colores secundaria, logo, favicon, y en casos justificados, algún template específico. El tema base se gestiona como un componente versionado dentro del repositorio.

Design tokens y restricciones de marca

La implementación de Design Tokens en CSS Custom Properties permite que el equipo de marca defina qué es configurable por sitio y qué no. Por ejemplo:

• Inmutable por sitio: tipografía principal, grid base, tamaños de componentes, iconografía corporativa.
• Configurable por sitio: color primario, color secundario, logo, imágenes hero de portada.

El módulo Domain Config permite configurar qué tema se activa en cada dominio, de forma que la asignación de subtema se gestiona desde la administración sin intervención técnica. Ahora la parte incómoda: si no defines bien estas restricciones desde el día uno, cada sitio acabará derivando visualmente hasta que tu ecosistema parezca un Frankenstein.

Components y Single Directory Components (SDC)

Drupal 10+ introduce los Single Directory Components, que permiten encapsular componentes reutilizables con su template, estilos y lógica en un único directorio. Para un multisite corporativo, esto significa que el equipo central desarrolla los componentes una vez, y cada sitio los consume con las variaciones de estilo que permitan los tokens. La consistencia está garantizada por diseño arquitectónico, no por disciplina manual. Eso es lo bonito del modelo.

Roles, permisos y gobernanza editorial entre sitios

La gestión de usuarios en un entorno multisite requiere un modelo de permisos que contemple dos dimensiones: la funcional (qué puede hacer un usuario) y la de dominio (en qué sitios puede hacerlo).

Modelo de roles recomendado

Rol	Alcance	Capacidades
Administrador global	Todos los dominios	Configuración de módulos, gestión de dominios, asignación de roles
Editor corporativo	Todos los dominios	Crear/editar contenido corporativo, promover contenido entre sitios
Responsable de sitio	Un dominio específico	Gestión editorial completa dentro de su dominio
Editor local	Un dominio específico	Crear/editar contenido dentro de su dominio
Revisor	Un dominio o todos	Aprobar/rechazar contenido según workflow

El módulo Domain Access proporciona la capa de restricción por dominio sobre los roles nativos de Drupal. Combinado con Workflows (contenido modular de Drupal core) y Content Moderation, se establecen flujos de aprobación que pueden variar por sitio o ser corporativos.

Integración con directorio corporativo

Para organizaciones con Active Directory o Azure AD, el módulo LDAP o la integración vía SAML (SimpleSAMLphp) permiten que la autenticación y los grupos del directorio corporativo se mapeen automáticamente a roles de Drupal. Un usuario que pertenece al grupo "Marketing Barcelona" recibe automáticamente el rol de editor local en el dominio correspondiente. Así de directo.

Auditoría y compliance

El módulo Audit Log registra todas las acciones editoriales con detalle de usuario, timestamp, dominio y cambio realizado. Para organizaciones sujetas a regulación (sector financiero, sanitario, administración pública), este registro es esencial para demostrar compliance en la gestión de contenidos publicados. No es opcional, es un must.

Rendimiento a escala: infraestructura y optimización para multisite

Un multisite corporativo con tráfico agregado significativo requiere una estrategia de rendimiento específica. Va más allá de los mecanismos estándar de caché de Drupal. Te explico las capas.

Capa de caché

• Varnish o CDN (Cloudflare, Fastly) como primera línea de caché, configurado para gestionar múltiples dominios con purga selectiva por dominio.
• Internal Page Cache + Dynamic Page Cache de Drupal core, con cache tags que permiten invalidación granular sin afectar a otros dominios.
• Redis o Memcached para caché de objetos y sesiones, compartido entre todos los sitios de la instalación.
• BigPipe para servir la estructura de la página inmediatamente y cargar bloques personalizados de forma asíncrona.

Hosting especializado para Drupal multisite

Las plataformas de hosting especializadas en Drupal ofrecen ventajas operativas significativas para multisite:

Acquia Cloud Platform: soporte nativo para Domain Access y multisite, con entornos de staging por sitio, CDN integrada y herramientas de monitorización. La función Acquia Site Factory está diseñada específicamente para gestionar decenas o cientos de sitios desde un mismo codebase.

Platform.sh: infraestructura como código con soporte para múltiples aplicaciones en un mismo proyecto. Cada pull request genera un entorno de preview completo con todos los dominios, lo que facilita el QA en multisite.

Pantheon: con su arquitectura de upstreams, permite propagar cambios de código desde un repositorio central a múltiples sitios. Su CDN global y la capa de caché avanzada están optimizadas para alto tráfico distribuido.

Para organizaciones que prefieren infraestructura propia, un cluster de Kubernetes con Drupal containerizado permite escalar horizontalmente los pods de PHP y gestionar los múltiples dominios mediante Ingress controllers.

Base de datos y almacenamiento

Con Domain Access (instalación única), la base de datos crece proporcionalmente al contenido total del ecosistema. Mis recomendaciones:

• MySQL 8 o MariaDB 10.6+ con replicas de lectura para distribuir queries de consulta.
• Almacenamiento de ficheros en object storage (S3, MinIO) compartido entre todos los frontends.
• Solr o Elasticsearch para búsquedas transversales rápidas sin impactar la base de datos.

De sitios dispersos a multisite unificado: estrategia de migración

La migración hacia un multisite centralizado es un proyecto en sí mismo. Requiere planificación rigurosa. La experiencia con grupos empresariales españoles me ha enseñado que el enfoque por fases es el único que funciona de verdad.

Fase 1: Auditoría y mapeo (4-6 semanas)

• Inventario de todos los sitios existentes: tecnología, volumen de contenido, integraciones, tráfico.
• Identificación de contenidos compartibles vs. específicos de sitio.
• Mapeo de roles actuales al modelo de permisos unificado.
• Definición del Design System corporativo y las variables por sitio.
• Selección de la arquitectura multisite (Domain Access vs. multisite nativo vs. híbrido).

Fase 2: Construcción del núcleo (8-12 semanas)

• Implementación de la instalación Drupal base con Domain Access configurado.
• Desarrollo del tema base corporativo y los primeros subtemas.
• Configuración de roles, workflows y políticas de contenido.
• Integración con directorio corporativo y SSO.
• Setup de la infraestructura de hosting con CI/CD.

Fase 3: Migración incremental (2-4 semanas por sitio)

• Migración de contenidos usando el sistema de migraciones de Drupal (Migrate API).
• Mapeo de URLs antiguas con redirects 301 para preservar SEO.
• Migración de usuarios y asignación a dominios.
• QA por sitio con validación de stakeholders locales.
• Cutover con periodo de monitorización intensiva.

Fase 4: Optimización y gobernanza (continuo)

• Documentación de procesos editoriales por rol.
• Formación a equipos locales.
• Establecimiento de comité de gobernanza digital que revise periódicamente el ecosistema.
• Monitorización de rendimiento y planes de capacidad.

Gestión de URLs y SEO en la migración

Ahora la parte que muchos subestiman. Un punto crítico en cualquier migración multisite es la preservación del posicionamiento orgánico. Cada sitio migrado requiere:

• Mapeo completo de URLs antiguas a nuevas con el módulo Redirect.
• Implementación de hreflang si hay versiones en múltiples idiomas.
• Verificación de sitemaps por dominio con el módulo Simple Sitemap.
• Monitorización en Search Console de cada propiedad durante los 3 meses posteriores al cutover.
• Canonicals correctos para evitar contenido duplicado entre dominios que comparten nodos.

Si te saltas esto, vas a perder tráfico orgánico. Te lo digo por experiencia.

Gobernanza a largo plazo: mantener el ecosistema sano

Un multisite corporativo sin gobernanza degenera rápidamente. Módulos que se activan en un sitio y no en otros, contenido huérfano, temas que divergen del Design System... Lo he visto pasar demasiadas veces. La gobernanza técnica requiere compromiso continuo:

Actualización centralizada: un pipeline CI/CD que ejecute tests en todos los dominios antes de desplegar cualquier cambio de código. Herramientas como PHPStan, Drupal Check y tests funcionales con PHPUnit o Cypress garantizan que un cambio en el tema base no rompe ningún subtema.

Revisión periódica de módulos: inventario trimestral de módulos contribuidos, verificación de estado de mantenimiento, y plan de sustitución para módulos abandonados.

Monitorización unificada: dashboards que muestren métricas de rendimiento, errores y uso por dominio. Herramientas como New Relic, Datadog o la combinación de Prometheus + Grafana proporcionan visibilidad operativa sobre todo el ecosistema.

Documentación viva: un wiki interno (o incluso un sitio Drupal adicional) que documente decisiones arquitectónicas, convenciones de naming, procesos de onboarding de nuevos sitios y guías editoriales.

Proceso de alta de nuevos sitios: cuando una nueva unidad de negocio necesita presencia web, el proceso debe estar estandarizado: solicitud formal, evaluación de si encaja en el multisite existente, provisión del subtheme, configuración del dominio, asignación de roles y formación al equipo local. Este proceso debería completarse en días, no en meses. Si tarda más, algo en tu gobernanza está fallando.

---

La construcción de un portal corporativo multisite con gestión centralizada en Drupal es un proyecto de arquitectura digital que, bien ejecutado, transforma la capacidad operativa de tu organización. Reduce costes, acelera el time-to-market de nuevos sitios, garantiza coherencia de marca y libera a los equipos locales para centrarse en lo que importa: crear contenido relevante para su audiencia.

La clave, y esto es lo que intento transmitir siempre a mis clientes, está en elegir la arquitectura correcta desde el inicio, invertir en el Design System como activo estratégico, y establecer una gobernanza que mantenga el ecosistema sano a medida que crece.

Hablemos de tu proyecto Drupal