Eine Universität ist nie nur eine einzige Website. Sie besteht aus der zentralen institutionellen Seite sowie separaten Websites für jede Fakultät, jeden Fachbereich, jedes Forschungszentrum, jede Bibliothek und oft Dutzende einzelner Projekte, Labore und Veranstaltungen. Eine große Universität betreibt problemlos zwischen 50 und mehreren Hundert eigenständigen Websites. Die Herausforderung liegt nicht darin, eine einzelne davon zu erstellen – sie liegt darin, sie alle gemeinsam zu verwalten: sicher, markenkonform und aktuell zu halten, ohne für jede einzelne ein eigenes Team und einen eigenen Technologie-Stack zu benötigen. Genau dieses Problem soll Drupal Multisite lösen, und das ist ein wesentlicher Grund dafür, warum so viele der weltweit führenden Universitäten auf Drupal setzen.
Dieser Artikel erklärt, wie Drupal Multisite funktioniert, warum es sich so gut für den Anwendungsfall Universität eignet, wie es sich im Vergleich zu Alternativen schlägt und – ebenso wichtig – wann es die falsche Wahl ist. Ziel ist ein klares, ehrliches Bild, das einer Institution hilft zu entscheiden, ob Multisite die richtige Architektur für ihre Web-Landschaft ist.
Das Multi-Site-Problem, mit dem jede Universität konfrontiert ist
Universitäten sind von Natur aus dezentral organisiert. Jede Fakultät möchte die Kontrolle über ihre eigene Website behalten, jeder Fachbereich hat eigene Inhalte und eigene Redakteure, und die zentrale IT-Abteilung ist dafür verantwortlich, die gesamte Web-Landschaft sicher, zugänglich und einheitlich zu halten. Bleibt diese Spannung unmanaged, entsteht ein vertrautes Durcheinander: Fachbereiche richten eigenmächtig nicht genehmigte Websites auf irgendeiner beliebigen Plattform ein, die Markenkonsistenz bricht zusammen, Sicherheitspatches werden uneinheitlich oder gar nicht eingespielt, und niemand hat mehr einen vollständigen Überblick darüber, was überhaupt läuft.
Die Plattformentscheidung ist mit anderen Worten in Wirklichkeit eine getarnte Governance-Entscheidung. Die Frage, die eine Universität beantworten muss, lautet nicht nur „Welches CMS sollen wir verwenden", sondern „Wie lassen wir Dutzende Teams ihre eigenen Websites verwalten, während die zentrale IT die gesamte Landschaft sicher und kohärent hält?" Drupal Multisite ist eine der stärksten Antworten auf genau diese Frage.
Was Drupal Multisite tatsächlich ist
Drupal ist eines der wenigen Content-Management-Systeme, das Multisite nativ im Kern unterstützt. Ein Drupal-Multisite ist eine einzelne Drupal-Installation, die mehrere Websites aus einer gemeinsamen Codebasis betreibt. Das entscheidende technische Detail ist, was geteilt wird und was nicht: Die Websites teilen sich den Code – Drupal-Kern, Module und Themes –, aber jede Website hat ihre eigene, separate Datenbank. Das bedeutet, dass Inhalte, Konfiguration, Benutzer und hochgeladene Dateien pro Website vollständig getrennt sind, obwohl alle auf derselben zugrunde liegenden Installation laufen.
Technisch gesehen liegt jede Website in einem eigenen Unterverzeichnis innerhalb der Installation, mit einer eigenen Konfigurationsdatei, die auf ihre eigene Datenbank verweist. Trifft eine Anfrage ein, prüft Drupal die Domain oder URL und lädt die passende Datenbank und Konfiguration der jeweiligen Website. Das praktische Ergebnis ist eine Reihe von Websites, die wie völlig eigenständige Webauftritte aussehen und funktionieren – jede mit eigenem Branding, eigenen Inhalten und eigenem Redaktionsteam –, während sie darunter eine einzige Codebasis und einen einzigen Aktualisierungsprozess teilen. Aktualisiert man den Code einmal, läuft jede Website mit der neuen Version.
Warum Universitäten auf Multisite setzen
Das Multisite-Modell passt fast perfekt zu der Art und Weise, wie eine Universität tatsächlich arbeitet. Stanford, Yale, Harvard und Duke betreiben nach diesem Prinzip jeweils ihre eigenen großen Drupal-Plattformen, und Institutionen wie das University College London verwalten 500 oder mehr Microsites über eine einzige Governance-Ebene. Die Vorteile, die dies möglich machen, sind konkret:
- Einmal aktualisieren, überall ausrollen: Ein Sicherheitspatch oder ein Drupal-Versionsupgrade wird einmal auf die gemeinsame Codebasis angewendet und wirkt sich auf jede Website aus. Statt 200 Websites einzeln zu patchen, führt die zentrale IT ein einziges Update durch – die mit Abstand größte betriebliche Einsparung, die Multisite bietet.
- Zentrale Governance mit lokaler Autonomie: Die zentrale IT verwaltet Architektur, Sicherheit und das Designsystem, während jede Fakultät und jeder Fachbereich die volle redaktionelle Kontrolle über die eigenen Inhalte behält. Die Fachbereiche erhalten ihre Unabhängigkeit, die Institution behält ihre Kohärenz.
- Markenkonsistenz im großen Maßstab: Ein gemeinsames Designsystem und gemeinsame Komponenten sorgen dafür, dass jede Website ein konsistentes Branding und einheitliche Barrierefreiheitsstandards trägt, statt dass jede in ihre eigene Richtung abdriftet.
- Gemeinsame Entwicklung: Individuelle Funktionalität wird einmal gebaut und allen Websites zur Verfügung gestellt. Ein Modul oder eine Funktion, die für eine Fakultät entwickelt wurde, kann für andere aktiviert werden, ohne sie neu zu bauen.
- Effizientes Onboarding neuer Websites: Wenn ein neuer Fachbereich oder ein neues Programm eine Website benötigt, kann diese schnell aus der gemeinsamen Plattform bereitgestellt werden – ausgehend von derselben sicheren, zugänglichen und markenkonformen Basis, statt bei null anzufangen.
Für eine Institution, die eine große Anzahl von Websites betreibt, summieren sich diese Effizienzgewinne. Genau dieses Muster steckt hinter der Dominanz von Drupal im Hochschulwesen, und es hängt direkt mit den breiteren Stärken der Plattform in diesem Sektor zusammen, die wir in unserem Überblick zu Drupal im Bildungsbereich behandeln.
Multisite ist nicht die einzige Option
Klassisches Multisite ist eine Möglichkeit, viele Websites mit Drupal zu betreiben, aber nicht die einzige. Die Wahl der richtigen Architektur zu Beginn spart später erheblich Zeit und Kosten, daher lohnt es sich, die wichtigsten Alternativen zu kennen.
| Ansatz | Funktionsweise | Am besten geeignet für |
|---|---|---|
| Klassisches Multisite | Eine Codebasis, eine separate Datenbank pro Website. Inhalte vollständig isoliert. | Viele strukturell ähnliche Websites mit Bedarf an starker Inhaltstrennung. |
| Domain Access | Eine Codebasis und eine gemeinsame Datenbank; ein Modul steuert, welcher Inhalt zu welcher Domain gehört. | Websites, die sich viele Inhalte und Redakteure teilen und zentral verwaltet werden. |
| Separate Installationen | Jede Website ist eine eigene, unabhängige Drupal-Installation, oft verwaltet über einen gemeinsamen Composer-Workflow. | Websites, die sich deutlich unterscheiden oder vollständige Isolation und unabhängige Skalierung benötigen. |
| Distribution / Upstream | Ein standardisierter Drupal-Build wird gepackt und als Ausgangspunkt für jede neue, unabhängige Website verwendet. | Die Einführung vieler Websites aus einer gemeinsamen Basis heraus, bei gleichzeitiger Unabhängigkeit. |
Der zentrale Unterschied liegt zwischen Inhaltsisolation und Inhaltsfreigabe. Multisite gibt jeder Website ihre eigene Datenbank und die stärkste Trennung. Domain Access teilt sich eine Datenbank, was das Teilen von Inhalten und Redakteuren erleichtert, die Websites aber eng aneinander koppelt. Separate Installationen bieten das Höchstmaß an Isolation und Unabhängigkeit auf Kosten der individuellen Verwaltung jeder einzelnen Website. Die richtige Antwort hängt davon ab, ob Ihre Websites Variationen eines Themas sind, die sich etwas teilen sollten, oder tatsächlich unabhängige Bestände, die das nicht sollten.
Die ehrlichen Kompromisse: Wann Multisite die falsche Wahl ist
Multisite ist leistungsstark, aber nicht risikofrei, und eine verantwortungsvolle Bewertung muss die Nachteile ebenso ernst nehmen wie die Vorteile. Die Effizienz einer gemeinsamen Codebasis ist zugleich ihre zentrale Schwäche: Sie schafft einen Single Point of Failure.
- Gemeinsames Schicksal: Da alle Websites auf einer Codebasis laufen, wirkt sich ein Problem in dieser Codebasis auf alle Websites gleichzeitig aus. Ein Traffic-Spike auf einer Website kann die Performance aller anderen beeinträchtigen, und eine Sicherheitsverletzung ist schwerer einzudämmen – wird eine Website über den gemeinsamen Code kompromittiert, können auch die anderen gefährdet sein.
- Begrenzte Isolation: Es gibt keine starke Trennung zwischen den Websites auf Code-Ebene, was für Institutionen mit strengen Sicherheits- oder Compliance-Anforderungen eine echte Überlegung wert ist. Wo Websites vollständig isoliert sein müssen, sind separate Installationen das sicherere Modell.
- Wartungskopplung: Manche Vorgänge, etwa bestimmte Upgrades, können erfordern, dass alle Websites gemeinsam in den Wartungsmodus versetzt werden, und eine Website später aus einem Multisite herauszulösen, ist keine triviale Aufgabe.
- Divergenz im Laufe der Zeit: Wenn Websites sich in ihren Code- oder Konfigurationsanforderungen auseinanderentwickeln, kann sich der gemeinsame Upgrade-Pfad aufspalten, und die Einfachheit, die Multisite rechtfertigte, beginnt zu bröckeln.
Moderne Drupal-Workflows haben die Alternativen attraktiver gemacht, als sie es einst waren. Ein Composer-basierter Workflow zur Verwaltung separater Installationen oder eine Plattform, die isolierte Websites aus einer gemeinsamen Upstream-Basis bereitstellt, kann einen Großteil der Konsistenz von Multisite liefern, ohne das Risiko des gemeinsamen Schicksals einzugehen. Multisite bleibt eine hervorragende Wahl für eine große Zahl ähnlicher, gut verwalteter Websites – aber für Websites, die echte Isolation, unabhängige Skalierung oder erhebliche Divergenz benötigen, ist es oft das falsche Werkzeug. Die ehrliche Regel lautet: Multisite wählen, weil die eigenen Websites tatsächlich ähnlich sind und zentral verwaltet werden – nicht einfach, weil es die Anzahl der Websites zu reduzieren scheint.
Governance: Der eigentliche Grund, warum das wichtig ist
Unter der technischen Architektur kauft eine Universität mit Multisite in Wirklichkeit ein Governance-Modell. Das schwierigste Problem bei der Verwaltung von Universitätswebsites ist nicht der Bau der Websites – es ist die Koordination Dutzender autonomer Teams, ohne deren Unabhängigkeit zu ersticken oder die zentrale Kontrolle zu verlieren.
Eine gut geführte Multisite-Plattform löst diese Spannung explizit auf. Die zentrale IT besitzt die gemeinsame Ebene: die Codebasis, Sicherheitsupdates, das Designsystem, Barrierefreiheitsstandards und die Gesamtarchitektur. Fakultäten und Fachbereiche besitzen ihre Inhalte: ihre eigenen Redakteure, ihre eigenen Veröffentlichungspläne, ihre eigene, websitespezifische Struktur innerhalb des gemeinsamen Rahmens. Da Rollen und Berechtigungen zentral definiert werden, erhält jedes Team genau den Zugriff, den es benötigt – nicht mehr. Das Ergebnis ist Autonomie dort, wo sie hilft – bei den Inhalten – und Konsistenz dort, wo sie zählt – bei Sicherheit, Branding und Compliance. Dieses Gleichgewicht ist das eigentliche Produkt, und deshalb ist die Plattformwahl letztlich eine Governance-Entscheidung und keine rein technische.
Häufige Fehler bei Multisite und wie man sie vermeidet
- Multisite wählen, um die Anzahl der Websites zu reduzieren: Der richtige Grund für Multisite ist echte Ähnlichkeit und gemeinsame Governance, nicht eine kleinere Zahl auf dem Server. Wählen Sie die Architektur, die zur tatsächlichen Beziehung der Websites passt, nicht diejenige, die am aufgeräumtesten wirkt.
- Den Single Point of Failure ignorieren: Eine gemeinsame Codebasis bedeutet gemeinsames Risiko. Planen Sie dafür mit starken Sicherheitspraktiken, Performance-Reserven und einem klaren Verständnis dessen, was passiert, wenn eine Website einen schlechten Tag hat.
- Sehr unterschiedliche Websites zwangsweise zusammenfügen: Websites mit stark abweichenden Code- oder Konfigurationsanforderungen belasten das gemeinsame Modell. Ist die Divergenz real, dienen separate Installationen besser als ein erzwungenes Multisite.
- Die Ausstiegskosten unterschätzen: Eine Website später aus einem Multisite herauszulösen, ist schwierig. Planen Sie die Architektur mit Blick auf eine mögliche künftige Trennung, statt anzunehmen, dass die Websites für immer zusammenbleiben.
- Governance vernachlässigen: Die Technologie allein schafft keine Ordnung. Ohne ein klares Modell dafür, wem die gemeinsame Ebene gehört und wem der Inhalt jeder einzelnen Website gehört, gerät selbst ein gut gebautes Multisite in Unordnung.
- Websites unkontrolliert auseinanderdriften lassen: Wenn jede Website ihren eigenen, individuellen Code anhäuft, untergräbt das den Vorteil der gemeinsamen Codebasis. Halten Sie Anpassungen diszipliniert und, wo möglich, gemeinsam nutzbar.
Gut verwaltet, ermöglicht Drupal Multisite einer Universität, eine große, kohärente Web-Landschaft von einer einzigen Plattform aus zu betreiben – die zentrale IT hält alles sicher und markenkonform, während jede Fakultät und jeder Fachbereich die Kontrolle über die eigene Website behält. Es ist einer der klarsten Gründe, warum Drupal im Hochschulwesen zur Standardwahl geworden ist, und es passt natürlich zu den Stärken der Plattform bei mehrsprachigen Inhalten, Barrierefreiheit und der Integration mit akademischen Systemen.
Häufig gestellte Fragen zu Drupal Multisite
Teilen sich Multisite-Websites Inhalte untereinander?
In einem klassischen Multisite nicht. Jede Website hat ihre eigene, separate Datenbank, sodass Inhalte, Benutzer und Konfiguration isoliert sind – die Websites teilen sich lediglich den zugrunde liegenden Code. Wenn das Teilen von Inhalten über Websites hinweg eine Anforderung ist, spricht das für eine andere Architektur, wie zum Beispiel Domain Access, das eine einzige gemeinsame Datenbank verwendet und es ermöglicht, zu steuern, welcher Inhalt auf welcher Website erscheint. Die Wahl zwischen beiden hängt davon ab, ob Ihre Websites isoliert sein oder Inhalte teilen sollen.
Wie viele Websites kann ein Drupal-Multisite betreiben?
Es gibt keine feste Grenze, und große Institutionen betreiben beachtliche Zahlen – Universitäten wie das University College London verwalten 500 oder mehr Websites, und manche Implementierungen reichen in die Hunderte oder darüber hinaus. Die praktische Obergrenze wird weniger von Drupal selbst bestimmt als von der Infrastruktur, der Governance-Disziplin und davon, wie ähnlich sich die Websites sind. Je mehr Websites auf einer Codebasis laufen, desto wichtiger werden solide Betriebspraktiken und Performance-Planung, da sie alle das Schicksal dieser Codebasis teilen.
Wird Drupal Multisite abgeschafft?
Nein. Multisite ist eine geschätzte Kernfunktion und wird nicht entfernt. Es gab Diskussionen in der Community darüber, wie das Zusammenspiel mit modernen Werkzeugen wie Composer verbessert werden kann, und diese Verbesserungen sind vorangekommen, aber die Funktion selbst bleibt unterstützt. Allerdings bietet das Ökosystem inzwischen starke Alternativen – darunter über Composer verwaltete separate Installationen und plattformbasierte Upstreams –, sodass die moderne Frage weniger lautet „Ist Multisite verfügbar" als vielmehr „Ist Multisite die richtige Wahl für genau diese Web-Landschaft".
Multisite oder separate Installationen – wofür sollte sich eine Universität entscheiden?
Das hängt davon ab, wie ähnlich und wie isoliert die Websites sein müssen. Multisite eignet sich für eine große Zahl strukturell ähnlicher Websites, die sich ein Designsystem teilen und gemeinsam aktualisiert werden sollten, bei zentraler Governance – das klassische Szenario der Fachbereichs-Websites einer Universität. Separate Installationen eignen sich für Websites, die sich deutlich unterscheiden, vollständige Isolation aus Sicherheits- oder Compliance-Gründen benötigen oder unabhängig skalieren müssen. Viele Universitäten setzen für den Großteil ihrer Fachbereichs-Websites auf Multisite und für alles mit wirklich eigenständigen Anforderungen auf separate Installationen. Die Entscheidung sollte der tatsächlichen Beziehung zwischen den Websites folgen, nicht bloß einer Vorliebe für weniger bewegliche Teile.