Die Systemwahl ist die teuerste Entscheidung eines Webprojekts, weil sie am längsten wirkt. Ein Design lässt sich überarbeiten, ein Text neu schreiben, ein Hoster wechseln. Das System entscheidet darüber, wer die Seite pflegen kann, was sie im Monat kostet und wie schmerzhaft der nächste Umzug wird.
Die Marketingfrage “welches ist das beste System” hat keine Antwort. Die brauchbare Frage lautet: welches System passt zu diesem Projekt, dieser Pflegekapazität und diesem Zeithorizont?
Die vier Systemfamilien
Baukästen (Website-Builder) liefern Hosting, Vorlagen, Editor, SSL und Updates in einem Abo. Man arbeitet visuell im Browser, kommt in Stunden zu einem Ergebnis und muss sich um Technik nie kümmern. Der Preis ist Gestaltungsgrenze und Lock-in: Was der Anbieter nicht vorsieht, geht nicht, und mitnehmen kann man später fast nichts.
Klassische CMS wie WordPress, Joomla oder TYPO3 trennen Inhalte, Vorlagen und Funktionen. Man betreibt sie auf eigenem Hosting, hat sehr viel Freiheit und trägt dafür die Verantwortung für Updates, Backups und Sicherheit. Die Inhalte liegen in einer Datenbank und lassen sich exportieren.
Statische Generatoren wie Astro, Hugo oder Eleventy erzeugen aus Inhaltsdateien und Vorlagen fertiges HTML. Es gibt keine Datenbank und zur Laufzeit keinen Code, der angegriffen werden könnte. Das Ergebnis ist extrem schnell und praktisch kostenlos zu hosten. Die Hürde liegt in der Redaktion: Wer Inhalte pflegen soll, braucht entweder technisches Verständnis oder ein zusätzliches Redaktionssystem.
Headless-CMS setzen genau das obendrauf: eine komfortable Redaktionsoberfläche, die Inhalte per Schnittstelle an einen beliebigen Frontend-Build liefert. Damit lässt sich die Geschwindigkeit eines statischen Builds mit einer bedienbaren Redaktion verbinden, zum Preis von zwei Systemen statt einem.
Entscheidungsmatrix
| Anforderung | Baukasten | Klassisches CMS | Statisch | Headless |
|---|---|---|---|---|
| Live in Tagen | ja | bedingt | bedingt | nein |
| Ohne Technikwissen pflegbar | ja | ja | nein | ja |
| Sehr schnelle Ladezeit | bedingt | mit Arbeit | von Haus aus | von Haus aus |
| Wartungsaufwand | keiner | dauerhaft | minimal | gering |
| Gestaltungsfreiheit | begrenzt | hoch | vollständig | vollständig |
| Umzug später möglich | kaum | ja | ja | ja |
| Sinnvoll ab | 1 Seite | 10 Seiten | 5 Seiten | 50 Seiten |
| Laufende Kosten | 10 bis 30 Euro | 5 bis 25 Euro | 0 bis 10 Euro | 0 bis 100 Euro |
Die Zeile “sinnvoll ab” ist keine Grenze, sondern ein Hinweis auf das Verhältnis von Aufwand und Nutzen. Ein CMS für drei Seiten bedeutet, ein Wartungsproblem für einen Nutzen einzukaufen, den es nicht gibt.
Die Fragen, die die Wahl tatsächlich entscheiden
Wer pflegt die Seite, und wie oft? Bei “ich selbst, zweimal im Jahr” gewinnt der Baukasten fast immer. Bei “eine Kollegin, jede Woche” braucht es eine Redaktionsoberfläche. Bei “niemand, die Inhalte sind stabil” ist ein statischer Build die wartungsärmste Lösung.
Wie viele Inhalte werden es? Bis rund zehn Seiten ist jedes System handhabbar. Ab etwa fünfzig Seiten entscheidet die Frage, wie gut sich Inhalte strukturieren, kategorisieren und wiederverwenden lassen, und da verlieren Baukästen deutlich.
Braucht es Funktionen über Inhalte hinaus? Buchung, Shop, Mitgliederbereich, Mehrsprachigkeit, Formulare mit Logik. Jede dieser Anforderungen verschiebt die Wahl. Mehrsprachigkeit ist bei Baukästen oft aufpreispflichtig und schlecht gelöst.
Wie lange soll die Seite halten? Wer in zwei Jahren neu bauen will, kann bewusst in den Lock-in gehen. Wer fünf bis zehn Jahre plant, sollte auf Exportierbarkeit achten.
Wie hoch ist die Toleranz für Wartung? Ein WordPress ohne Updates ist nach zwölf Monaten ein Sicherheitsrisiko. Wer weiß, dass er sich nicht kümmern wird, sollte kein System wählen, das Kümmern verlangt.
Wo der Lock-in am meisten kostet
Der Lock-in wird selten beim Aufbau bemerkt, sondern beim Verlassen. Konkret betroffen sind:
- Inhalte. Fehlt ein vollständiger Export, muss jede Seite manuell übertragen werden.
- URL-Struktur. Ändern sich beim Umzug alle Adressen, gehen Rankings verloren, sofern nicht jede alte Adresse per Weiterleitung auf ihr neues Ziel zeigt.
- Formulardaten und Anfragen. Liegen im System des Anbieters, oft ohne brauchbaren Export.
- Bilder. Häufig in anbietereigenen Größen und Formaten, die außerhalb nicht funktionieren.
- Domain. Wurde die Domain über den Baukasten registriert, ist der Transfer ein eigener Vorgang.
Die praktische Konsequenz: Domain immer separat registrieren, Texte und Originalbilder immer zusätzlich außerhalb des Systems ablegen. Das kostet nichts und macht jeden späteren Wechsel um ein Vielfaches billiger. Details in System wechseln.
Realistische Empfehlungen nach Ausgangslage
Handwerksbetrieb, fünf Seiten, Anfragen per Telefon: Baukasten. Alles andere ist Aufwand ohne Gegenwert.
Ferienwohnung mit Verfügbarkeitsanzeige: Baukasten mit Buchungsanbindung oder ein spezialisiertes Buchungssystem. Ein selbstgebautes CMS mit Buchungs-Plugin ist der schlechteste der drei Wege.
Praxis oder Beratung mit Fachbeiträgen: klassisches CMS, weil regelmäßige Inhalte der Zweck sind und die Redaktion bedienbar sein muss.
Kleiner Verein, wechselnde Ehrenamtliche: Baukasten. Übergaben scheitern an Systemen, die Wissen verlangen.
Portal mit vielen Unterseiten und stabilen Inhalten: statischer Build, bei mehreren Redakteuren mit Headless-CMS davor.
Shop: eigene Frage, siehe Onlineshop. Ein Shop-Plugin auf einem CMS ist eine andere Entscheidung als eine Shop-Plattform.