Drupal multisite el 2026. Quan funciona, quan no, i amb què comparar-ho.

Gestionar diversos llocs web amb un sol equip i una sola plataforma sempre ha estat un problema mal resolt. Cada CMS popular ha intentat la seva variant —Multisite a WordPress, contenidors a JAMstack, tenants lògics a la majoria de SaaS— i tots tenen els seus costos amagats.

Drupal multisite és una de les solucions més antigues i alhora més sòlides. Tan antiga que algunes generacions de desenvolupadors l'han donat per morta diversos cops. Però el 2024 la decisió oficial del nucli de Drupal va deixar clar que es manté com a funcionalitat de primer nivell, i amb l'arribada de Drupal 11, Drupal CMS i Recipes (gener 2025) ha guanyat eines noves que la fan més pràctica que en cap moment anterior.

Aquesta guia repassa l'estat real de Drupal multisite el 2026: arquitectura, casos d'ús, comparació amb WordPress, alternatives modernes (Pantheon Custom Upstreams, Acquia Site Factory, contenidors), guia tècnica compacta amb Drupal 11.3 i criteris per decidir si encaixa amb el teu projecte.

Què és Drupal multisite

Drupal multisite és una característica nativa del core que permet servir múltiples llocs web independents amb una sola base de codi. Una única instal·lació de Drupal (core, mòduls i temes) executa diversos llocs; cadascun amb la seva configuració, el seu contingut i, normalment, la seva pròpia base de dades, però compartint el mateix codi font.

Drupal decideix quin lloc carregar segons el domini sol·licitat: llegeix el HTTP_Host, busca dins de sites/ la carpeta amb aquest nom, en carrega el settings.php i connecta a la base de dades corresponent.

És important entendre des del principi que existeixen dues arquitectures completament diferents per servir múltiples llocs amb una sola instal·lació de Drupal. La confusió entre les dues és la font de la majoria de males decisions arquitectòniques.

Multisite tradicional (bases de dades separades). És la funcionalitat nativa del core. Es comparteix la base de codi però cada lloc té la seva pròpia base de dades, configuració, usuaris i contingut totalment aïllats. Els llocs no comparteixen res automàticament. És el que es correspon literalment amb "multisite" a la documentació oficial.

Multidomini amb Domain (base de dades compartida). Una solució amb el mòdul contribuït Domain, que el 2026 té versions 2.x i 3.x estables compatibles amb Drupal 11. Aquí hi ha un sol lloc Drupal lògic amb una sola base de dades, però es serveix sota diversos dominis amb control sobre quin contingut apareix a cada un. Els usuaris són compartits per defecte, el contingut també tret que el limitis explícitament. Domain 3.x ha migrat a usar Config Collections del core per gestionar overrides de configuració, i ha introduït suport experimental per a path prefix, que permet que diversos "dominis" comparteixin hostname distingint-se pel primer segment de la URL.

L'elecció entre les dues és gairebé sempre la decisió més important del projecte, i no té res a veure amb preferències personals: depèn de si els llocs comparteixen contingut/usuaris (Domain) o són projectes radicalment diferents que només comparteixen infraestructura tècnica (multisite tradicional).

Quan multisite té sentit el 2026

Després d'una dècada veient implementacions multisite —algunes brillants, moltes desastroses— el patró és força clar.

Encaixa bé quan:

• Una organització publica molts llocs amb la mateixa estructura tècnica però aïllats: portals universitaris per facultat, llocs municipals per departament, sistemes de webs corporatives per filial, xarxes de mitjans amb capçaleres independents.
• Es vol un sol equip mantenint el codi però es necessita que cada lloc tingui el seu propi cicle editorial, els seus usuaris, els seus permisos i potencialment el seu propi hosting.
• Els llocs comparteixen prou similituds funcionals per justificar una base comuna, però prou diferències per no poder ser un únic lloc multilingüe.
• Es vol llançar micrositios o campanyes ràpidament amb una estructura preconfigurada.

