Wagtail oder Django CMS? Der ehrliche Vergleich für Python-Projekte

Wer ein Content-Management-System auf Python-Basis sucht, landet bei zwei ernstzunehmenden Kandidaten: Wagtail und Django CMS. Beide sind seit über zehn Jahren in Entwicklung, beide werden von Agenturen weltweit produktiv eingesetzt, beide setzen auf Django auf. Und beide verfolgen einen so unterschiedlichen Ansatz, dass die Wahl zwischen ihnen selten eine Geschmacksfrage ist.

Wir haben Projekte mit beiden gebaut. Dieser Artikel beschreibt den Unterschied dort, wo er sich im Alltag tatsächlich auswirkt — im Redaktionsbetrieb, bei Mehrsprachigkeit, im Headless-Einsatz und beim Aufwand für Entwicklerinnen und Entwickler.

Der grundlegende Unterschied

Alles andere folgt aus dieser einen Entscheidung:

Bei Wagtail ist eine Seite ein Python-Modell. Eine „Produktseite“ hat einen Titel, ein Bild, einen Beschreibungstext und einen strukturierten Inhaltsbereich — nicht mehr. Was nicht definiert ist, kann die Redaktion nicht anlegen. Das klingt einschränkend und ist in der Praxis der Hauptgrund, warum Wagtail-Websites nach drei Jahren noch konsistent aussehen.

Bei Django CMS ist eine Seite eine Fläche mit Platzhaltern, in die Redakteure Plugins ziehen: Text, Bild, Spalten, Akkordeon, Formular. Die Redaktion kann fast jedes Layout selbst bauen. Das ist mächtig — und der Hauptgrund, warum Django-CMS-Websites nach drei Jahren oft sehr heterogen aussehen.

Die Frage ist nicht, welches System besser ist, sondern wem ihr die Gestaltungshoheit geben wollt: der Redaktion oder dem Design.

Der Vergleich im Detail

Kriterium	Wagtail	Django CMS
Inhaltsmodell	Typisierte Seitenmodelle, StreamField	Platzhalter mit frei setzbaren Plugins
Redaktionelle Freiheit	Bewusst begrenzt	Sehr hoch
Konsistenz über Jahre	Hoch, systembedingt	Braucht Redaktionsdisziplin
Bearbeitung	Eigene Oberfläche, nicht im Frontend	Direkt auf der Seite
Mehrsprachigkeit	Über wagtail-localize, gut gelöst	Von Beginn an Kernfunktion, sehr stark
Headless / API	API eingebaut, klar strukturiert	Nachrüstbar, weniger geradlinig
Suche	Eingebaut, Elasticsearch-fähig	Über Zusatzpakete
Medienverwaltung	Sehr ausgereift	Über django-filer, solide
Einarbeitung Entwicklung	Eigene Konzepte, 1–2 Wochen	Näher an klassischem Django
Einarbeitung Redaktion	Schnell, weil weniger möglich ist	Länger, weil mehr möglich ist

StreamField — das stärkste Argument für Wagtail

Wagtails StreamField ist der Kompromiss zwischen starrer Struktur und freiem Layout. Statt eines Rich-Text-Feldes definiert man eine Liste erlaubter Blocktypen, die die Redaktion in beliebiger Reihenfolge aneinanderreihen darf:

from wagtail.blocks import CharBlock, RichTextBlock, StructBlock
from wagtail.fields import StreamField
from wagtail.images.blocks import ImageChooserBlock


class ZitatBlock(StructBlock):
    text = CharBlock(required=True)
    quelle = CharBlock(required=False)

    class Meta:
        template = "blocks/zitat.html"


class ArtikelSeite(Page):
    inhalt = StreamField([
        ("absatz", RichTextBlock(features=["bold", "italic", "link"])),
        ("bild", ImageChooserBlock()),
        ("zitat", ZitatBlock()),
    ], use_json_field=True)

Zwei Dinge daran sind praktisch wichtig. Erstens die Einschränkung im Rich Text: features=["bold", "italic", "link"] verhindert, dass jemand Überschriften oder Schriftgrößen setzt und damit die Typografie unterläuft. Zweitens ist der Inhalt strukturiert gespeichert — er lässt sich als JSON über die API ausliefern, in einer App darstellen oder auswerten. Bei einem Rich-Text-Feld voller HTML ist beides deutlich mühsamer.

Mehrsprachigkeit — das stärkste Argument für Django CMS

Django CMS wurde von Anfang an mehrsprachig gedacht. Jede Seite existiert in mehreren Sprachversionen, der Seitenbaum kann sich je Sprache unterscheiden, und die Redaktion wechselt im selben Arbeitsschritt zwischen Sprachen. Für Organisationen mit vielen Sprachen und eigenständigen Länderredaktionen ist das nach wie vor der bequemere Weg.

