CMS, Static Site oder Web-App: Architektur für digitale Projekte wählen

Die Wahl zwischen CMS, Static Site und Web-App ist keine reine Technologiefrage. Sie entscheidet darüber, wie Inhalte gepflegt, Daten verarbeitet, Funktionen erweitert und Änderungen im laufenden Betrieb abgesichert werden. Für Geschäftsführung, Produktverantwortliche und technische Leitung zählt deshalb nicht, welches System die meisten Funktionen verspricht, sondern welche Architektur die tatsächlichen Anforderungen mit vertretbarem Betriebsaufwand erfüllt.

Die Begriffe beschreiben außerdem nicht immer Gegensätze. Eine Website kann Inhalte in einem CMS verwalten, Seiten statisch ausliefern und einzelne Funktionen als Web-App bereitstellen. Ein Headless CMS kann mit einem statischen Frontend verbunden sein; ein CMS kann auch zum Backend eines internen Tools werden. Entscheidend ist, wo Inhalte, Daten und Geschäftslogik liegen – und wer sie kontrolliert. Dieser Beitrag liefert Kriterien, um die passende Kombination zu bestimmen und zu erkennen, wann ein Standardprodukt genügt und wann eine individuelle Lösung nötig wird.

Kurz gesagt

Wählen Sie ein CMS, wenn Menschen regelmäßig Inhalte pflegen und die redaktionelle Oberfläche wichtig ist. Eine Static Site passt, wenn Inhalte überwiegend lesend genutzt werden und dynamische Funktionen begrenzt oder separat lösbar sind. Eine Web-App ist angezeigt, wenn Nutzerkonten, individuelle Zustände, Transaktionen oder komplexe Abläufe zum Kern des Produkts gehören. Viele Projekte brauchen eine Kombination statt einer einzigen Kategorie. Entscheiden Sie anhand von Content-Modell, Interaktion, Datenverantwortung, Integrationen und Betrieb – nicht anhand eines Framework-Rankings.

Ausgangslage

Die Architekturfrage entsteht häufig, wenn ein Projekt als neue Website beginnt, aber im Laufe der Planung weitere Anforderungen sichtbar werden: Inhalte sollen in mehreren Formaten erscheinen, Daten aus externen Quellen einfließen, Nutzer sollen persönliche Ergebnisse speichern oder interne Teams sollen Abläufe über die Website steuern. Umgekehrt können bestehende Systeme Funktionen und Abhängigkeiten angesammelt haben, die für den eigentlichen Zweck nicht mehr nötig sind.

Dazu kommt, dass CMS, Static Site und Web-App keine sauber getrennten Produktklassen sind. CMS bezeichnet vor allem eine Möglichkeit, Inhalte zu verwalten. Static Site beschreibt eine Art, Seiten auszuliefern. Web-App benennt eher eine Nutzung und einen Funktionsumfang: Menschen arbeiten mit Daten und Funktionen, häufig mit persönlichem oder verändertem Zustand. Ein Projekt kann daher alle drei Eigenschaften verbinden.

Auch „Headless“ ist keine eigenständige Lösung für jede Anforderung. Es beschreibt die Trennung von Inhaltsverwaltung und Ausspielung. Diese Trennung kann sinnvoll sein, bringt aber zusätzliche Schnittstellen, Betriebsverantwortung und Koordination mit sich. Ob sie Vorteile schafft, hängt vom Bedarf an mehreren Ausgabekanälen, eigenen Frontends und kontrollierten Datenflüssen ab. Eine vertiefte Abwägung bietet Headless CMS oder klassisches CMS.

Entscheidungskriterien

Die folgenden Kriterien sollten vor der Wahl eines konkreten Systems geklärt werden. Sie helfen, Anforderungen zu priorisieren und verhindern, dass ein Framework oder ein vertrautes Tool die Architekturentscheidung vorwegnimmt.

1. Welche Inhalte werden verwaltet?

Erfassen Sie nicht nur die Zahl der Seiten, sondern die Arten von Inhalten und ihre Beziehungen. Sind es überwiegend Artikel und redaktionelle Seiten? Oder gibt es strukturierte Objekte wie Produkte, Orte, Leistungen, Profile und Datensätze, die in verschiedenen Ansichten erscheinen?

