Multisite-Lösungen mit Drupal: das Domain-Modul und Sites im Vergleich
Warum nicht einfach immer das Modul "Domain Access"? Wir vergleichen Sites und das weithin genutzte "Domain"-Modul als Multisite-Lösungen in Drupal: Stärken, Grenzen und wann welcher Ansatz passt.
Wenn aus einer einzelnen Website eine Website-Familie wird
Die meisten Organisationen fangen mit einer Website an. Dann kommen Kampagnenseiten, Länderseiten und eigene Auftritte für Marken oder Tochtergesellschaften dazu. Für solche Netze aus Websites haben wir die Sites-Modulsuite entwickelt, mit der sich Drupal-Multisites zentral steuern lassen.
In Gesprächen hören wir manchmal folgende Frage: Warum nicht einfach Domain Access? Das Modul ist seit Jahren der bekannteste Weg zu Multidomain in Drupal, und die Frage ist berechtigt.
Die Antwort passt nicht in einen Satz, und sie lautet auch nicht immer „Sites“. In diesem Beitrag vergleichen wir beide Ansätze detailliert miteinander und sagen, wann welcher besser passt.
Das Grundprinzip: Websites als Inhalt
Sites macht aus einer Drupal-Installation ein Multisite-System, das beliebig viele Websites ausspielen kann. Es gibt nur eine Codebasis, eine Datenbank, und für Wartung und Weiterentwicklung muss nur ein System gepflegt werden. Ein zentraler Verwaltungsbereich steuert alle Auftritte, und jeder Auftritt antwortet auf seiner eigenen Adresse.
Diese Adresse kann ein eigener Hostname sein, etwa eine Marken- oder Länderdomain. Sie kann aber auch ein Pfad unter einer Hauptdomain sein, etwa als Microsites für Kampagnen. Eine solche Unter-Site übernimmt die Einstellungen ihrer Hauptsite und ändert nur, was sie wirklich braucht.
Der wichtigste Unterschied zum Ansatz von Domain Access steckt im Fundament: Bei Sites sind Websites Inhalt, keine Konfiguration. Wer im Team die Rolle Site-Manager hat, legt einen neuen Auftritt im laufenden Betrieb an. Dies erfolgt direkt der Backend-Oberfläche und ohne Zutun eines Entwicklers. Auch ein extra Deployment ist dafür nicht erforderlich.
Was eine Site konkret kann, lässt sich im Vorfeld über so genannte Site-Types definieren. Diese dienen als Blaupausen dafür, welche Einstellungen ein Auftritt hat, welche Inhaltstypen er nutzen darf und welche Rollen dort vergeben werden können.
Sites: gebaut für die Menschen, die damit arbeiten
Andere Multisite-Werkzeuge setzen eine Multisite-Ebene auf Drupal und lassen die Verwaltung, wie sie war. Das bedeutet mitunter Herausforderungen und erheblichen Lernaufwand für die korrekte Bedienung: Redakteurinnen und Redakteure müssen sich z.B. merken, auf welcher Website sie gerade arbeiten. Die Einstellungen aller Auftritte landen auf einer komplexen Konfigurations-Seite. Es gibt keine individuellen Berechtigungen für eine bestimmte Site-Instanz usw.
Ein großes Ziel bei der Entwicklung von Sites war es daher, die Backend-UX für die Administration der Multisite-Funktionalität deutlich einfacher und intuitiver zu gestalten. Es sollte sich mehr nach den gewohnten UX-Konzepten Drupals anfühlen, etwa bei der Pflege von Menüs pro Seiten oder bei der Administration von site-spezifischen Rollen.
Obwohl also ein sites-basiertes Multisite-Drupal ein System mit nur einer Codebase und einer Datenbank ist, kann es sich durch eine klare logische Gliederung ganz nach Bedarf entweder wie viele Einzelseiten anfühlen, die man dediziert pflegt - oder wie ein großer einheitlicher Content-Hub, der zentral administriert wird... oder einfach beides gleichzeitig.
Dahinter steht eine einfache Regel: Der zentrale Verwaltungsbereich ist für die ganze "Flotte" an Sites da. In diesem Bereich - wir nennen ihn "Sites Hub" - können Site Manager über ein übersichtliches Dashboard die vorhandenen Site-Instanzen verwalten und neue anlegen. Zudem können im Hub z.B. Redakteure mit globalen Berechtigungen die Inhalter aller Sites zentralisiert verwalten. Eine neue Site anzulegen ist in wenigen Minuten erledigt: nur ein kleiner Dialog mit Name, Adresse und Site-Typ muss hierzu ausgefüllt werden. Eine Checkliste zeigt vor dem Go-live einer neuen Site-Instanz an, was noch fehlt. Und weil es so schnell und einfach ist, neue Site-Instanzen anzulegen, sind neue Instanzen initial redaktionell unveröffentlicht, damit sie vor Produktiv-Schaltung erst einem Vollständigkeits-Check unterzogen werden können. Auch hier soll sich die Pflege anfühlen wie bei normaler Content-Administration.
Gleichzeitig kann aber auch jede Site-Instanz für sich verwaltet werden - etwa durch einen lokalen Administrator oder einen Regionalredakteur. Diese kümmern sich dann nur um die Betreuung der Inhalte einer bestimmten Site-Instanz. Sie müssen dafür nie auf den Hub gehen, sondern können sich direkt unter der URL ihrer Site-Instanz authentifizieren und dann dort arbeiten.
Sites und das Domain-Modul im Vergleich
Wer in Drupal an Multidomain oder Multisite denkt, denkt meist an Domain Access. Das Modul gibt es seit 2006, es ist ausgereift, aktiv gepflegt und in über 11.000 Installationen im Einsatz. Seine Kernaufgabe erledigt es gut: erkennen, auf welchem Hostnamen eine Anfrage ankommt, und festlegen, welche Inhalte dort sichtbar sind.
Seine Grenzen kommen aus demselben Fundament, das es so verlässlich macht. Die wichtigsten Unterschiede zu Sites im Überblick:
1. Grundlagen und Inhalte
Beide Module machen aus einer Drupal-Installation viele Websites. Der Unterschied liegt darin, was eine Website ausmacht: bei Domain vor allem der Hostname und die Nodes, die dort sichtbar sind. Bei Sites die Website als Ganzes, mit allen Inhalten, die zu ihr gehören.
| Funktion | Domain-Modul | Sites |
| Drupal-Version | 10.2 und neuer, 11 | 11.2 und neuer, 12 (eine Abhängigkeit steht noch aus) |
| Website über den Hostnamen | Ja, plus Aliase, Wildcards und Weiterleitungen | Ja, ein Hostname pro Site und Umgebung |
| Mehrere Hostnamen, Weiterleitung auf den Haupthost | Ja, auch mit Wildcards | Ja (aber noch keine Wildcard-Untersützung) |
| Neue Website ohne Deployment starten | Nein, Domains sind Konfiguration | Ja |
| Unter-Sites unter einem Pfad | Teilweise, experimentell und ohne Vererbung | Ja, mit Vererbung |
| Inhalte einer Website zuordnen | Teilweise. Out of the box nur Nodes, alles andere über ein Zusatzmodul | Ja, von Nodes bis Dateien |
| Nicht zugeordnete Inhalte verborgen | Teilweise, hängt am Neuaufbau der Berechtigungen | Ja, plus Bericht zum Nachsteuern |
| Derselbe Inhalt, pro Website anders | mit Zusatzmodul, Beta | Ja |
| Listen und Referenzfelder pro Website | Teilweise. Listen ja, Referenzfelder nein | Ja |
| Menüs pro Website | Teilweise, einzelne Menüpunkte per Zusatzmodul | Ja |
| Suchergebnisse pro Website | mit Zusatzmodul | Ja |
2. Einstellungen und Sprachen
Sobald Websites unterschiedlich aussehen und in verschiedenen Sprachen erscheinen sollen, zählt, wo diese Werte liegen. Bei Domain sind sie Konfiguration und gehen beim nächsten Deployment verloren, wenn man sie nicht eigens ausnimmt, bei Sites bleiben sie als Inhalt dort, wo das Team sie eingestellt hat.
| Funktion | Domain-Modul | Sites |
|---|---|---|
| Name, Startseite, Theme, Logo pro Website | Ja, über Domain Config | Ja |
| Einstellungen pro Umgebung (dev, stage, prod) | Teilweise, nur Hostnamen | Ja |
| Alle Websites aus einer Verwaltung einstellen | Teilweise. Stabil nur über den Host der Domain | Ja |
| Eigener Sprachumfang pro Website | Teilweise, mit Zusatzmodul im Alpha-Stadium | Ja |
| Spracherkennung pro Website | Nein | Ja, bis zu einer Domain pro Sprache |
3. Personen und Verwaltung
Je mehr Websites eine Plattform trägt, desto mehr Menschen arbeiten daran, und nicht jede Person soll überall alles dürfen. Hier zeigt sich, für wen ein Modul gebaut ist: für die Technik, die Domains einrichtet, oder für die Teams, die täglich mit ihren Websites arbeiten.
| Funktion | Domain-Modul | Sites |
|---|---|---|
| Rollen pro Website | Nein, von den Maintainern abgelehnt | Ja, auf der Access Policy API |
| Mitgliederverwaltung an Teams abgeben | Teilweise. Man kann Redaktionen Domains zuweisen | Ja, mit Schutzmechanismen |
| Zugriffsberichte | Teilweise, durch Redaktionen pro Domain | Ja, für Plattform, Site und Person |
| Redaktionen sehen nur ihre eigene Website | Nein, eine geteilte Verwaltung | Ja |
| Dashboard und Launch-Checkliste | Nein | Ja |
| Website klonen | Nein | Ja |
| Löschen mit Entscheidung über die Inhalte | Teilweise, per Drush | Ja |
| Vorschau aus der Verwaltung | Nein | Ja, plus teilbare Links |
| Drush-Befehle | Ja | Ja |
Access Policy API
Seit Drupal 10.3 enthält Drupal Core eine Schnittstelle, mit der sich Berechtigungen abhängig vom Kontext berechnen lassen, zum Beispiel pro Site. Sites nutzt sie für Rollen pro Website. Die Rechte werden pro Site und Nutzer berechnet und zwischengespeichert, ohne dass Berechtigungstabellen neu aufgebaut werden müssen.
4. SEO und Marketing
Jede Website braucht ihre eigenen Adressen, Weiterleitungen und Signale für Suchmaschinen. Mit Domain kommt das aus mehreren Zusatzmodulen in sehr unterschiedlichem Zustand, bei Sites gehört es zur Suite.
| Funktion | Domain-Modul | Sites |
|---|---|---|
| URL-Aliase und Pathauto pro Website | Zusatzmodul | Ja |
| Redirects pro Website | Zusatzmodul | Ja |
| XML-Sitemap pro Website | Zusatzmodul, Release Candidate ohne Security-Abdeckung | Ja, mit hreflang |
| robots.txt pro Website | Teilweise, über Konfiguration, ungetestet | Ja, pro Umgebung |
| Canonical- und hreflang-Tags | Teilweise | Ja, mit Metatag |
| Analytics-IDs pro Website | Teilweise, über Domain Config | Ja, pro Umgebung |
| Passwortschutz pro Website | Teilweise, über einen Wartungsmodus | Ja, pro Umgebung |
Zwischenfazit
Vieles aus den genannten Themenbereichen 1 bis 4 lässt sich auch mit Domain nachbauen. Für ein vergleichbares Setup braucht es aber rund zehn Zusatzprojekte, mit unterschiedlichen Maintainern und teils im Alpha- oder Beta-Stadium. Jedes davon will aktualisiert und nach Upgrades getestet werden. Das bedeuet mehr Abhängigkeiten und ein höheres Risiko für Seiteneffekte in der langfristigen Wartung.
Bei Sites greifen Kernmodul und die gewählten Satelliten eng ineinander, auf demselben Datenmodell und in derselben Verwaltung. Das macht den Unterschied somit zwar selten am ersten Tag spürbar, dafür aber durchaus im langfristigen Betrieb.
Wann für das Domain-Modul entscheiden?
Nicht immer muss Sites unbedingt die bessere Lösung sein. Hier sind einige Szenarien aufgeführt, bei denen Domain sinnvoller oder der wirtschaftlich effizientere Weg sein kann.
| Ihre Ausgangslage | Was sollte genutzt werden? |
|---|---|
| Es geht nur darum, denselben Inhalt auf einigen Domains zu zeigen, ohne eigene Verwaltung, Rollen oder Varianten. | Domain-Modul oder Sites |
| Hostnamen brauchen Wildcard-Aliase. | Domain-Modul |
| Eine bestehende Domain-Installation erfüllt ihren Zweck bereits. Ein Umbau ist nicht wirtschaftlich. | Domain-Modul |
| Die „Websites“ sind eigentlich Communities: Menschen treten bei, und ihre Mitgliedschaft entscheidet, was sie sehen. | Group-Modul |
| Websites dürfen aus rechtlichen oder Sicherheitsgründen keine gemeinsame Datenbank haben. | Multisite aus Drupal Core |
| Neue Auftritte sollen ohne Entwicklungsprojekt entstehen, mit eigenen Rechten, Inhalten und Einstellungen je Website. | Sites |
Wo Sites heute steht
Sites liegt als Version 1.0.0-beta1 auf drupal.org, veröffentlicht am 22. August 2026, für Drupal 11.2 und Drupal 12. Die Suite steht wie Drupal selbst unter der GPL. Jede Agentur kann sie also betreiben, weiterentwickeln und übernehmen. Rund 350 automatisierte Testklassen sichern den Funktionsumfang ab.
Die Architektur trägt bereits mehrere unserer Plattformen im Produktivbetrieb, darunter die globale Webseiten-Familie der Conductix-Wampfler GmbH mit 26 Länderseiten und den Gemeinschaftsauftritt der Verbraucherzentralen mit über 50 Sites.
Im August 2026 haben wir eine grundlegende Entscheidung umgesetzt: Frühere Versionen nutzten das Group-Modul für die Rechteverwaltung. Heute baut Sites seine Rollen direkt auf Drupal Core auf, bestehende Installationen wechseln mit einem mitgelieferten Migrationspfad.
Unsere bestehenden Plattformen ziehen wir schrittweise auf die neue Architektur nach. Wie Sites im Alltag großer Auftritte arbeitet, zeigen die Referenzen zum Marken-Relaunch von linexo und der Webseiten der WERTGARANTIE Group.
Eine neue Lösung muss wachsen und kann nicht sofort aus dem Stand auch alles, was bereits etalierte Lösungen mitunter schon mitbringen. Stand September 2026 kann Sites beispielsweise noch nicht:
- Wildcard-Aliase für Hostnamen,
- Einladungen per E-Mail oder Selbstregistrierung pro Site,
- einzelne Sites archivieren oder exportieren,
- beim Klonen die Rollenzuweisungen mitkopieren,
- öffentliche Dateien pro Site beschränken.
Domain hat zwanzig Jahre Vorsprung und entsprechend viele Grenzfälle gesehen. Diesen Vorsprung holt man nicht in einem Release auf. Man holt ihn mit jedem Projekt auf, in dem die Suite im Alltag bestehen muss.
Auf der anderen Seite kann Sites eben auch schon sehr viel, was Domain nicht oder nur über Umwege möglich macht. Letzten Endes sind beide Ansätze valide und überzeugende Lösungen, um ein professionelles Multisite-Setup mit Drupal zu betreiben.
Domain ist als Multisite-Lösung bewährt und ausgereift. Sites ist neu und innovativ. Welche Lösung für Sie die beste ist, besprechen wir gerne mit Ihnen.
Fazit: die richtige Frage zuerst
Die Entscheidung zwischen Sites und dem Domain-Modul ist selten eine Geschmacksfrage. Sie hängt daran, wie Ihr Netz aus Websites wachsen soll. Bleibt die Zahl der Domains stabil und geht es vor allem um die Sichtbarkeit von Inhalten, ist Domain eine solide Wahl.
Sollen neue Auftritte ohne Entwicklungsprojekt entstehen, sollen Teams je Website eigene Rechte bekommen, und sollen Inhalte, Menüs, Sprachen und Einstellungen gemeinsam je Site gesteuert werden? Dann spielt Sites seine Stärken aus.
Sie planen eine Multisite- oder Multidomain-Plattform mit Drupal, oder Ihre bestehende Lösung stößt an Grenzen? Sprechen Sie uns an. Wir schauen gemeinsam, welcher Ansatz zu Ihrem Vorhaben passt, auch wenn die Antwort am Ende nicht Sites heißt.
Weiterlesen: Sites auf drupal.org | Drupal Multisite bei erdfisch
Pascal Crott
