Am 1. April 2026 stellte Cloudflare ein Projekt vor, das viele zunächst für einen Aprilscherz hielten: EmDash, ein quelloffenes Content-Management-System, das als „geistiger Nachfolger“ von WordPress gilt. Das Produkt ist sehr real, unter der MIT-Lizenz veröffentlicht, in TypeScript geschrieben und auf Astro aufgebaut. Fünf Monate später steht es noch bei Version 0.1.0, einer Entwicklervorschau. Genug, um die Architektur zu beurteilen, zu früh, um von einem Ökosystem zu sprechen.
Was EmDash ist und was nicht
EmDash ist kein WordPress-Fork. Keine Zeile des historischen CMS wurde übernommen: Das Projekt wurde von Grund auf neu geschrieben, mithilfe von Coding-Agenten, mit dem Ziel der Funktions- statt der Code-Kompatibilität. Technisch installiert sich EmDash als Astro-Integration und liefert ein Admin-Panel, eine Medienbibliothek, eine REST-API und ein Erweiterungssystem.
Die Laufzeitumgebung ist Cloudflare Workers mit seiner V8-Isolat-Architektur, mit Node.js-Kompatibilität. Das Deployment bleibt offen: Workers, aber auch Netlify oder Vercel. Eine Einschränkung zählt, und sie ist strukturell: Die Funktion, die EmDash auszeichnet — die Sandbox für Erweiterungen — funktioniert nur auf Cloudflares eigener Infrastruktur vollständig.
Die zentrale Wette: jede Erweiterung isolieren
EmDashs Nutzenversprechen stützt sich auf eine Statistik, die Cloudflare hervorhebt: Die überwiegende Mehrheit der Sicherheitsvorfälle auf WordPress-Seiten stammt von Erweiterungen. Die gewählte Antwort ist architektonisch. Jede Erweiterung deklariert ihre Fähigkeiten in einem Manifest und läuft in ihrem eigenen Isolat, ohne direkten Zugriff auf die Datenbank oder das Dateisystem.
{
"name": "newsletter-widget",
"version": "1.0.0",
"capabilities": {
"content": ["read"],
"network": ["api.example.com"],
"storage": ["kv:newsletter"]
}
}Das Prinzip sind deklarative Berechtigungen: Eine Erweiterung darf nur berühren, was ihr Manifest ausdrücklich erlaubt. Auf dem Papier schließt das Modell das häufigste Einfallstor für WordPress-Kompromittierungen. In der Praxis beruht es auf Cloudflares Dynamic Workers, weshalb die Sandbox auf klassischem Hosting ihr Versprechen nicht hält.
Jede Erweiterung in ihrer eigenen Sandbox zu isolieren, beantwortet das Problem, das WordPress am teuersten zu stehen kommt: seine Erweiterungen.
EmDash gegen WordPress
Die folgende Tabelle stellt die beiden Ansätze bei den Punkten gegenüber, die wirklich über eine CMS-Wahl entscheiden.
| Kriterium | EmDash | WordPress |
|---|---|---|
| Sprache | TypeScript | PHP |
| Basis | Astro-6-Integration | Monolithischer Kern |
| Erweiterungen | Isoliert, deklarierte Fähigkeiten | Direkter Kernzugriff |
| Ausführung | Isolate (Workers), Sandbox | Geteilter PHP-Prozess |
| Lizenz | MIT | GPL |
| KI-Integration | Nativer MCP-Server | Über Dritt-Erweiterungen |
| Ökosystem | Kaum vorhanden | Riesig, ausgereift |
| Reife | 0.1.0, Vorschau | Seit 20 Jahren bewährt |
Achtung: EmDash ist eine 0.1.0-Vorschau. Kein Erweiterungs-Ökosystem, kein visueller Seitenbaukasten und ein Sicherheitsargument, das Cloudflare-Hosting voraussetzt, um voll wirksam zu sein. Nichts davon macht es heute zu einem Kandidaten für die Migration einer Produktionsseite.
Von WordPress migrieren: was übernommen wird
EmDash verlangt keinen Neuanfang auf einer leeren Seite. Das Projekt akzeptiert die WXR-Exportdateien von WordPress und liefert eine Export-Erweiterung auf der WordPress-Seite. Die Medienbibliothek wird automatisch importiert, und benutzerdefinierte Inhaltstypen werden in Astro-Content-Collections umgewandelt.
# Ein Astro-Projekt erstellen und EmDash hinzufügen
npm create astro@latest demo-seite
cd demo-seite
npx astro add emdash
# Einen WordPress-Export importieren (WXR-Datei)
npx emdash import ./wordpress-export.xmlAuf einer einfachen Redaktionsseite ist der Inhalt in Minuten übernommen. Die Schwierigkeit liegt woanders: in allem, was eine echte WordPress-Seite rund um den Inhalt mitbringt — Fach-Erweiterungen, ein maßgeschneidertes Theme, SEO-Einstellungen, Formulare. Dafür gibt es in einem noch leeren Ökosystem keine fertige Entsprechung.
Ein CMS für Agenten gedacht
Wo WordPress künstliche Intelligenz über sukzessive Erweiterungen aufgepfropft hat, baut EmDash sie in das Fundament ein. Das CMS bringt einen nativen MCP-Server mit: Ein Agent kann Inhalte lesen, erstellen oder aktualisieren, ohne zusätzliche Werkzeuge, im direkten Dialog mit der Verwaltung. Hinzu kommen Agent Skills und eine auf Automatisierung ausgelegte Kommandozeile, die das Steuern des CMS per Skript oder Agent so selbstverständlich machen wie den Klick im Panel.
Zwei Voreinstellungen setzen diese Ausrichtung fort. Die Authentifizierung stützt sich auf Passkeys statt auf ein Benutzername-Passwort-Paar, was den Brute-Force-Angriffen auf die Anmeldeseite den Boden entzieht. Und eine x402-Zahlungsunterstützung ist auf Kernebene vorgesehen, um Zugang oder Inhalte abzurechnen, ohne eine E-Commerce-Erweiterung. Bausteine, die zusammengenommen ein CMS zeichnen, das für ein Web gedacht ist, in dem Agenten ebenso zählen wie Besucher.
Was noch fehlt
Die Liste der Fehlstellen ist ebenso aufschlussreich wie die der Funktionen. EmDash bietet keinen visuellen Seitenbaukasten, obwohl genau das die Vormachtstellung von WordPress bei Nicht-Entwicklern begründet hat. Der Katalog an Erweiterungen und Themes ist nahezu leer, was alles, was eine Erweiterung mit einem Klick löste, auf das Team zurückverlagert. Suchmaschinenoptimierung, feingliedrige Rollenverwaltung und fortgeschrittene Internationalisierung müssen sich im Feld erst noch bewähren.
Bleibt schließlich die Abhängigkeit von Cloudflare für die Sandbox. Das CMS lässt sich anderswo deployen, doch sein stärkstes Verkaufsargument verliert außerhalb der Infrastruktur, in der es entstanden ist, an Kraft. Ein Punkt, den man bedenken sollte, bevor man es zu einer Architektursäule macht.
Für wen und ab wann
EmDash interessiert zuerst Teams, die bereits in der TypeScript- und Astro-Welt zu Hause sind, mit einem Deployment auf Workers vertraut und für das Sicherheitsargument empfänglich. Für einen Prototyp, ein Blog-Mockup oder eine ernsthafte Technologiebeobachtung ergibt der Test schon jetzt Sinn. Für eine Kundenseite in Produktion rät die Vorsicht zum Abwarten: Eine 0.1.0-Version ohne Ökosystem bietet nicht die Garantien, die ein abgerechnetes Projekt verlangt. Die Frage der CMS-Wahl bleibt offen und verdient es, Projekt für Projekt gestellt zu werden.
Was bleibt
EmDash bringt ernstzunehmende Architekturideen mit: durchgängiges TypeScript, nach Fähigkeiten isolierte Erweiterungen, ein integrierter MCP-Server für Agenten. Seine Grenzen sind ebenso deutlich: eine 0.1.0-Vorschau, ein nicht vorhandenes Ökosystem, eine an Cloudflare gebundene Sandbox. In diesem Stadium ist es ein Projekt zum Beobachten und Prototypisieren, keine Produktionsbasis. Die Richtung aber verdient die Aufmerksamkeit aller, die täglich mit Erweiterungslücken leben.
In meinen Projekten bleibt WordPress aus einem guten Grund die Standardwahl: sein Ökosystem. Aber die Idee von EmDash spricht mich an, weil ich unverhältnismäßig viel Zeit damit verbringe, Dritt-Erweiterungen im Auge zu behalten. Ein Modell, in dem eine Erweiterung nur berühren darf, was sie deklariert hat, ist genau die Garantie, die WordPress fehlt. Ich migriere nichts auf 0.1.0, aber ich lasse das Projekt in einem Tab offen — und teste es an einem Nebenprojekt vor allen anderen. — Simon Janvier
Zum Weiterlesen
Primärquelle: EmDash, the open-source spiritual successor to WordPress (Cloudflare-Blog).