Wenn Inhalte unterschiedliche Felder, Status, Beziehungen oder Freigaben haben, muss das System diese Strukturen nachvollziehbar abbilden. Eine lose Sammlung von Seiten oder Plugins löst das nicht automatisch. Bei großen oder wiederverwendbaren Content-Beständen sollte das Datenmodell vor der Systemauswahl skizziert werden. Dazu passt der Leitfaden Content-Architektur.

2. Wie oft und von wem wird publiziert?

Klären Sie, wer Inhalte erstellt, prüft, freigibt und aktualisiert. Ein kleines Team mit seltenen Änderungen benötigt andere Abläufe als eine Redaktion mit mehreren Rollen, Entwurfsständen und laufender Veröffentlichung. Auch externe Partner oder Kunden können bestimmte Inhalte bearbeiten müssen.

Prüfen Sie, ob die vorgesehenen Nutzeroberflächen für diese Aufgaben geeignet sind. Wenn redaktionelle Mitarbeitende jede Änderung über ein Ticketsystem oder durch technische Personen anfordern müssen, ist die Architektur möglicherweise an der Arbeitsrealität vorbei geplant. Umgekehrt ist ein umfangreiches CMS nicht automatisch nötig, wenn Inhalte selten und von einem kleinen, technisch versierten Team gepflegt werden.

3. Welche Interaktion ist zentral?

Unterscheiden Sie zwischen Interaktionen, die nur eine Eingabe entgegennehmen, und Funktionen, die dauerhafte Zustände und Regeln benötigen. Ein Kontaktformular oder ein Rechner mit vorgegebenen Daten ist etwas anderes als ein persönliches Konto, ein gespeicherter Warenkorb, ein Antragsprozess oder ein mehrstufiger Workflow.

Fragen Sie für jede Funktion: Wird ein Ergebnis nur im Browser berechnet? Muss es gespeichert werden? Gibt es individuelle Berechtigungen? Ändert ein Nutzer Daten, auf die andere Nutzer oder Mitarbeitende reagieren? Je mehr eine Funktion dauerhafte Zustände, Transaktionen und rollenabhängige Abläufe umfasst, desto eher gehört sie in eine Anwendungsschicht – und nicht in eine Ansammlung von Seitenelementen.

4. Wem gehören die Daten und wie werden sie gepflegt?

Listen Sie interne Daten, externe Quellen und Nutzereingaben getrennt auf. Legen Sie fest, welches System für jede Information die maßgebliche Quelle ist. Werden Datensätze regelmäßig importiert? Müssen Abweichungen geprüft werden? Gibt es mehrere Versionen oder einen Freigabeschritt, bevor Änderungen öffentlich werden?

Ein CMS kann strukturierte Daten verwalten, ist aber nicht in jedem Fall die passende Datenbank oder Prozesssteuerung. Eine externe Datenpipeline kann Inhalte vorbereiten, während ein CMS die redaktionelle Prüfung übernimmt. Bei personenbezogenen oder geschäftskritischen Daten gehören Zuständigkeiten, Zugriffsrechte, Aufbewahrung und Löschung früh in die Planung. Rechtliche Anforderungen sind im Einzelfall zu prüfen.

5. Welche Integrationen sind wirklich erforderlich?

Erfassen Sie Systeme, die Daten liefern oder entgegennehmen: etwa CRM, Warenwirtschaft, Zahlungsanbieter, Apps, Suchdienste oder interne Werkzeuge. Trennen Sie verbindliche Integrationen von möglichen späteren Erweiterungen. Für jede verbindliche Verbindung sollte geklärt sein, in welche Richtung Daten fließen, wie Fehler erkannt werden und welches System bei widersprüchlichen Angaben Vorrang hat.

Eine API ist dann ein Architekturbaustein, wenn ein konkreter Verbraucher oder Integrationsbedarf existiert. Sie ist kein Selbstzweck. Wenn mehrere Frontends oder Anwendungen dieselben Daten nutzen, kann eine API-first-Architektur sinnvoll sein. Für eine einzelne Website mit einem redaktionellen Backend kann sie dagegen unnötige Komplexität erzeugen. Siehe dazu API-first: Wann eine API wirklich zur Architektur gehören sollte.