No encaixa quan:

• Els llocs comparteixen molt contingut o usuaris i només es diferencien per branding (és el cas clàssic per a Domain, no multisite).
• Cada lloc té necessitats tècniques radicalment diferents que requereixen versions de mòduls incompatibles entre si (millor instal·lacions separades).
• L'equip no té experiència amb Composer, Drush i desplegaments controlats (multisite multiplica els problemes operatius si no es té el procés sota control).
• Es busca una solució on cada lloc pugui escalar i fallar independentment a nivell d'infraestructura (cal anar a contenidors per lloc o plataformes com Pantheon o Acquia).

Avantatges reals d'un multisite ben fet

L'argumentari habitual de "menys feina, més resultat" és cert, però els avantatges concrets mereixen una mica de precisió.

Manteniment centralitzat. Una sola actualització de core o d'un mòdul s'aplica a tots els llocs alhora. Si descobreixes que un mòdul personalitzat té un bug, el corregeixes una vegada i tots els llocs reben el patch en el següent desplegament. Per equips que han gestionat 10 instal·lacions Drupal separades, l'estalvi és substancial. Per equips que en gestionen 50 o 100, és la diferència entre viable i inviable.

Costos d'infraestructura més baixos. Un sol servidor pot allotjar desenes de llocs perquè comparteixen codi i, segons la configuració, també recursos de PHP, OPcache i caches. Comparat amb tenir N instal·lacions separades cadascuna amb la seva infraestructura, la reducció és evident. Comparat amb plataformes especialitzades tipus Acquia Site Factory, els costos també són sensiblement més baixos perquè no tens el cost de llicència ni de plataforma gestionada.

Reutilització de codi i configuració. Amb l'aparició de Recipes a Drupal 11 (gener 2025), el patró de reutilització ha millorat radicalment. Els Recipes són paquets preconfigurats de funcionalitat —tipus de contingut, vistes, blocs, permisos, mòduls— que es poden aplicar a qualsevol instal·lació de Drupal 11.2 o superior. En un multisite, pots crear un Recipe propi per a "blog corporatiu base" i aplicar-lo a tots els llocs nous d'un sol cop. Substitueixen els antics install profiles amb una sintaxi molt més neta i composable. Drupal CMS 1.0 i 2.0 es construeixen sencerament sobre Recipes.

Escalabilitat horitzontal en llançaments. Afegir un lloc nou a un multisite ben configurat és pràcticament instantani: nova base de dades buida, nova carpeta sota sites/, settings.php apuntant a la BD, instal·lació via Drush amb el perfil o Recipe escollit. Pots tenir un nou lloc funcionant en minuts.

Consistència de seguretat. Un punt subestimat: amb 50 instal·lacions separades és estadísticament gairebé impossible mantenir-les totes al dia de pegats de seguretat. Amb un multisite és impossible no fer-ho —la mateixa actualització de codi protegeix tota la flota alhora. L'avís de seguretat crític de Drupal del 20 de maig de 2026 (PSA-2026-05-18) hauria estat un malson per a qualsevol agència amb 30 llocs separats; per a un multisite, una sola actualització.

Compartició de contingut (només amb Domain). Si optes per Domain en lloc de multisite tradicional, pots tenir contingut únic publicat simultàniament a diversos dominis, amb el control fi per assignar quin node es veu a quin. És una funcionalitat que no té equivalent natiu a la majoria de CMS.

Drupal multisite vs WordPress multisite

Tots dos sistemes existeixen i resolen necessitats reals, però la filosofia és prou diferent per justificar comparar-los amb precisió.

Configuració inicial. A Drupal, activar multisite no requereix modificar el core: crees una carpeta amb el nom del domini sota sites/, hi poses un settings.php amb la connexió a la nova BD, i Drupal el detecta automàticament. A WordPress cal editar wp-config.php per definir constants específiques (WP_ALLOW_MULTISITE, després MULTISITE), tocar .htaccess, executar la instal·lació de xarxa des del panell, i decidir entre subdominis o subdirectoris en aquell moment —decisió difícil de canviar més tard.