Wagtail löst das über wagtail-localize und macht das inzwischen ordentlich, inklusive Übersetzungsworkflow und Export für externe Übersetzungsdienste. Es fühlt sich aber weiterhin wie eine gute Erweiterung an, nicht wie ein Kernkonzept.

Headless einsetzen

Wenn Inhalte nicht nur auf einer Website, sondern auch in einer App oder auf Partnerseiten erscheinen sollen, ist Wagtail die geradlinigere Wahl. Die API ist eingebaut, und weil Inhalte typisiert sind, hat die Ausgabe eine verlässliche Struktur. Ein StreamField wird zu einer sauberen Liste aus Blöcken mit Typ und Daten — genau das, was ein Frontend braucht.

Bei Django CMS ist Headless nachrüstbar, aber der Ansatz arbeitet dagegen: Inhalte sind an Platzhalter und Layout gebunden, und was frei platzierbar ist, lässt sich schwer in eine stabile API-Struktur überführen. Für rein serverseitig gerenderte Websites ist das kein Nachteil — für Mehrkanalbetrieb schon.

Wann keines von beiden passt

Beide Systeme sind Frameworks mit CMS-Charakter, keine schlüsselfertigen Websites. Das lohnt sich nicht immer:

• Reine Marketing-Website ohne Sonderanforderungen. Wenn es um Seiten, Blog und Formular geht und kein Python-Backend dahintersteht, ist ein etabliertes Standard-CMS schneller und günstiger.
• Kein Python im Haus. Beide Systeme brauchen für Betrieb und Weiterentwicklung Django-Kenntnisse. Ohne die kauft ihr euch eine dauerhafte Abhängigkeit ein.
• Inhalte sind Nebensache. Wenn die Anwendung im Kern eine Fachanwendung ist und nur ein paar statische Seiten braucht, reichen Django-Templates. Ein CMS fügt dann nur Komplexität hinzu.

Umgekehrt gilt: Sobald eine Website mit einer Python-Anwendung verschmilzt — Kundendaten, Berechnungen, Anmeldebereiche, Schnittstellen — ist ein Django-basiertes CMS klar im Vorteil. Inhalte und Fachlogik liegen im selben Projekt, ohne Brücke zwischen zwei Systemen.

Unsere Entscheidungsregel

Wenn …	dann
Inhalte strukturiert und über Jahre konsistent sein sollen	Wagtail
Inhalte auch in App oder API gebraucht werden	Wagtail
Die Redaktion Layouts selbst bauen können soll	Django CMS
Viele Sprachen mit eigenständigen Redaktionen	Django CMS
Große Mediensammlung und eingebaute Suche wichtig	Wagtail
Redaktion soll direkt auf der Seite bearbeiten	Django CMS

In der Praxis fällt die Entscheidung häufiger für Wagtail — nicht weil es besser wäre, sondern weil der Wunsch nach maximaler redaktioneller Freiheit im Gespräch oft lauter ist, als er sich später im Alltag bewährt. Redaktionen, die alles dürfen, bauen mit der Zeit Seiten, die niemand mehr pflegen will.

Wechsel zwischen den beiden

Eine Migration von Django CMS zu Wagtail oder umgekehrt ist möglich, aber kein Skriptlauf. Der Aufwand liegt nicht in den Texten, sondern in der Übersetzung des Inhaltsmodells: Aus frei platzierten Plugins müssen typisierte Seiten werden, und diese Zuordnung ist redaktionelle Arbeit, keine technische.

Realistisch sind bei einer mittelgroßen Website vier bis zehn Wochen, abhängig von der Zahl der Seitentypen und davon, wie sehr die bestehenden Inhalte einer Struktur folgen. Die gute Nachricht: Weil beide auf Django aufsetzen, bleibt alles außerhalb des CMS — Datenmodell, Schnittstellen, Fachlogik — unverändert.

Fazit

Wagtail und Django CMS lösen dieselbe Aufgabe mit gegensätzlichen Überzeugungen. Wagtail schützt die Konsistenz einer Website, indem es der Redaktion Grenzen setzt. Django CMS maximiert die Freiheit der Redaktion und überlässt die Konsistenz der Disziplin.

Wer strukturierte Inhalte, Mehrkanalbetrieb und langfristige Konsistenz braucht, ist mit Wagtail besser bedient. Wer viele Sprachen, eigenständige Länderredaktionen und Bearbeitung direkt auf der Seite braucht, mit Django CMS.

Wichtiger als beides: Die Entscheidung sollte nach einem Gespräch mit den Menschen fallen, die täglich damit arbeiten werden — nicht in einer Architekturrunde ohne sie.