6. Welche Anforderungen bestehen an Auslieferung und Performance?

Statische Auslieferung kann die Anzahl dynamischer Komponenten reduzieren und ist für viele informationsorientierte Websites geeignet. Sie beseitigt jedoch nicht automatisch alle Laufzeitabhängigkeiten: Suche, Formulare, Personalisierung oder externe Daten können weiterhin Dienste und Schnittstellen benötigen.

Bewerten Sie deshalb nicht nur die Geschwindigkeit einer einzelnen Seite. Relevant sind auch Aktualisierungswege, Suchfunktion, Verfügbarkeit von Datenquellen, Ausfallverhalten und die technische Fähigkeit, Änderungen sicher auszurollen. Wenn Inhalte häufig aktualisiert werden müssen, muss der Veröffentlichungsprozess zum redaktionellen Takt passen. Static Site Generation behandelt die Einsatzbedingungen statischer Auslieferung genauer.

7. Wie viel Kontrolle braucht die Redaktion?

Redaktionelle Kontrolle umfasst mehr als ein Eingabefeld. Prüfen Sie Vorschau, Entwürfe, Freigaben, Rollen, Versionierung, geplante Veröffentlichungen und die Möglichkeit, Änderungen zurückzunehmen. Fragen Sie außerdem, ob Redakteure die Seitengestaltung frei verändern sollen oder ob ein festes Inhaltsmodell Konsistenz sicherstellen soll.

Ein freies Seitensystem kann Gestaltungsspielraum bieten, aber auch uneinheitliche Inhalte und Layouts erzeugen. Ein stark strukturiertes Modell begrenzt manche Freiheiten, macht Inhalte dafür wiederverwendbarer und validierbarer. Die richtige Balance hängt von Marke, Teamgröße und Publikationsprozess ab.

8. Wer betreibt und wartet die Lösung?

Kalkulieren Sie nicht nur die Einführung. Zur Architektur gehören Aktualisierungen, Backups, Überwachung, Sicherheitsmaßnahmen, Fehlerbehandlung, Abhängigkeiten und Dokumentation. Bei einer statischen Website können Build-Prozess und Datenpipelines wartungsrelevant sein. Bei einem CMS zählen unter anderem Erweiterungen, Benutzerrechte und Aktualisierungen. Bei einer Web-App kommen meist zusätzliche Laufzeitkomponenten und Zustandsverwaltung hinzu.

Klären Sie, wer diese Aufgaben übernimmt und welches Wissen dafür verfügbar sein muss. Eine Architektur, die nur von einer einzelnen Person verstanden wird, kann ein betriebliches Risiko sein – unabhängig davon, ob sie technisch elegant ist.

9. Welche Gesamtkosten entstehen über den Lebenszyklus?

Vergleichen Sie nicht nur Lizenz- oder Hostingkosten. Berücksichtigen Sie Einrichtung, individuelle Entwicklung, Migration, Redaktion, Integration, Betrieb, Anpassungen und spätere Änderungen. Die günstigste Startlösung kann teuer werden, wenn jede neue Anforderung Sonderarbeit auslöst. Eine individuelle Plattform kann wiederum unnötig aufwendig sein, wenn Standardfunktionen den Bedarf abdecken.

Entscheidend ist, welche Kosten regelmäßig wiederkehren und wie stark sie mit Wachstum oder Änderungen steigen. Schätzen Sie deshalb die typischen Änderungen der kommenden Betriebsphase ab: neue Inhaltstypen, zusätzliche Rollen, weitere Datenquellen oder neue Ausgabekanäle.

Architekturoptionen

Die Optionen schließen einander nicht vollständig aus. Die folgenden Beschreibungen zeigen, welche Aufgaben jede Architektur gut abdecken kann und wo zusätzliche Komponenten nötig werden.

CMS: wenn redaktionelle Arbeit im Zentrum steht