Gestió de dominis. Drupal multisite està dissenyat per a dominis completament independents des del primer dia. WordPress multisite per defecte assumeix subdominis o subdirectoris d'un domini base; per a dominis personalitzats cal domain mapping (avui ja al core, però amb particularitats segons hosting).

Estructura de bases de dades. Drupal permet base de dades separada per lloc (l'opció habitual i recomanada) o BD compartida amb prefixos. WordPress multisite imposa una sola BD compartida amb prefix per lloc. L'aïllament de Drupal vol dir que un lloc amb molt tràfic no degrada la BD dels altres, que els backups per lloc són trivials i que un error de corrupció afecta només a un lloc, no a tota la xarxa.

Aïllament funcional. A Drupal cada lloc pot tenir mòduls activats i configuració completament diferent, fins i tot versions de tema diferents. A WordPress multisite tots els llocs comparteixen els fitxers de plugins i themes; pots desactivar-los per lloc, però els fitxers són comuns. WordPress té el concepte de "super admin de xarxa" que pot limitar l'autonomia dels admins de cada lloc; Drupal multisite no té aquesta jerarquia perquè cada lloc és essencialment independent.

Portabilitat. Treure un lloc d'un multisite Drupal és relativament senzill (es copia la carpeta, la BD i s'aïlla la instal·lació). A WordPress multisite, separar un lloc de la xarxa és complex per la forma com l'estructura de BD compartida emmagatzema les referències.

Filosofia. WordPress multisite va néixer per habilitar xarxes de blogs estil WordPress.com. Drupal multisite és una eina d'arquitectura per gestionar flotes de llocs generalment més complexos. Si el cas d'ús és "habilitar 200 blogs simples amb auto-registre", WordPress multisite pot ser perfectament adequat. Si és "una universitat amb 40 portals amb workflows editorials propis", Drupal multisite és pràcticament l'única opció open source raonable.

Configuració pràctica amb Drupal 11.3

Aquesta secció dona una passada compacta per al cas típic: vols afegir un segon lloc a una instal·lació Drupal 11 existent (gestionada amb Composer, com hauria de ser el 2026).

1. Preparació del servidor i dominis. Cada domini que servirà un lloc del multisite ha d'apuntar al mateix servidor a nivell de DNS, i el webserver (Nginx o Apache) ha de tenir un server block o virtual host que serveixi tots aquests dominis des de la mateixa arrel de Drupal. Per a desenvolupament local, l'opció recomanada el 2026 segueix sent DDEV, que té suport natiu de multisite via el flag --additional-hostnames.

2. Crear la carpeta del nou lloc. Sota web/sites/, crea una carpeta amb el nom exacte del domini:

mkdir -p web/sites/segon-domini.com/files
chmod 755 web/sites/segon-domini.com
chmod 775 web/sites/segon-domini.com/files

3. Generar el settings.php específic. Copia la plantilla i edita la connexió a la nova BD:

cp web/sites/default/default.settings.php web/sites/segon-domini.com/settings.php

Dins el nou settings.php, configura el $databases['default']['default'] apuntant a una BD buida creada prèviament. A Drupal 11 és una bona pràctica externalitzar credencials amb variables d'entorn i carregar-les amb getenv(), sobretot si treballes amb plataformes com Pantheon, Platform.sh/Upsun o Lando.

4. (Opcional) sites.php per a mapejos avançats. Drupal detecta el lloc per coincidència de nom de carpeta amb HTTP_Host. Si necessites àlies (per exemple, www.segon-domini.com i segon-domini.com apuntant al mateix lloc) o entorns staging amb dominis diferents al de producció, edita web/sites/sites.php:

$sites['www.segon-domini.com'] = 'segon-domini.com';
$sites['staging.segon-domini.com'] = 'segon-domini.com';

