Was dieser Vergleich bewusst ausklammert: Joomla und Contao behandeln wir hier nicht in eigenen Kapiteln. Beide haben im deutschsprachigen Markt eine sinkende bzw. stark nischige Relevanz für neue B2B-Projekte und sind primär in Bestandsinstallationen relevant. Ebenfalls außen vor: klassische Homepage-Baukästen wie Wix, Squarespace, Strato oder der IONOS-Baukasten. Für eine ernsthafte Unternehmenswebsite mit Wachstumsanspruch sehen wir sie kritisch – der Lock-in beim Anbieter ist hoch, Datenexport und Wechsel sind eingeschränkt. Und: Dieser Vergleich ist bewusst kein Shopsystem-Vergleich.
Kurzüberblick: Wofür die Systeme typischerweise stehen
| Option | Typische Stärke | Typische Grenze |
|---|---|---|
| Kein CMS nötig | Kleine, langlebige Websites; schlanker Code; sehr gute Performance; KI-gestützte Änderungen | Keine klassische Redaktion, Rollen oder Freigaben |
| WordPress* | Marketing, SEO, Landingpages, großes Ökosystem und viele Dienstleister | Plugin-, Wartungs- und Qualitätsdisziplin nötig |
| Webflow | Designorientierte Websites mit Managed Hosting und schneller visueller Umsetzung | SaaS-Abhängigkeit und Grenzen bei komplexen Strukturen und Integrationen |
| Neos | Strukturierte Inhalte und sehr gute Inline-Redaktion | Kleinerer Markt an spezialisierten Dienstleistern |
| TYPO3 | Multisite, Mehrsprachigkeit, Rollen und Governance im DACH-Raum | Für kleine und agile Marketingprojekte häufig zu schwer |
| Drupal | Komplexe Datenmodelle, Portale, Rechte, Integrationen und Security | Hohe Konzeptions-, Entwicklungs- und Betriebskosten |
| Storyblok | Headless, Omnichannel und freie Frontend-Wahl mit visuellem Editor | Zusätzliche Frontend-Komplexität und SaaS-Abhängigkeit |
Die falsche Frage lautet: Welches CMS ist das beste?
Wer einen Website-Relaunch plant, beginnt häufig mit einer Produktfrage. WordPress oder TYPO3? Webflow oder ein Headless-CMS? Diese Frage kommt zu früh. Sie setzt voraus, dass bereits feststeht, wie die Website technisch aufgebaut werden soll. Genau das müsste aber erst aus den Anforderungen abgeleitet werden.
Eine Website kann heute ein relativ statischer Unternehmensauftritt sein. Sie kann aber auch Kampagnenmaschine, Fachportal, Bewerberplattform, Produktdatenbank, Kundenportal und Datenquelle für Apps zugleich sein. Beide Projekte heißen „Website“, benötigen aber weder dieselben Prozesse noch dieselbe Architektur. Die sinnvollere Reihenfolge lautet daher:
- Welche Aufgaben übernimmt die Website für Marketing, Vertrieb, Service und Recruiting?
- Wer verändert welche Inhalte – und wie häufig geschieht das wirklich?
- Welche Daten und Funktionen kommen aus anderen Systemen?
- Wer trägt nach dem Start die Verantwortung für Betrieb, Sicherheit und Weiterentwicklung?
- Welche Anforderungen bestehen an Datenschutz, Barrierefreiheit, Performance und Anbieterunabhängigkeit?
- Erst danach: Welches System erfüllt diese Anforderungen mit möglichst wenig unnötiger Komplexität?
Das klingt selbstverständlich. In Website-Projekten läuft es trotzdem oft anders. Ein System wird aus Gewohnheit, aufgrund einer Agenturpräferenz oder wegen eines einzelnen Features vorab gesetzt. Anschließend werden Prozesse und Anforderungen an das gewählte Werkzeug angepasst. Das ist einer der häufigsten Gründe für unnötig teure Relaunches.
Braucht eine Unternehmenswebsite 2026 überhaupt noch ein CMS?
Vor wenigen Jahren wäre die Antwort fast automatisch „ja“ gewesen. Ein CMS war der übliche Weg, um Inhalte ohne Programmierung zu ändern. Diese Annahme gilt nicht mehr uneingeschränkt. W3Techs weist zum 31. Juli 2026 für 30,4 Prozent der untersuchten Websites kein erkanntes Content-Management-System aus. Die Zahl bedeutet nicht, dass all diese Websites modern, statisch oder KI-gestützt sind. Sie zeigt aber deutlich: Ein klassisches CMS ist keine technische Pflicht.
Für eine Kanzlei oder Arztpraxis, Beratung, Handwerksfirma oder lokale Niederlassung mit zehn bis dreißig langlebigen Seiten kann eine individuell entwickelte Website ohne Datenbank und Redaktionsoberfläche sehr sinnvoll sein. Der öffentliche Auftritt besteht dann aus fertigen HTML-, CSS- und JavaScript-Dateien oder wird aus einer Codebasis statisch erzeugt. Änderungen werden über Git und einen kontrollierten Entwicklungsprozess veröffentlicht.
Neu ist nicht die statische Website. Neu ist, wie wirtschaftlich sie sich erstellen und pflegen lässt. Werkzeuge wie Lovable, Claude Code oder OpenAI Codex können heute Layouts und Komponenten erzeugen, vorhandene Codebasen analysieren, Änderungen umsetzen und Tests unterstützen. Damit kann eine kleine Website bei Bedarf tatsächlich „per KI“ verändert werden. Das ist etwas anderes als die Pflege in einem CMS: Die KI bearbeitet Code und Dateien, nicht nur freigegebene Inhaltsfelder.
Diese Option ist besonders interessant, wenn Inhalte selten geändert werden, nur eine verantwortliche Stelle existiert und keine komplexen Redaktions- oder Freigabeprozesse erforderlich sind. Sie ist weniger geeignet, sobald mehrere Personen regelmäßig Inhalte veröffentlichen, strukturierte Daten verwalten oder rechtsverbindliche Freigaben dokumentieren müssen.
Unsere Einordnung
„Kein CMS nötig“ ist keine Sparvariante und kein Freibrief für unkontrolliertes Vibe Coding. Es ist eine eigenständige Architektur, die bei passenden Anforderungen einfacher, schneller und sicherer sein kann – aber nur mit Versionskontrolle, Tests, Backups und klarer Verantwortung.
Vibe Coding: sinnvoller Beschleuniger oder teure Abkürzung?
Vibe Coding beschreibt einen Entwicklungsstil, bei dem Anforderungen in Alltagssprache formuliert und von KI-Werkzeugen in Code übersetzt werden. Für Prototypen, kleine Websites und klar abgegrenzte Funktionen kann das die Entwicklung erheblich beschleunigen. Der Begriff beschreibt jedoch nur, wie Code entsteht. Er sagt nichts darüber aus, ob das Ergebnis strategisch sinnvoll, barrierefrei, sicher, wartbar oder performant ist. Eine Website kann im Browser gut aussehen und trotzdem gravierende Mängel besitzen: unklare Informationsarchitektur, nicht messbare Formulare, fehlende Consent-Logik, unzugängliche Dialoge oder übergroße JavaScript-Pakete.
- Umfang und Ziel der Website sind klar begrenzt.
- Ein bestehendes Komponenten- und Designsystem gibt Leitplanken vor.
- Code liegt in einer Versionsverwaltung und jede Änderung bleibt nachvollziehbar.
- Staging, automatisierte Tests und manuelle Abnahme sind vorgesehen.
- Eine fachkundige Person prüft Security, Datenschutz, SEO und Barrierefreiheit.
Riskant wird es, wenn die KI gleichzeitig Konzept, Design, Code, Inhalte und Betrieb ohne fachliche Kontrolle übernehmen soll. Dann werden Entscheidungen zwar schneller getroffen, aber nicht zwingend besser. Die Kosten verschwinden nicht – sie tauchen später als technische Schuld, Sicherheitslücke oder unübersichtliche Codebasis wieder auf.
KI an die Website anbinden: mehr als ein Chatfenster
Bei der Systemauswahl wird inzwischen häufig gefragt, ob die Website „KI-fähig“ sei. Das ist zu ungenau. Fast jede moderne Website kann einen externen Chatbot einbinden. Entscheidend ist, welche Daten die KI verwenden darf, wie Antworten kontrolliert werden und ob die Funktion nur ein Zusatz oder Teil des digitalen Produkts ist.
| Stufe | Beispiel | Architektonische Folgen |
|---|---|---|
| 1. Externer Dienst | Chatbot oder Übersetzung wird als fertiger Dienst eingebettet | Consent, Auftragsverarbeitung, Datenübermittlung und Ladezeit prüfen |
| 2. KI-Suche | Inhalte werden semantisch durchsucht und zusammengefasst | Saubere Content-Struktur, Indexierung, Quellenangaben und Aktualisierung erforderlich |
| 3. Assistent auf eigener Wissensbasis | Freigegebene Inhalte, Produktdaten oder Dokumente werden genutzt | Berechtigungen, Retrieval, Protokollierung, Datenqualität und Halluzinationskontrolle nötig |
| 4. KI als Produktfunktion | Assistent arbeitet in Portal oder Anwendung mit Kundendaten | Authentifizierung, Rollen, Auditierbarkeit, Security-Architektur und tiefe Backend-Anbindung zentral |
Für Stufe eins reicht häufig ein klassisches CMS oder sogar eine statische Website. Ab Stufe drei werden strukturierte Inhalte, APIs und klare Berechtigungsmodelle wesentlich wichtiger. Dann gewinnen Drupal, Storyblok, Neos, TYPO3 oder eine individuell geplante Architektur an Gewicht. WordPress* kann ebenfalls angebunden werden, benötigt bei komplexen Szenarien aber ein sehr bewusstes Daten- und Sicherheitskonzept.
Was moderne Website-Systeme im Frontend leisten müssen
Responsive Design: nicht nur Desktop, Tablet und Smartphone
Responsive Design wird häufig auf drei Layoutansichten reduziert. Das reicht nicht. Websites müssen bei unterschiedlichen Bildschirmbreiten, Schriftvergrößerungen, Hoch- und Querformat, Touch-, Maus- und Tastaturbedienung stabil funktionieren. Ein gutes System verhindert responsive Fehler nicht automatisch. Entscheidend sind ein belastbares Designsystem, flexible Komponenten und echte Tests.
Core Web Vitals und Ladezeiten
Google beschreibt die Core Web Vitals als Kennzahlen für reale Nutzungserfahrungen. Im Mittelpunkt stehen derzeit LCP für die Ladeleistung, INP für die Reaktionsfähigkeit und CLS für visuelle Stabilität. Gute Werte entstehen nicht durch den Namen des CMS, sondern durch Frontend-Code, Bildstrategie, Hosting, Caching und den kontrollierten Einsatz externer Skripte.
Statische Websites und moderne Headless-Frontends haben strukturelle Vorteile, weil sie Seiten vorab erzeugen und ohne umfangreiche Backend-Logik ausliefern können. Webflow kann ebenfalls sehr schnell sein. WordPress*, TYPO3 und Drupal erreichen gute Werte, wenn Templates, Erweiterungen und Infrastruktur sauber optimiert sind. Sinnvoll sind Performance-Budgets, Feldmessungen mit realen Nutzerdaten und klare Regeln für neue Drittanbieter.
Barrierefreiheit als Qualitätsstandard
Die WCAG des W3C strukturieren Barrierefreiheit nach vier Grundprinzipien: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein. Das Barrierefreiheitsstärkungsgesetz gilt seit dem 28. Juni 2025 für bestimmte Produkte und Dienstleistungen, besonders relevant sind digitale Angebote im elektronischen Geschäftsverkehr. Ob ein konkretes Unternehmen erfasst ist, sollte rechtlich geprüft werden.
Für die CMS-Auswahl bedeutet das: Das System muss semantische Komponenten ermöglichen und Redakteure vor typischen Fehlern schützen. Vollständig freie Layouts sind nicht automatisch ein Vorteil. Bei verbindlicher Barrierefreiheit sind begrenzte, geprüfte Komponenten häufig besser als unbegrenzte Gestaltungsfreiheit.
Was ein modernes System im Backend leisten muss
Redaktion und Freigaben
Eine kleine Marketingabteilung benötigt andere Funktionen als eine Hochschule, ein Konzern oder eine öffentliche Einrichtung. Relevant sind nicht nur Benutzerkonten, sondern Rollen, Versionierung, Vier-Augen-Freigaben, Vorschau, zeitgesteuerte Veröffentlichung, Übersetzungsprozesse und nachvollziehbare Verantwortlichkeiten. Je einfacher das Projekt, desto gefährlicher ist es, Enterprise-Prozesse vorsorglich einzubauen.
Strukturierte Inhalte und Mehrfachnutzung
Leistungen, Ansprechpartner, Standorte, Veranstaltungen und Produkte sollten als strukturierte Datensätze gepflegt werden, wenn sie an mehreren Stellen erscheinen. Werden dieselben Informationen auf vielen Seiten kopiert, entstehen Widersprüche und unnötiger Pflegeaufwand. Headless- und Enterprise-CMS sind hier stark, aber auch WordPress* kann mit Custom Post Types und Feldern vernünftig strukturiert werden.
Schnittstellen und Integrationen
Eine API allein macht noch keine gute Integration. Entscheidend sind Datenmodell, Berechtigungen, Fehlerbehandlung, Dokumentation, Webhooks, Synchronisationsrichtung und Verantwortung bei Ausfällen. CRM, ERP, PIM, DAM oder Bewerbersysteme sollten nicht über zufällige Plugin-Ketten angebunden werden, wenn sie geschäftskritisch sind.
Datenschutz, Security und Rechtsraum
Open Source und SaaS verteilen Verantwortung unterschiedlich. Bei selbst gehosteten Systemen lassen sich Hosting, Netzwerk und Datenstandort weitgehend selbst bestimmen. Dafür müssen Updates, Monitoring, Backups und Incident-Prozesse organisiert werden. Bei SaaS übernimmt der Anbieter große Teile des Betriebs, gleichzeitig entstehen Abhängigkeiten von Vertragsbedingungen, Unterauftragnehmern, Datenflüssen und Rechtsraum.
Bei KI-Funktionen kommen neue Fragen hinzu: Welche Eingaben werden an Modellanbieter übertragen? Werden Inhalte zum Training verwendet? Welche Daten dürfen indexiert werden? Wie werden Zugriffe beschränkt und Antworten protokolliert? Diese Entscheidungen gehören nicht erst in die Datenschutzerklärung, sondern in die Architektur.
Agenturauswahl und langfristiger Betrieb
Das System bestimmt auch, welche Agenturen und Fachkräfte später zur Verfügung stehen. WordPress* besitzt einen sehr großen Markt, die Qualität der Anbieter schwankt allerdings erheblich. TYPO3 und Drupal haben kleinere, aber oft stärker technisch geprägte Dienstleistermärkte. Neos bietet eine überzeugende Technologie, kann aber regional zu höherer Abhängigkeit von einzelnen Spezialisten führen. Bei Webflow und Storyblok bleibt das Betriebsmodell eng mit dem Plattformanbieter verbunden.
- Wer besitzt Domains, Hostingkonten, Repositorys, Lizenzen und Administrationszugänge?
- Ist die Website dokumentiert und kann ein anderer Dienstleister übernehmen?
- Wer verantwortet Updates, Sicherheitsmeldungen, Backups und Wiederherstellung?
- Gibt es Staging, Versionskontrolle, automatisierte Deployments und Abnahmeprozesse?
- Wie werden Barrierefreiheit, Performance und Datenschutz getestet?
- Welche laufenden Kosten entstehen für Lizenzen, Plugins, Hosting und Wartung?
Marktanteile 2026: Orientierung, kein Qualitätsranking
Nach den aktuellen W3Techs-Daten vom 31. Juli 2026 nutzt WordPress 41,2 Prozent aller untersuchten Websites und erreicht 59,1 Prozent Marktanteil unter Websites mit erkanntem CMS. Webflow liegt bei 0,8 Prozent aller Websites beziehungsweise 1,2 Prozent im CMS-Markt. Drupal erreicht 0,7 beziehungsweise 1,0 Prozent, TYPO3 0,4 beziehungsweise 0,5 Prozent. 30,4 Prozent verwenden keines der von W3Techs überwachten CMS.
Diese Zahlen sind für die Auswahl relevant, weil Verbreitung Hinweise auf Fachkräfte, Erweiterungen und langfristige Anschlussfähigkeit gibt. Sie sagen aber nichts darüber aus, ob ein System für ein konkretes Projekt geeignet ist. TYPO3 ist global klein, im deutschsprachigen Enterprise- und öffentlichen Umfeld aber deutlich relevanter. Storyblok und Neos bewegen sich ebenfalls in Nischen, können dort jedoch sehr gut passen.
| System / Kategorie | Anteil aller Websites | Anteil im erkannten CMS-Markt |
|---|---|---|
| Kein überwachtes CMS | 30,4 % | – |
| WordPress | 41,2 % | 59,1 % |
| Webflow | 0,8 % | 1,2 % |
| Drupal | 0,7 % | 1,0 % |
| TYPO3 | 0,4 % | 0,5 % |
| Neos | unter 0,1 % | unter 0,1 % |
| Storyblok | unter 0,1 % | unter 0,1 % |
Stand der W3Techs-Werte: 31. Juli 2026. Marktanteile schwanken mit Messmethode und Stichtag.
Die Systeme im ausführlichen Vergleich
WordPress*: der pragmatische Marketing-Allrounder
WordPress* bleibt für viele KMU- und Marketing-Websites die pragmatischste Lösung. Das liegt weniger an der Kernsoftware als am großen Ökosystem. Für nahezu jedes verbreitete CRM, Newsletter-System, Formular-, SEO- oder Tracking-Werkzeug existieren Erweiterungen oder erprobte Integrationswege. Mit Elementor können Marketingteams Seiten visuell aufbauen und relativ schnell verändern.
Die Stärke ist zugleich das Risiko. WordPress-Projekte werden häufig aus zu vielen Plugins, Add-ons und individuellen Sonderlösungen zusammengesetzt. Dadurch steigen Angriffsfläche, Update-Aufwand und Performance-Risiken. Ein professioneller Aufbau benötigt einen begrenzten, dokumentierten Plugin-Stack, ein Komponentenmodell, Staging, Backups, Monitoring und verbindliche Update-Prozesse.
Für KI-gestützte Weiterentwicklung ist WordPress interessant, weil Theme-, Plugin- und Integrationscode offen zugänglich ist. Gleichzeitig sollte KI nicht unkontrolliert direkt auf einer Produktivinstallation arbeiten. WordPress kann außerdem headless über die REST API oder GraphQL betrieben beziehungsweise statisch veröffentlicht werden. Das erhöht die technische Komplexität und sollte nur bei einem konkreten Nutzen gewählt werden.
Webflow: starke Gestaltung bei geringem Betriebsaufwand
Webflow verbindet visuellen Websitebau, CMS und Managed Hosting. Für designorientierte Corporate Websites und Kampagnen ist das attraktiv: Layouts und Interaktionen lassen sich sehr direkt umsetzen, während Serverbetrieb und Core-Updates weitgehend beim Anbieter liegen. Die Plattform fördert saubere responsive Regeln stärker als viele klassische Drag-and-Drop-Baukästen.
Die Grenzen zeigen sich bei komplexen Datenmodellen, tiefen Integrationen, großen Multisite-Strukturen und strategischer Souveränität. Webflow ist eine proprietäre Cloud-Plattform. Preisgestaltung, Produktgrenzen, Hosting und viele dynamische Funktionen bleiben an den Anbieter gebunden. Für Unternehmen mit hohen Anforderungen an Datenstandort, Auditierbarkeit oder Exit sollte diese Abhängigkeit bewusst bewertet werden.
Drupal: wenn Komplexität wirklich vorhanden ist
Drupal spielt seine Stärken bei komplexen Portalen, Datenmodellen, Rollen, Workflows und Integrationen aus. Die JSON:API ist im Core verankert und arbeitet mit dem Entity-, Field- und Berechtigungssystem zusammen. Das macht Drupal zu einer starken Grundlage für klassische, hybride und headless Architekturen.
Für eine normale KMU-Website wäre Drupal meist überdimensioniert. Es verlangt ein gutes technisches Konzept, erfahrene Entwickler und einen professionellen Betrieb. Hohe Security- oder Compliance-Anforderungen sprechen nicht automatisch für Drupal, aber das System bietet deutlich mehr strukturelle Möglichkeiten, solche Anforderungen sauber umzusetzen.
TYPO3: Multisite, Sprachen und Governance
TYPO3 ist besonders stark, wenn viele Websites, Sprachen, Rollen und Organisationseinheiten zentral verwaltet werden. Hochschulen, Verbände, öffentliche Stellen und größere mittelständische Unternehmen nutzen das System häufig für kontrollierte Weblandschaften. Rechte, Workspaces und Multisite-Funktionen sind nicht nachträglich aufgesetzt, sondern Teil des typischen Einsatzmodells.
Marketingteams erleben TYPO3 manchmal als weniger spontan als WordPress* oder Webflow. Das ist häufig die Folge der gesetzten Leitplanken. Wer Governance benötigt, profitiert davon. Wer nur schnell Landingpages bauen will, bezahlt für Komplexität, die keinen Mehrwert liefert.
Neos: gute Redaktion und strukturiertes Content-Modell
Neos verbindet direkte Inline-Bearbeitung mit einem flexiblen Content Repository. Redakteure arbeiten nahe an der späteren Darstellung, während Inhalte trotzdem strukturiert und über Dimensionen, Workspaces und Schnittstellen organisiert werden können. Das wichtigste Risiko ist der kleinere Spezialistenmarkt: Unternehmen sollten früh prüfen, wie viele geeignete Agenturen verfügbar sind und wie ein Dienstleisterwechsel funktioniert.
Storyblok: Headless mit visueller Redaktion
Storyblok trennt die Inhaltsverwaltung vom Frontend. Inhalte werden über APIs an Websites, Apps oder andere Kanäle ausgeliefert. Der Visual Editor reduziert dabei eine typische Schwäche vieler Headless-Systeme: Redakteure können Änderungen im Seitenkontext sehen. Diese Architektur lohnt sich, wenn mehrere Frontends, unabhängige Deployment-Zyklen oder Omnichannel tatsächlich erforderlich sind. Für eine einzelne Corporate Website entsteht dagegen schnell unnötige Komplexität.
Kein CMS nötig: schlank, schnell und kontrolliert per KI pflegbar
Eine Website ohne CMS kann die wirtschaftlichste Lösung sein, wenn wenige Inhalte selten geändert werden. Sie benötigt keine laufende Datenbank, keine Plugin-Updates und keine allgemeine Redaktionsoberfläche. Die öffentliche Angriffsfläche ist meist kleiner und sehr gute Ladezeiten sind leichter erreichbar.
KI-Werkzeuge machen die Pflege zugänglicher. Sie können neue Seiten aus vorhandenen Komponenten erstellen, Texte ersetzen, strukturierte Daten ergänzen oder technische Fehler beheben. Trotzdem bleibt der Prozess eine Softwareänderung. Jede Anpassung sollte als nachvollziehbarer Commit erfolgen, automatisch gebaut und vor Veröffentlichung geprüft werden. Ungeeignet ist diese Architektur, wenn häufige redaktionelle Arbeit, viele Beteiligte, Übersetzungsworkflows oder umfangreiche strukturierte Inhalte erwartet werden.
Direkter Vergleich nach zentralen Kriterien
| Kriterium | WordPress* | Webflow | Drupal / TYPO3 | Neos | Storyblok | Kein CMS |
|---|---|---|---|---|---|---|
| Marketing-Agilität | Sehr hoch | Hoch | Mittel bis gering | Mittel bis hoch | Mittel | Mittel bei KI-Prozess |
| Redaktionsworkflows | Gut, erweiterbar | Gut für kleine Teams | Sehr stark | Sehr stark | Stark | Nicht vorhanden |
| Komplexe Datenmodelle | Mittel | Begrenzt | Sehr stark | Sehr stark | Sehr stark | Individuell, aber ohne Redaktion |
| Schnittstellen | Hoch | Mittel | Sehr hoch | Hoch | Sehr hoch | Individuell |
| Hostingfreiheit | Sehr hoch | Gering | Sehr hoch | Sehr hoch | Gering bis mittel | Sehr hoch |
| Core-Web-Vitals-Potenzial | Gut bei Disziplin | Sehr gut | Sehr gut bei guter Umsetzung | Sehr gut | Sehr gut | Sehr hoch |
| Barrierefreiheit | Gut mit Komponenten und Regeln | Gut bei sauberer Umsetzung | Sehr gut steuerbar | Sehr gut steuerbar | Frontendabhängig | Sehr gut steuerbar |
| KI-gestützte Codepflege | Gut | Begrenzt durch Plattform | Gut, aber anspruchsvoll | Gut | Sehr gut im Frontend | Sehr hoch |
| Agenturwechsel | Meist gut | Mittel | Gut bei Dokumentation | Markt kleiner | Frontend wechselbar, CMS gebunden | Gut bei sauberem Repository |
| Typische Projektgröße | Klein bis mittelgroß | Klein bis mittelgroß | Mittelgroß bis Enterprise | Mittelgroß | Mittelgroß bis Enterprise | Klein bis klar begrenzt |
Welche Lösung passt zu welchem Unternehmen?
| Ausgangslage | Naheliegende Option | Worauf besonders achten? |
|---|---|---|
| Kleine Praxis, Kanzlei oder lokaler Dienstleister | Kein CMS oder WordPress* | Änderungshäufigkeit, Formulare, lokale SEO, Barrierefreiheit und klare Zuständigkeit |
| Marketinggetriebenes KMU | WordPress* oder Webflow | Landingpages, Tracking, SEO, Komponenten, Wartung und Agenturqualität |
| Designorientierte Kampagnen- oder Corporate Site | Webflow oder kein CMS | Plattformbindung, spätere Inhaltsmenge, responsive Tests und Performance |
| Internationaler Mittelstand | TYPO3, Neos, Drupal oder Storyblok | Sprachen, Multisite, Rollen, Integrationen und Betriebsmodell |
| Content-Hub mit vielen strukturierten Inhalten | Neos, Drupal, TYPO3 oder WordPress* | Content-Modell, Suche, Taxonomien, Redaktion und API-Bedarf |
| Portal oder digitale Plattform | Drupal, TYPO3 oder individuelle Headless-Architektur | Authentifizierung, Security, Rechte, Schnittstellen und Observability |
| Omnichannel mit Website und App | Storyblok, Drupal oder Neos | Frontend-Team, Preview, Deployment, API-Governance und SaaS-Risiko |
| Reguliertes Angebot oder öffentliche Stelle | Drupal oder TYPO3; ggf. Neos | Barrierefreiheit, Auditierbarkeit, Hosting, Rollen und langfristige Betreuung |
Die 15 Fragen im CMS-Check
Der Check geht bewusst tiefer als übliche Online-Quizze. Die folgenden Fragen fließen in die Bewertung ein:
- Welche Aufgabe soll die Website hauptsächlich erfüllen?
- Wie häufig ändern sich Inhalte voraussichtlich?
- Wie viele Personen sollen Inhalte bearbeiten?
- Wie umfangreich und wiederkehrend sind die Inhalte?
- Welche anderen Systeme müssen angebunden werden?
- Wie frei und schnell sollen neue Seiten gestaltet werden?
- Wie wichtig sind Hostingfreiheit und Unabhängigkeit vom Anbieter?
- Welches Budget ist für Konzeption, Design und Entwicklung vorgesehen?
- Wie soll die Website nach dem Start betreut werden?
- Welche Rolle soll KI bei Entwicklung und Pflege spielen?
- Welche KI-Funktionen soll die Website selbst erhalten?
- Welche Anforderungen bestehen an Datenschutz und Sicherheit?
- Auf welchen Geräten und in welchen Situationen muss die Website zuverlässig funktionieren?
- Wie wichtig sind sehr gute Ladezeiten und Core Web Vitals?
- Welchen Stellenwert hat digitale Barrierefreiheit?
Wer das Ergebnis anschließend gemeinsam einordnen möchte, findet in unserer Relaunch-Beratung den passenden Rahmen. Die Ergebnisansicht nennt nicht nur ein einzelnes System, sondern eine Hauptempfehlung und eine plausible Alternative, eine Begründung anhand der wichtigsten Antworten, Stärken und Grenzen der empfohlenen Architektur, Warnhinweise zu Datenschutz, Barrierefreiheit, Security oder Anbieterbindung sowie die Möglichkeit, die vollständige Vergleichsmatrix als Excel-Datei anzufordern.
Fazit: So viel System wie nötig – und so wenig Komplexität wie möglich
Die Entscheidung fällt 2026 nicht mehr nur zwischen verschiedenen CMS. Unternehmen können zwischen klassischem CMS, Website-Plattform, Headless-Architektur und einer KI-gestützt gepflegten Code-Website wählen. Das erweitert die Möglichkeiten, macht die Entscheidung aber nicht einfacher.
WordPress* bleibt für viele Marketing- und KMU-Websites der pragmatische Allrounder. Webflow überzeugt bei designorientierten Projekten und geringem Betriebsaufwand. TYPO3 und Drupal sind sinnvoll, wenn Multisite, Governance, Integrationen und Security die Mehrkosten rechtfertigen. Neos verbindet strukturierten Content mit sehr guter Redaktion. Storyblok ist stark, wenn Inhalte tatsächlich für mehrere Frontends benötigt werden.
Und manchmal ist die richtige Antwort: gar kein CMS. Für kleine, selten veränderte Websites kann eine sauber entwickelte Codebasis mit KI-gestützter Pflege wirtschaftlicher, schneller und wartungsärmer sein. Entscheidend ist, dass die Einfachheit nicht mit fehlender Qualitätssicherung verwechselt wird.
Das beste Website-System ist deshalb nicht das mit den meisten Funktionen. Es ist das System, dessen Komplexität zu den tatsächlichen Anforderungen passt, von den verantwortlichen Personen beherrscht wird und auch nach einem Agenturwechsel noch sinnvoll betrieben werden kann.
* WordPress bezeichnet in diesem Vergleich die selbst gehostete Open-Source-Variante mit Elementor-Editor. Headless- oder statische Varianten können zusätzlich REST API, WPGraphQL und/oder eine statische Veröffentlichung einsetzen.