Ein klassisches CMS verbindet Inhaltsverwaltung und Website-Ausgabe in einem System. Es passt, wenn redaktionelle Teams Inhalte regelmäßig erstellen, überarbeiten und veröffentlichen und die Website hauptsächlich Informationen und Angebote darstellt.

WordPress kann von einer klassischen Website bis zu einer größeren Plattform reichen. Entscheidend ist, ob Inhalte, Rollen und Funktionen sauber modelliert sind. Wenn ein Projekt komplexe Daten und Nutzeraufgaben entwickelt, sollte das CMS nicht automatisch mit beliebigen Erweiterungen wachsen. Der Beitrag WordPress als Plattform zeigt, wann WordPress mehr als ein Publikationswerkzeug sein kann. Für komplexe Vorhaben sind außerdem Datenmodelle statt Plugin-Stapel relevant.

Ghost ist eine Option für redaktionelle Marken, bei denen Publikation und Leserbeziehung im Mittelpunkt stehen. Es ist kein Ersatz für jedes allgemeine CMS oder jede kundenspezifische Anwendung. Welche Anforderungen damit abgedeckt werden können, erläutert Ghost CMS für redaktionelle Marken.

Ein CMS ist weniger passend, wenn der wichtigste Produktwert aus individuellen Abläufen, komplexer Transaktionslogik oder umfassender Verarbeitung strukturierter Daten besteht. Dann kann es als Teil der Lösung dienen, sollte aber nicht ungeprüft die gesamte Anwendungslogik tragen.

Static Site: wenn Auslieferung und klare Inhaltsstrukturen zählen

Bei einer Static Site werden Seiten im Build-Prozess erzeugt und als fertige Dateien ausgeliefert. Das eignet sich besonders für informationsorientierte Websites, Dokumentationen und Content-Angebote, deren Inhalte nicht für jede Anfrage individuell berechnet werden müssen.

Astro kann Inhalte aus Dateien, einem CMS oder anderen Datenquellen verarbeiten und für die Auslieferung vorbereiten. Je nach Architektur lassen sich dynamische Funktionen ergänzen. Diese müssen dann bewusst abgegrenzt werden, statt sie als selbstverständlich vorhandene CMS-Funktionen zu behandeln. Der Beitrag Astro für Content-Sites beschreibt, wann diese Architektur passt.

Publii kann für kleine Websites mit einem überschaubaren redaktionellen Workflow eine pragmatische Lösung sein. Wenn viele Personen gleichzeitig Inhalte bearbeiten, komplexe Freigaben nötig sind oder Inhalte in mehreren Systemen ausgespielt werden sollen, sollten Sie prüfen, ob der Workflow weiterhin trägt. Mehr dazu unter Publii für statische Websites.

Statisch heißt nicht wartungsfrei. Build-System, Suche, Formulare, externe Daten und Aktualisierungswege benötigen weiterhin klare Zuständigkeiten. Eine Static Site ist auch nicht automatisch die beste Wahl, nur weil Seiten schnell ausgeliefert werden sollen.

Headless CMS: wenn Inhalt und Ausspielung getrennt sein müssen

Ein Headless CMS verwaltet Inhalte und stellt sie über Schnittstellen bereit. Das Frontend wird unabhängig davon entwickelt. Diese Trennung ist sinnvoll, wenn Inhalte über mehrere Kanäle oder unterschiedliche Oberflächen genutzt werden oder wenn ein eigenes Frontend klare Vorteile bietet.

Der Preis dafür ist zusätzliche Architekturarbeit: Vorschau und Veröffentlichung müssen verbunden, Schnittstellen gepflegt und Fehler über Systemgrenzen hinweg behandelt werden. Ein Headless CMS reduziert nicht automatisch den Gesamtaufwand. Es verschiebt Aufgaben und Zuständigkeiten. Wägen Sie den konkreten Bedarf gegen die zusätzliche Betriebs- und Entwicklungsarbeit ab.