5. Instal·lació via Drush amb un Recipe. En lloc d'anar al navegador i seguir l'instal·lador, el 2026 el patró net és:

drush --uri=https://segon-domini.com site:install \
  --site-name="Segon Domini" \
  --account-name=admin \
  -y
drush --uri=https://segon-domini.com recipe ../recipes/blog-corporatiu-base

El segon comandament aplica un Recipe propi que tens guardat fora de web/ (per exemple a recipes/). Aquest pas és el que substitueix la configuració manual repetida lloc per lloc.

6. Gestió de mòduls i temes. Tot el que viu sota web/modules/ i web/themes/ està disponible per a tots els llocs, però cada lloc decideix què activa via la seva pròpia configuració. Si necessites un mòdul específic d'un sol lloc (cas rar però possible), pots posar-lo sota web/sites/segon-domini.com/modules/.

7. Workflow d'actualització. Els updates de codi els fas un cop:

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

Els updates de BD els executes per cada lloc:

drush --uri=https://primer-domini.com updb -y
drush --uri=https://segon-domini.com updb -y

Per a flotes grans val la pena envolcallar aquest pas amb un script o amb Drush aliases.

Alternatives modernes al multisite "clàssic"

Drupal multisite no és l'única manera de servir múltiples llocs amb infraestructura compartida. El 2026 hi ha alternatives madures que cal conèixer abans de decidir.

Pantheon Custom Upstreams. Pantheon permet definir un repositori "upstream" que serveix de base per a N llocs Drupal independents. Cada lloc té la seva pròpia instal·lació, però comparteixen la mateixa base de codi mantinguda en un sol lloc. Els canvis a l'upstream es propaguen a tots els llocs amb un clic. És semblant en filosofia al multisite, però amb cada lloc en infraestructura separada (BD pròpia, instàncies PHP pròpies, escalat independent). Bona opció per a agencies amb molts clients que comparteixen tecnologia però no infraestructura.

Acquia Site Factory. La solució empresarial pura: una plataforma SaaS específicament dissenyada per gestionar centenars o milers de llocs Drupal amb codi compartit. Té tota la maquinària de governance, deployment workflows multinivel, gestió d'usuaris global i SLA contractual. Cara, però per a organitzacions tipus gran corporació, govern o universitat amb requeriments seriosos d'auditoria, sovint és la resposta correcta. Drupal multisite "casolà" no escala bé a aquesta dimensió a nivell operatiu (no tècnic).

