Als Cloudflare Anfang April 2026 EmDash als neuen Gegenentwurf zu WordPress vorgestellt hat, war daran weniger das Produkt selbst interessant als das, was der Release sichtbar macht. Der Vergleich legt einen alten Schwachpunkt von Gutenberg offen: Content wird am Ende als HTML in post_content gespeichert und nicht als strukturiertes Datenmodell.
Dass genau darin ein grundlegendes Problem liegt, ist keine neue Beobachtung. Die Debatte um strukturierte Daten in WordPress begleitet Gutenberg im Grunde seit dem Start, und ich kritisiere diese mangelhafte Unterstützung seit 2017. Schon früh war absehbar, dass Inhalte im Web mehr sein würden als reine Ausgabe. Sie müssen sich einordnen, sortieren, transformieren und in neue Kontexte überführen lassen. Genau daran entscheidet sich heute, wie zukunftsfähig ein CMS wirklich ist.
Der Punkt ist deshalb nicht, ob Gutenberg ein guter Editor ist. Der Punkt ist, dass Gutenberg seine innere Struktur beim Speichern nicht ernst genug nimmt. Solange Content vor allem als HTML abgelegt wird, bleibt Struktur etwas, das bei Bedarf erst wieder herausgelesen werden muss. In einer Webrealität mit APIs, Headless Architekturen und KI gestützten Workflows wirkt das zunehmend wie ein Konstruktionsfehler, den WordPress bis heute mitschleppt.
Warum EmDash CMS gerade jetzt relevant ist
Cloudflare positioniert EmDash CMS nicht einfach als ein weiteres neues CMS, sondern als Gegenentwurf zu einer bestimmten Art, Content zu speichern und weiterzuverarbeiten. Genau deshalb ist der Release interessant. EmDash CMS setzt auf strukturierten Content statt auf serialisiertes HTML und nutzt dafür Portable Text, also ein JSON basiertes Rich Text Format. Damit trennt das System Inhalt und Darstellung dort, wo Gutenberg beides bis heute zu eng miteinander verknüpft.
Wie grundlegend dieser Unterschied ist, zeigt ein Blick auf die Architektur von Gutenberg. In der offiziellen WordPress Doku zu Data Flow and Data Format wird beschrieben, dass der Block Baum beim Bearbeiten im Speicher existiert, gespeichert wird am Ende aber post_content. Die Seite zur Markup Representation of a Block zeigt zusätzlich, dass diese Speicherung über HTML mit Block Kommentaren funktioniert. Gutenberg arbeitet intern also strukturiert, behandelt diese Struktur beim Speichern aber nicht als primäres Datenmodell.
Genau deshalb ist EmDash CMS gerade jetzt relevant. Der Release liefert keinen bloßen Produktvergleich, sondern einen Kontrast, an dem sich Gutenbergs architektonische Schwäche sehr klar ablesen lässt. Wenn ein neues CMS im Jahr 2026 offensiv darauf setzt, Content als Daten zu behandeln, dann ist die Speicherfrage keine technische Fußnote mehr. Sie ist eine Architekturfrage.
Das eigentliche Problem liegt nicht im Editor, sondern im Speicherformat
Die Schwäche von Gutenberg zeigt sich nicht beim Schreiben, sondern dort, wo Inhalte außerhalb des Editors weiterleben sollen. Solange ein Text nur in WordPress bearbeitet und anschließend gerendert wird, fällt die Speicherentscheidung kaum auf. Relevant wird sie erst dann, wenn Content über Schnittstellen weiterverarbeitet, umgebaut oder in andere Systeme überführt werden soll. Genau dort wird aus einer internen Implementierung eine strukturelle Grenze.
Der Grund dafür ist simpel: Gutenberg speichert seine inhaltliche Struktur nicht als primäres Datenmodell, sondern als serialisierte Ausgabe in post_content. Die WordPress Dokumentation zu Data Flow and Data Format beschreibt diese Trennung ausdrücklich. Was im Editor als Blockstruktur vorliegt, wird beim Speichern in ein HTML geprägtes Format überführt. Die Seite zur Markup Representation of a Block zeigt, wie diese Struktur über Kommentar Marker und eingebettete Attribute erhalten bleibt.
Der Preis fehlender Vorausschau
Das funktioniert, aber es hat einen Preis. Sobald andere Systeme nicht die Ausgabe, sondern die Bedeutung eines Inhalts verstehen sollen, muss diese Struktur erst wieder aus dem gespeicherten HTML herausgelesen werden. WordPress stellt dafür mit parse_blocks() die zentrale Funktion bereit. Dass in der offiziellen Referenz auf den Speicherbedarf hingewiesen wird und mit dem WP_Block_Processor inzwischen ein zusätzlicher, effizienterer Zugriff eingeführt wurde, zeigt ziemlich klar, wo die Reibung entsteht.
Noch deutlicher wird das bei der Block Data API von WordPress VIP. Sie stellt Gutenberg Inhalte als strukturiertes JSON bereit und wird ausdrücklich damit begründet, dass sich so HTML Parsing vermeiden lässt. Genau das ist der entscheidende Punkt. Wenn ein System erst eine zusätzliche API braucht, um seine Inhalte in einer Form auszugeben, die für Headless Architekturen, GraphQL oder andere Anwendungen sinnvoll nutzbar ist, dann zeigt das vor allem, wo die ursprüngliche Speicherlogik an ihre Grenzen stößt.
Damit wird auch klar, warum EmDash CMS als Vergleich so interessant ist. Der Kontrast zeigt nicht nur, dass ein anderer Weg möglich ist. Er zeigt vor allem, wie viel Zusatzaufwand WordPress inzwischen betreiben muss, um wieder an die Struktur heranzukommen, die beim Speichern nie sauber priorisiert wurde.
Warum WordPress diese Entscheidung so begründet hat und warum das trotzdem zu kurz greift
WordPress hat die Entscheidung für HTML in post_content nicht beiläufig getroffen, sondern bewusst begründet. In der offiziellen Doku zu Data Flow and Data Format geht es um Kompatibilität, um eine Single Source of Truth und darum, konkurrierende Speichermodelle zu vermeiden. Auch die FAQ zum Block Editor argumentiert in diese Richtung und stellt den HTML nahen Ansatz dem Gedanken gegenüber, Inhalte stattdessen als JSON in Post Meta zu speichern.
Genau diese Begründung greift aus unserer Sicht aber zu kurz. Denn sie denkt zu stark aus der Logik bestehender WordPress Strukturen und zu wenig aus der Frage, was Inhalte künftig leisten müssen. Kompatibilität ist ein valider Punkt. Aber sie ersetzt kein sauberes Strukturmodell.
Das Problem war von Anfang an sichtbar. Sobald Content mehr sein soll als gerenderte Ausgabe, reicht es nicht, Struktur nur implizit in HTML mitzuschleppen. Dann braucht es ein Datenmodell, das Inhalte nicht bloß darstellt, sondern sie auch maschinell lesbar, sortierbar und weiterverarbeitbar macht. Genau diese Kritik haben wir rund um strukturierte Daten in WordPress schon früh formuliert.
Rückblickend wirkt die damalige Argumentation deshalb weniger wie eine tragfähige Lösung als wie eine defensive Entscheidung zugunsten kurzfristiger Systemstabilität. Der Preis dafür ist bis heute sichtbar. Struktur muss wieder aus HTML herausgelöst werden, statt von Anfang an die Grundlage des Inhalts zu sein.
EmDash CMS macht sichtbar, wie ein anderer Weg aussehen kann
Genau deshalb ist EmDash CMS mehr als nur ein neues CMS. Interessant ist nicht, dass Cloudflare jetzt auch ein Publishing System baut. Interessant ist, dass EmDash CMS die Speicherfrage dort ansetzt, wo Gutenberg ihr bis heute ausweicht.
Der entscheidende Unterschied liegt in der Architektur. EmDash CMS setzt mit Portable Text auf ein JSON basiertes Rich Text Format und trennt Inhalt damit sauber von seiner späteren Darstellung. Das ist keine technische Nebensache, sondern eine grundsätzlich andere Haltung. Content wird nicht erst beim Rendern oder Parsen wieder als Struktur lesbar, sondern bringt diese Struktur von Anfang an mit.
Genau darin liegt die eigentliche Provokation für WordPress. EmDash CMS stellt implizit die Grundannahme infrage, dass HTML ein sinnvoller Ort ist, um Content dauerhaft abzulegen. Denn wenn Inhalte heute als Datenobjekte durch unterschiedliche Systeme laufen, dann ist HTML nicht die Basis, sondern nur noch eine mögliche Ausgabeform. EmDash CMS behandelt diese Realität als Ausgangspunkt. Gutenberg behandelt sie bis heute eher als nachträgliches Problem.
Natürlich heißt das nicht automatisch, dass EmDash CMS schon die fertige Antwort auf alles ist. Dafür ist das Projekt zu neu. Aber der Release macht etwas sehr klar: Die Frage, wie Content gespeichert wird, ist keine technische Fußnote mehr. Sie entscheidet darüber, wie anschlussfähig ein CMS an die Realität moderner Inhalte überhaupt noch ist.
Was WordPress heute nachträglich reparieren muss
Dass WordPress VIP mit der Block Data API Gutenberg Inhalte als strukturiertes JSON bereitstellt, ist der deutlichste Hinweis auf das eigentliche Problem. Diese API erweitert Gutenberg nicht einfach nur. Sie kompensiert eine Speicherlogik, die Struktur nicht sauber an die erste Stelle setzt. WordPress VIP benennt den Nutzen selbst entsprechend klar: HTML Parsing soll dadurch vermieden werden.
Ähnlich verhält es sich mit parse_blocks() und dem WP_Block_Processor. Auch hier zeigt sich kein luxuriöses Zusatzfeature, sondern der Bedarf, gespeicherte Inhalte wieder effizient in eine nutzbare Struktur zu überführen. Dass WordPress dafür eigene Verarbeitungslogik und zusätzliche Optimierungen braucht, macht den Konstruktionsfehler eher sichtbarer als kleiner.
Genau deshalb wirkt die aktuelle Entwicklung bei WordPress weniger wie konsequente Weiterentwicklung als wie nachträgliche Symptomarbeit. Es entstehen immer neue Werkzeuge, um wieder an die Struktur heranzukommen, die beim Speichern nie sauber priorisiert wurde. Und genau an diesem Punkt wird der Unterschied zu EmDash CMS scharf. Dort muss Struktur nicht zurückgewonnen werden. Sie ist von Anfang an Teil des Inhalts.
Was man aus EmDash CMS für Gutenberg lernen sollte
Die wichtigste Lehre aus EmDash CMS ist deshalb nicht, dass WordPress plötzlich obsolet wäre. Die eigentliche Lehre ist, dass Content im Web heute anders gedacht werden muss. Solange Inhalte vor allem als Ausgabe verstanden werden, wirkt HTML als Speicherformat noch irgendwie ausreichend. Sobald Inhalte aber über APIs, unterschiedliche Frontends, Personalisierung und KI Systeme in neue Kontexte wandern, reicht diese Logik nicht mehr. Dann muss Struktur nicht nachträglich freigelegt, sondern von Anfang an mitgespeichert werden.
Für Gutenberg ist das die eigentliche Zumutung. Nicht, weil das System keine Blöcke hätte oder intern unstrukturiert wäre. Sondern weil diese Struktur bis heute nicht konsequent zum Kern des Speichermodells gemacht wurde. Genau deshalb produziert WordPress rund um Gutenberg immer neue Hilfskonstruktionen, während EmDash CMS dieselbe Frage eine Ebene früher beantwortet. Die entscheidende Architekturfrage lautet heute eben nicht mehr nur, wie Inhalte editiert werden. Sie lautet, in welcher Form ein System Inhalte dauerhaft begreift.
Und genau hier liegt auch die größere Konsequenz über WordPress hinaus. Das Web braucht nicht einfach nur modernere Editoren. Es braucht Systeme, die Content wieder ernster als Daten behandeln. EmDash CMS macht diesen Punkt gerade deshalb so sichtbar, weil es nicht bloß ein neues Interface verspricht, sondern ein anderes Verständnis von Inhalt. Für Gutenberg ist das kein kleiner Denkanstoß, sondern eine ziemlich direkte Erinnerung daran, wo der eigene Konstruktionsfehler seit Jahren liegt.