Payload ist eine mögliche Option, wenn strukturierte Inhalte, APIs und redaktionelle Kontrolle zusammen gedacht werden sollen. Es ist besonders relevant, wenn Inhalt und Anwendung eng verbunden sind, aber ein eigenständiges Datenmodell gebraucht wird. Der Vergleich Payload CMS für Datenprodukte ordnet diesen Ansatz ein. Für den generellen Vergleich von Frontend und Backend siehe Monolith oder Headless.

Web-App: wenn Nutzer mit Daten und Prozessen arbeiten

Eine Web-App ist passend, wenn Nutzer personalisierte Funktionen verwenden, Daten anlegen oder verändern, Ergebnisse speichern oder geregelte Abläufe durchlaufen. Dazu können etwa Kundenportale, interne Werkzeuge, Konfiguratoren mit gespeicherten Aufträgen oder datenbasierte Produkte gehören.

In solchen Fällen müssen Datenmodell, Rechte, Zustände, Fehlerbehandlung und Schnittstellen als Kern der Lösung geplant werden. Ein CMS kann weiterhin redaktionelle Inhalte verwalten, sollte aber nicht automatisch die Anwendungslogik ersetzen. Wie sich die Grenze einordnen lässt, beschreibt Website oder Web-App sowie WordPress oder Webanwendung.

Eine individuelle Web-App ist nicht automatisch besser als ein CMS. Sie bringt Entwicklungs- und Wartungsverantwortung mit sich. Wenn die benötigten Funktionen durch ein bestehendes Produkt gut abgedeckt werden, ist eine Eigenentwicklung möglicherweise nicht gerechtfertigt. Wenn ein Standardtool dagegen zentrale Abläufe nur mit Umwegen abbildet, kann eine gezielte individuelle Lösung langfristig klarer sein.

Kombinationen: oft die tragfähige Antwort

Viele digitale Projekte lassen sich als Kombination präziser beschreiben:

Anforderung	Mögliche Architektur	Zu klärende Grenze
Redaktionelle Website mit regelmäßigen Artikeln	Klassisches CMS	Welche Rollen, Freigaben und Inhaltstypen werden benötigt?
Informationsportal mit strukturierten Inhalten	CMS oder Content-Datenquelle mit Static Site	Wie werden Daten aktualisiert, geprüft und ausgespielt?
Mehrere Ausgabekanäle für dieselben Inhalte	Headless CMS mit passenden Frontends	Wer betreibt Schnittstellen, Vorschau und Synchronisation?
Persönliche Konten und mehrstufige Nutzerabläufe	Web-App, gegebenenfalls mit CMS	Welche Daten gehören zur App, welche zur Redaktion?
Kleine Website mit seltenen Änderungen	Statischer Workflow, etwa mit Publii	Wer aktualisiert Inhalte und den Build-Prozess?
Datenprodukt mit Redaktion und Nutzerfunktionen	Individuelle Plattform oder CMS plus Anwendung	Wo liegen Datenhoheit, Berechtigungen und Geschäftslogik?

Die Tabelle ist ein Ausgangspunkt, keine automatische Zuordnung. Zwei Projekte mit ähnlichen Seitenzahlen können sehr unterschiedliche Datenflüsse und Betriebsanforderungen haben.

Vorgehen: von Anforderungen zur Architektur

1. Anforderungen nach Bedeutung ordnen

Trennen Sie Muss-Anforderungen von möglichen späteren Erweiterungen. Beschreiben Sie nicht nur gewünschte Funktionen, sondern den konkreten Ablauf: Wer handelt, mit welchen Daten, unter welchen Rechten und mit welchem Ergebnis? So wird sichtbar, ob eine vermeintliche Website-Funktion tatsächlich einen Anwendungsprozess darstellt.

2. Inhalte und Daten getrennt modellieren

Erstellen Sie eine Liste der Inhaltstypen und Datenobjekte. Notieren Sie Felder, Beziehungen, Herkunft, Aktualisierung und Freigabeverantwortung. Inhalte, die redaktionell gestaltet werden, müssen nicht zwingend dieselben Regeln haben wie importierte Datensätze oder Nutzereingaben.

3. Zuständigkeiten und Systemgrenzen festlegen