Container-per-site (Docker / Kubernetes). L'enfocament modern de microserveis: cada lloc viu en el seu propi contenidor amb la seva instal·lació de Drupal, la seva BD i el seu cicle de vida. Comparteixen base d'imatge Docker (que pots actualitzar de manera centralitzada), però són operativament independents. Avantatge clar: aïllament total de rendiment i fallades. Desavantatge: més consum de recursos i complexitat operativa (Kubernetes té una corba d'aprenentatge real). Bona opció quan l'aïllament és més important que l'eficiència de recursos, o quan els llocs tenen patrons de càrrega molt diferents.

Drupal CMS amb Recipes. Per a casos on cada lloc pot ser una instal·lació separada però volem uniformitat funcional, Drupal CMS 2.0 (octubre 2025) i el seu ecosistema de Recipes és una alternativa lleugera al multisite. Defineixes la teva "stack" en un Recipe propi i aplicar-lo a cada lloc nou és qüestió d'un comandament Drush.

La pregunta no és "què és millor". És què encaixa amb el teu cas concret. Multisite tradicional és imbatible en eficiència de recursos i centralització de manteniment. Container-per-site és imbatible en aïllament. Plataformes gestionades són imbatibles en operacions a escala empresarial. Pantheon Upstreams és un terme mig elegant.

SEO en un entorn multisite

La part SEO és més senzilla del que sembla, perquè cada lloc d'un multisite Drupal és, a tots els efectes pràctics, un lloc independent per a Google. Però hi ha cinc punts que cal vigilar.

Dominis vs subdominis vs subrutes. Per a llocs que han de construir autoritat independent (marques diferents, mercats diferents), dominis separats. Per a llocs que comparteixen marca i autoritat (mateixa empresa, idiomes o regions diferents), subdominis o subrutes. Drupal multisite gestiona perfectament dominis i subdominis; subrutes és tècnicament possible però complicat, i la solució natural amb subrutes sol ser un sol lloc Drupal multilingüe (no un multisite). Domain 3.x ha afegit suport experimental de path prefix que canvia una mica això, però amb prudència.

Contingut duplicat. Si fas servir Domain per compartir contingut entre dominis, hauràs de configurar canonical tags amb el mòdul Metatag apuntant a la versió principal. A multisite tradicional el contingut viu en bases de dades diferents, així que el risc de duplicat només existeix si físicament copies contingut entre llocs, cosa rara.

Sitemaps i robots.txt independents. Cada lloc ha de tenir el seu sitemap.xml i el seu robots.txt. El mòdul Simple XML Sitemap funciona de manera natural amb multisite —cada lloc en genera el seu sense interferir amb els altres. Robots és part del codi base i s'aplica a tots, però sovint es vol diferenciar (per exemple, evitar indexació de llocs interns); per això hi ha el mòdul RobotsTxt que en permet versió per lloc.

Hreflang. Si els llocs corresponen a idiomes/regions de la mateixa organització, configura hreflang adequadament amb Metatag o Hreflang Multilingual. Multisite no automatitza aquesta relació perquè els llocs són independents; cal definir-la explícitament. Una alternativa més neta per a casos clarament multilingües és un sol lloc Drupal amb la traducció nativa del core.

Rendiment compartit. Una optimització a nivell de codi (caches, CDN, lazy loading d'imatges, format AVIF/WebP) es propaga a tots els llocs alhora. Això és un avantatge directe de SEO tècnic: tots els llocs es beneficien de cada millora de Core Web Vitals que apliques.

Decisió: tres preguntes per descartar opcions ràpidament

Si has llegit fins aquí i encara dubtes entre Drupal multisite, Domain, instàncies separades o plataformes especialitzades, aquestes tres preguntes resolen la majoria de casos.

1. Els llocs comparteixen contingut o usuaris?

• Sí, sovint → Domain.
• No, mai → multisite tradicional o instàncies separades.

2. Quants llocs preveus mantenir simultàniament?

• Fins a uns 15-20, amb el mateix equip → multisite tradicional és ideal.
• 20-100, amb requeriments d'aïllament → Pantheon Custom Upstreams o container-per-site.
• 100+ amb governance empresarial → Acquia Site Factory o equivalent.

3. Necessites que els llocs escalin i fallin independentment?

• Sí → container-per-site, Pantheon o Acquia.
• No, tots tenen patrons de càrrega similars → multisite tradicional.

Aquestes tres preguntes fan caure el 90% dels casos. La resta són matisos d'equip, pressupost i governance que no es resolen llegint un article.

El que cal recordar

Drupal multisite el 2026 no és una solució antiga que sobreviu per inèrcia. És una eina madura, suportada oficialment, ben mantinguda i compatible amb les novetats més importants de l'ecosistema (Recipes, Drupal CMS, Drupal 11). Per a equips tècnics amb experiència en Drupal que han de servir desenes de llocs amb una mateixa base tecnològica, segueix sent una de les solucions més eficients i sòlides del panorama open source.

El que ha canviat és el context. Avui multisite competeix no només amb instal·lacions separades, sinó també amb plataformes especialitzades, contenidors orquestrats i workflows basats en Recipes. La decisió ja no és "multisite o no"; és quin patró multitenant encaixa amb el teu equip, escala i pressupost. I per a una bona part dels casos, la resposta segueix sent multisite, ara potenciat amb les eines noves que la versió 11 i el Drupal CMS han aportat.