Legen Sie fest, welches System führend ist und welche Systeme Daten nur anzeigen oder verarbeiten. Definieren Sie, wo Berechtigungen durchgesetzt werden und wie Änderungen zurückverfolgt werden. Diese Grenzen sind wichtiger als die Frage, ob eine Komponente als CMS oder Backend bezeichnet wird.

4. Einen typischen Ablauf durchspielen

Prüfen Sie die Architektur an einem vollständigen Beispiel: Inhalt anlegen, prüfen, veröffentlichen, in einer Suche finden, in einer anderen Oberfläche anzeigen und später aktualisieren. Bei einer Anwendung ergänzen Sie Registrierung, Berechtigungen, Datenänderung und Fehlerfall. Lücken werden so früh sichtbar.

5. Betrieb und Veränderung mitplanen

Klären Sie, wie Releases, Backups, Updates, Monitoring und Wiederherstellung organisiert werden. Fragen Sie, ob eine Änderung vor Veröffentlichung geprüft werden kann und wie sie zurückgenommen wird. Das Prinzip Know → Change → Prove bietet dafür eine kontrollierte Denkweise: Zustand erfassen, Änderung freigeben und Wirkung prüfen.

Praxisbeispiel

Garten 1x1 zeigt eine Architektur, in der die Anforderungen an den Content nicht zwingend ein klassisches CMS für die öffentliche Website erforderten. Die Migration erfolgte von WordPress zu Astro über ein einmaliges TypeScript-Skript, das einen WXR-Export in Markdown überführte. Content Collections mit Zod-Schema bilden unterschiedliche Inhaltstypen wie Pflanzen, Probleme, Aufgaben, Bereiche, Regionen und Ziele ab. Dazu kommen eine Pagefind-Suche und ein Gartenrechner im Browser.

Das Beispiel belegt keine allgemeine Überlegenheit statischer Websites. Es zeigt vielmehr, wie eine klar definierte Content-Struktur und passende Browserfunktionen zusammenpassen können. Für andere Anforderungen – etwa häufige Mehrpersonen-Redaktion oder nutzerbezogene gespeicherte Zustände – wäre eine andere Architektur zu prüfen. Details stehen in der Case Study Garten 1x1.

Typische Fehler

• Die Entscheidung am bevorzugten Framework ausrichten. Ein vertrautes Werkzeug beantwortet nicht, wie Inhalte, Daten und Nutzerabläufe modelliert werden müssen.
• Seitenzahl mit Komplexität gleichsetzen. Wenige Seiten können durch Rechte, Integrationen und Transaktionen anspruchsvoll sein. Viele redaktionelle Seiten können bei klarer Struktur vergleichsweise einfach bleiben.
• CMS und Datenmodell verwechseln. Ein CMS speichert Inhalte, aber die passende Modellierung und Zuständigkeit entstehen nicht automatisch durch die Installation.
• Headless als Standard für Flexibilität wählen. Ohne konkreten Mehrkanal- oder Frontendbedarf entstehen zusätzliche Schnittstellen und Betriebsaufgaben.
• Statische Auslieferung mit einer vollständig statischen Lösung verwechseln. Suche, Formulare, Datenaktualisierung und Nutzerfunktionen können weitere Dienste oder Anwendungen benötigen.
• Dynamische Funktionen ins CMS drängen. Komplexe Nutzerzustände und Geschäftslogik werden dadurch nicht einfacher, sondern können schwerer testbar und wartbar werden.
• Nur Einführungskosten betrachten. Updates, Datenpflege, Releases, Dokumentation und spätere Anpassungen gehören zur Architekturentscheidung.
• Redaktion und Technik getrennt planen. Eine technisch klare Lösung ist nicht tragfähig, wenn die vorgesehenen Redaktionsabläufe im Alltag nicht funktionieren.
• Erweiterungen als unverbindliche Zukunftsoption behandeln. Wenn eine mögliche Funktion die Datenstruktur oder Systemgrenze verändert, sollte sie zumindest als Szenario in die Planung einfließen.

Empfehlung

• Wenn Inhalte überwiegend redaktionell erstellt und in einem zentralen Webauftritt veröffentlicht werden, dann beginnen Sie mit einem passenden CMS und einem klaren Content-Modell.
• Wenn die Website hauptsächlich Informationen ausliefert, Änderungen kontrolliert gebündelt werden und dynamische Funktionen begrenzt sind, dann prüfen Sie eine Static Site oder einen statischen Veröffentlichungsworkflow.
• Wenn dieselben Inhalte über mehrere eigenständige Kanäle genutzt werden, dann kann ein Headless CMS sinnvoll sein – sofern der zusätzliche Schnittstellen- und Betriebsaufwand eingeplant ist.
• Wenn Nutzer persönliche Daten verwalten, Zustände speichern oder geregelte Transaktionen ausführen, dann planen Sie eine Web-App oder Anwendungsschicht. Ein CMS kann daneben die redaktionellen Inhalte übernehmen.
• Wenn strukturierte Daten, viele Rollen, externe Quellen und Freigabeschritte zusammenkommen, dann definieren Sie zuerst Datenmodell, Zuständigkeiten und Systemgrenzen. Entscheiden Sie erst danach, ob ein CMS erweitert oder eine individuelle Plattform gebaut wird.
• Wenn Anforderungen noch unklar sind, dann erstellen Sie einen begrenzten Architekturtest an einem typischen Inhalt, Datenfluss oder Nutzerablauf – nicht an einer isolierten Demonstrationsseite.

Checkliste

• Sind Muss-Anforderungen von möglichen späteren Erweiterungen getrennt?
• Sind Inhaltstypen, Datenobjekte und ihre Beziehungen beschrieben?
• Ist festgelegt, welches System für jede Datenart maßgeblich ist?
• Sind Rollen, Freigaben und redaktionelle Zuständigkeiten geklärt?
• Ist bekannt, welche Funktionen dauerhafte Nutzerzustände oder Transaktionen benötigen?
• Sind alle notwendigen Integrationen und ihre Datenrichtungen dokumentiert?
• Ist geklärt, wer Updates, Backups, Releases und Fehlerbehandlung verantwortet?
• Können Änderungen geprüft, freigegeben und bei Bedarf zurückgenommen werden?
• Sind laufende Wartung und spätere Anpassungen in der Bewertung berücksichtigt?

Häufige Fragen

Ist ein CMS für jede Website nötig?

Nein. Wenn Inhalte selten geändert werden und ein einfacher Veröffentlichungsworkflow genügt, kann eine statische Lösung passender sein. Entscheidend ist, wer Inhalte pflegt und welche redaktionellen Funktionen gebraucht werden. Siehe auch Wann braucht eine Website überhaupt ein CMS?.

Ist eine Static Site automatisch schneller und günstiger?

Nicht automatisch. Die Art der Auslieferung kann dynamische Arbeit reduzieren, aber Build-Prozess, Suche, Formulare, Datenquellen und Wartung bleiben zu berücksichtigen. Vergleichen Sie den gesamten Betrieb statt eines einzelnen Hosting- oder Performance-Aspekts.

Kann WordPress auch eine Web-App oder Plattform tragen?

In bestimmten Fällen kann WordPress als Plattform und Backend dienen. Ob das tragfähig ist, hängt von Datenmodell, Berechtigungen, Anwendungslogik und Betrieb ab. Wenn die Anforderungen zu stark von redaktionellen Funktionen abweichen, sollte eine eigenständige Anwendung oder eine kombinierte Architektur geprüft werden.

Wann lohnt sich Headless?

Wenn Inhalte tatsächlich mehrere Frontends oder Kanäle versorgen sollen oder ein eigenständiges Frontend klare Anforderungen erfüllt. Wenn nur eine Website gebraucht wird, ist ein Headless-Aufbau oft nicht allein wegen möglicher Flexibilität gerechtfertigt.

Weiterführend

• Web-Architektur: Astro für Content-Sites
• Ghost CMS für redaktionelle Marken
• Payload CMS für Datenprodukte
• Publii für statische Websites

Weiterführende Quellen

Diese offiziellen Dokumentationen und Standards vertiefen die behandelten Themen.

• Astro: Content Collections
• Payload CMS Dokumentation
• Ghost Dokumentation
• WordPress: Custom Post Types