EmDash statt WordPress? Ein Leitfaden für Agenturen

Geprüft mit EmDash 1.1.0 und WordPress 7.1.2 am 5. Oktober 2026. Überarbeitet für EmDash 1.2.0 am 7. Oktober 2026. Was sich geändert hat, steht am Ende des Leitfadens.

Wann hast du dir das letzte Mal überlegt, ob WordPress für deine Kunden noch die richtige Plattform ist? Seit EmDash 1.0 draussen ist und überall als moderne WordPress-Alternative auftaucht, stellen sich diese Frage viele Agenturen. Wenn deine Agentur hundert WordPress-Sites betreut, ist die Antwort allerdings keine Bauchentscheidung, denn jede zweite Plattform muss dein Team kennen, pflegen und aktualisieren.

Ich kenne beide Seiten. Ich führe selbst eine WordPress-Agentur und arbeite gleichzeitig als Maintainer an EmDash mit, unter anderem am Import von WordPress-Inhalten. Mir geht es in diesem Leitfaden nicht darum, dir eine Plattform zu verkaufen, sondern darum, ehrlich zu zeigen, wo EmDash Vorteile hat, wo WordPress klar besser ist und was ein Wechsel in der Praxis kostet.

Deshalb habe ich mich nicht auf Doku und Ankündigungen verlassen, sondern es selbst ausprobiert: Ich habe eine typische Agentur-WordPress-Site nach EmDash importiert und danach je drei EmDash- und WordPress-Sites auf eine neue Version gehoben. Einiges hat mich positiv überrascht, anderes hat mich recht geärgert, und ein Teil der Fehler steckt sogar in Code, den ich selbst geschrieben habe. Zu jeder Aussage findest du im Text einen Link auf die Quelle, damit du alles selbst nachprüfen kannst.

Neue Projekte ja, grosse Umzüge nein

EmDash kann sich heute für neue Projekte lohnen, die vor allem aus Inhalten bestehen, also für Firmen-Sites, Magazine, Dokumentationen oder mehrsprachige Auftritte, bei denen die Redaktion keinen Page Builder braucht. Für Shops, Mitgliederbereiche und Sites, die mit Elementor oder Divi gebaut sind, bleibt WordPress die bessere Wahl.

Bestehende Sites umzuziehen lohnt sich nur in einfachen Fällen, denn EmDash führt kein PHP aus. Dein Theme und deine Plugins kommen also nicht mit, sondern nur die Inhalte, und alles andere baust du neu.

Am meisten überrascht haben mich beim Testen die Updates. Eine EmDash-Site aktualisiert sich nie von selbst, jedes Update ist eine Codeänderung mit neuem Deployment, und zwar Site für Site. Bei einem grossen Portfolio entscheidet das über die laufenden Kosten mehr als die einmalige Migration.

Was ist EmDash?

Aber fangen wir doch mal vorne an. EmDash ist ein Open-Source-CMS, das direkt in einer Astro-Website läuft, sodass Admin, Inhalte und Website eine einzige Anwendung bilden. Gehostet wird meist auf Cloudflare, EmDash läuft aber auch auf einem normalen Node.js-Server. Die Lizenz ist MIT, und hinter dem Projekt steht Cloudflare.

Die Projektseite Why EmDash ist übrigens erfrischend ehrlich. Sie empfiehlt EmDash für Agentur-Sites, die an Kundenredaktionen übergeben werden, und für WordPress-Projekte, deren Frontend ohnehin neu gebaut wird, sagt aber auch klar, dass Datenbank, Backups und Updates bei dir liegen.

Welche Kundenprojekte passen?

Wo EmDash Vorteile hat

Headless ohne Klebstoff

Wenn du WordPress headless betreibst, also nur als Datenquelle für ein separates Frontend, kennst du die ganze Schicht dazwischen mit API, Webhooks, Build-Triggern, Caches und einem zweiten Hosting für PHP. Jedes dieser Teile kann kaputtgehen, und meistens tut es das ausgerechnet nachts. Bei EmDash fällt diese Schicht komplett weg, weil die Website ihre Inhalte direkt abfragt und alles in einem einzigen Deployment rausgeht.

Inhalte mit klarer Struktur

Inhalte sind in EmDash sauber strukturiert, auch der Fliesstext, der nicht als HTML gespeichert wird. Kunden können deshalb kein wildes Inline-Styling mehr einfügen, das dein Design zerschiesst, und Entwickler bekommen automatisch erzeugte TypeScript-Typen, sodass ein fehlendes Feld schon im Editor auffällt und nicht erst auf der Live-Site.

Vorschau für Kunden und für jeden Branch

Vorschau-Links funktionieren ohne Login und laufen nach einer Stunde von selbst ab, was für Kundenabnahmen sehr praktisch ist. Auf Cloudflare bekommt zudem jeder Git-Branch eine eigene Vorschau-URL. The Weekly Dash arbeitet genau so, und das möchte ich im Alltag nicht mehr missen.

Login ohne Passwort

Angemeldet wird mit Passkeys, und auf Wunsch lassen sich Google, GitHub oder Microsoft zuschalten. Admin-Passwörter, die jemand stehlen oder wiederverwenden könnte, gibt es damit nicht mehr. Eine klassische Zwei-Faktor-Anmeldung per App-Code fehlt allerdings, und wenn dein Kunde genau das verlangt, solltest du es vor dem Angebot klären.

Plugins mit klaren Rechten

Plugins können in einer Sandbox laufen und bekommen dort nur die Rechte, die sie vorher angemeldet haben, etwa "darf E-Mails senden". In WordPress darf dagegen jedes Plugin grundsätzlich alles. Warum das für Agenturen weniger bringt, als es zuerst klingt, erkläre ich weiter unten bei der Sicherheit.

Gebaut für KI-Agents

Jede EmDash-Site bringt eine Schnittstelle für KI-Agents mit (MCP), über die ein Agent Inhalte anlegen und bearbeiten kann, und zwar mit denselben Rechten wie ein Mensch im Admin. Dieser Artikel ist übrigens genau auf diesem Weg auf die Site gekommen. Was ein Agent damit heute schon baut, zeigt Daniels Test von EmDash Build.

Günstiges Hosting

Auf Cloudflare kostet der bezahlte Plan 5 Dollar im Monat pro Konto und nicht pro Site, und für kleine und mittlere Sites reicht das Inklusivvolumen meist weit. Einen unabhängigen Geschwindigkeitsvergleich zwischen EmDash und WordPress habe ich allerdings nicht gefunden.

Wo WordPress besser ist

Keine Seitenbäume

EmDash kennt keine Eltern-Kind-Seiten. Menüs lassen sich verschachteln, Seiten aber nicht, und auch Inhalte von Hand zu sortieren geht nur über Umwege. Für viele Firmen-Sites ist das ein echter Stolperstein, und die Community wünscht es sich schon lange (Discussion #3375).

Kein Page Builder

Das ist Absicht, denn EmDash will strukturierte Inhalte verwalten und kein Baukasten sein. Wer seinen Kunden die Freiheit von Elementor verkauft hat, wird hier nicht glücklich.

ACF nur teilweise

Einfache Felder sind kein Problem, Repeater und Flexible Content lassen sich aber nur eingeschränkt nachbauen, und bedingte Felder sowie Options-Pages fehlen ganz (Feldtypen).

Feste Rollen und kein Freigabeprozess

Es gibt fünf feste Rollen, eigene lassen sich nicht anlegen (#2332), und einen Status "zur Prüfung" gibt es ebenfalls nicht. Ein Tipp aus dem Code: Gib Redakteur:innen beim Kunden die Rolle Author oder Editor, denn mit der Rolle Contributor können sie ihre eigenen Entwürfe später nicht mehr bearbeiten.

Das Admin spricht nicht alle Landessprachen

Für Schweizer Agenturen kann ein Projekt genau hier kippen. Deutsch ist komplett übersetzt, Französisch nur etwa zur Hälfte und Italienisch gar nicht, und fehlende Texte erscheinen auf Englisch. Zeig das Admin also einer Redaktion in der Romandie oder im Tessin, bevor du es verkaufst.

Wenige Plugins

WordPress hat über 74.000 kostenlose Plugins, die EmDash-Registry hatte bei meinem Test gerade einmal 38. Für Formulare, SEO, Analytics und Newsletter findest du etwas, für Shops nichts, und jedes fehlende Plugin wird zu deinem eigenen Code.

Keine Shops

Ein Gegenstück zu WooCommerce gibt es nicht. Es existieren zwar erste Projekte von Dritten, aber keinem davon würde ich heute den Umsatz eines Kunden anvertrauen.

Suche auf Deutsch

Die eingebaute Suche versteht nur englische Wortstämme. Wenn die Suche für einen deutsch- oder französischsprachigen Kunden wichtig ist, solltest du sie mit echten Inhalten testen oder gleich einen externen Suchdienst einplanen.

Ein junges Projekt

EmDash ist enorm schnell gewachsen und hat bis Version 1.1.0 in rund einem halben Jahr 60 Versionen veröffentlicht. Seit 1.0 kommen grössere Brüche nur noch mit Hauptversionen, eine Langzeit-Version mit Sicherheitsupdates für ältere Releases gibt es aber nicht. WordPress hat dagegen zwanzig Jahre Erfahrung, ein riesiges Ökosystem und unzählige Agenturen, die jedes Problem schon einmal gelöst haben.

Der Praxistest: was beim Import ankommt

Ich wollte keine Demo-Site importieren, die zufällig perfekt passt, und habe deshalb eine gebaut, wie ich sie aus dem Agenturalltag kenne: WordPress 7.1.2 mit Yoast SEO, ACF-Feldern über Secure Custom Fields und den offiziellen Theme-Testdaten, dazu ein eigener Post Type für Referenzen, Unterseiten, ein Kontaktformular, Menüs, Kommentare und geplante Beiträge. Insgesamt waren das rund hundert Einträge und 37 Bilder.

EmDash bietet zwei Wege für den Import. Beim ersten lädst du die normale WordPress-Exportdatei hoch, beim zweiten installierst du ein Exporter-Plugin auf der WordPress-Site, das zusätzlich ACF-Felder und SEO-Daten mitnimmt. Einen kleinen Umweg gab es gleich zu Beginn: Weil EmDash keine Bilder von lokalen Adressen holt (#3815), musste mein Test-WordPress über einen öffentlichen Tunnel erreichbar sein.

Fünfundzwanzig Sekunden klingen erst einmal grossartig, aber nach dem Nachzählen sah es anders aus. Die eigentliche Arbeit steckt in dem, was nicht oder nur halb ankommt, und das passiert oft ohne jede Meldung:

• Hier bin ich selbst auf die Nase gefallen: Ich habe in eine Site mit Demo-Inhalten importiert, und weil es dort schon eine Seite "about" gab, hat der Import meine eigene "about"-Seite einfach übersprungen. Importiere also immer in eine leere Site.
• Ein Post Type mit Bindestrich im Namen (team-member) kam über das Plugin gar nicht an, und solche kleinen, aber gut sichtbaren Fehler ärgern mich als Maintainer besonders.
• Zwei Beiträge mit sehr vielen Schlagwörtern verloren beim Import alle ihre Kategorien und Schlagwörter.
• Normale Gutenberg-Blöcke kamen gut an, ein Button verlor aber seinen Link, ein Block eines Drittanbieters verschwand ganz, und der Shortcode des Kontaktformulars stand danach als Text auf der Seite, was dein Kunde womöglich vor dir entdeckt.
• Links auf PDFs und Hintergrundbilder zeigten weiterhin auf den alten WordPress-Server und wären gebrochen, sobald du ihn abschaltest.
• Weiterleitungen von alten URLs musst du selbst anlegen, denn Listen importieren kann EmDash noch nicht (#2291).

Vier dieser Fehler habe ich nach dem Test selbst behoben, und seit EmDash 1.2.0 sind die Fixes drin: Beiträge mit vielen Schlagwörtern behalten ihre Begriffe (#3889), Buttons ihren Link (#3893), Links auf PDFs und Hintergrundbilder zeigen auf die importierten Dateien (#3896), und geplante Beiträge behalten ihren Termin (#3895). Die Tabelle oben zeigt den Stand mit 1.1.0. Anderes ist gemeldet, aber noch offen, etwa die fehlenden Seitenbäume (#3819) und die fehlenden Felder beim Datei-Import (#3820). Bis alles behoben ist, solltest du nach jedem Import eine Aufräumrunde einplanen.

Noch ein Hinweis zum Exporter-Plugin: Die Doku verlangt einen Migrationsschlüssel, den die veröffentlichte Version 1.0.0 gar nicht kennt, weil er erst in einer neueren Version steckt, die ich geschrieben habe und die noch nicht veröffentlicht ist (PR #8). Das ist mir ehrlicherweise recht peinlich. Mit Version 1.0.0 klappt es trotzdem, wenn du im Admin die URL der Site eingibst und "Anmeldedaten manuell eingeben" wählst.

ACF-Felder: alles da, aber unpraktisch

Das Plugin bringt alle ACF-Werte mit, allerdings nicht in einer brauchbaren Form. Ein Datum wird zur Zahl 20250115, ein Bild zur alten WordPress-ID, und ein Repeater wird in viele Einzelfelder zerlegt (kennzahlen_0_label, kennzahlen_1_label und so weiter). Verloren geht also nichts, aber das Frontend kann mit dieser Struktur nicht direkt arbeiten.

Bei einfachen Feldern spielt das kaum eine Rolle. Bei Repeatern, Bildern und Beziehungen lohnt sich dagegen ein eigenes Import-Skript, das die Daten gleich in die richtige Struktur bringt und das du so oft laufen lassen kannst, wie du willst. Und den Umzug mehrmals zu proben, lohnt sich sowieso.

Themes und Plugins: immer neu

Dein WordPress-Theme wird zu einem Astro-Projekt, und das ist ein Neubau, auch wenn der Porting-Guide und ein mitgelieferter KI-Skill dabei helfen. Ein sauberes Theme mit Gutenberg-Inhalten ist in wenigen Tagen portiert, eine Builder-Site baust du dagegen Seite für Seite neu.

Eigene Plugins schreibst du in TypeScript neu, und wenn deine Agentur jahrelang eigene Plugins gepflegt hat, ist das wohl der Punkt, der am meisten schmerzt. Der Leitfaden zum Portieren gibt aber einen guten Rat: Portiere nichts, was EmDash schon kann. Caching, Sitemaps, SEO-Felder, Redirects und Suche sind bereits eingebaut, sodass ein Teil deines Plugin-Ordners einfach wegfällt.

Für den Rest gibt es Hooks wie in WordPress, aber deutlich weniger, und Plugins in der Sandbox haben auf Cloudflare enge Zeitlimits. Wie lange das Portieren eines typischen Plugins dauert, hat bisher niemand veröffentlicht. Ehrlich schätzen lässt sich das nur, indem du eines portierst und die Stunden zählst.

Was eine Migration günstig oder teuer macht

Updates: der grösste Unterschied zu WordPress

Für ein Portfolio wird es hier ernst. Ich habe deshalb drei EmDash-Sites von Version 1.0.1 auf 1.1.0 gehoben und zum Vergleich drei ältere WordPress-Sites samt Plugins aktualisiert.

Bei EmDash gibt es keinen Update-Knopf, das Admin zeigt lediglich einen Hinweis, dass eine neue Version verfügbar ist. Das Update selbst machst du im Code, indem du die Paketversion anhebst, die Site neu baust und deployst. Auf meinen Testsites dauerte das lokal rund zehn Sekunden pro Site, dazu kommt die Zeit für Build und Deployment in deiner Pipeline. Die Datenbank hat sich beim ersten Aufruf danach selbst angepasst, und die Inhalte blieben unversehrt. Wie das Schritt für Schritt geht, zeige ich in EmDash aktualisieren.

Eine Panne habe ich dabei aus Versehen gefunden: Wegen eines Tippfehlers in meinem Befehl wurde auf einer Site nur das Hauptpaket aktualisiert, während das Cloudflare-Paket auf der alten Version blieb, und die Site baute trotzdem ohne jede Warnung. Aktualisiere die EmDash-Pakete also immer gemeinsam, und wenn du Updates automatisierst, fasse sie zu einer Gruppe zusammen.

WordPress aktualisiert sich bei neuen Installationen dagegen sogar bei grossen Versionen von selbst, und mit Werkzeugen wie ManageWP oder MainWP hältst du Hunderte Sites von einer Oberfläche aus aktuell. Etwas Vergleichbares gibt es für EmDash noch nicht.

Der EmDash-Weg hat trotzdem einen Vorteil: Jedes Update läuft als Pull Request mit Vorschau und Tests, sodass sich auf keiner Kundensite etwas ändert, ohne dass es dokumentiert ist. Den Satz "seit dem Update am Dienstag ist das Formular weg" hörst du dann seltener.

Für ein Portfolio heisst das aber auch, dass jedes Release ein Update pro Site bedeutet. Weil Sicherheitskorrekturen nur für die neueste Version erscheinen, kannst du alte Versionen nicht einfach stehen lassen. Wenn deine Sites gleich aufgebaut sind und ein Bot die Updates vorbereitet, ist das gut machbar, wenn jede Site ein Einzelstück ist, wird es zur Qual.

Hosting und Kosten

Jede EmDash-Site auf Cloudflare braucht unter anderem einen zeitgesteuerten Job, einen sogenannten Cron-Trigger, ohne den geplante Beiträge nicht online gehen. Der Gratis-Plan erlaubt nur fünf davon und reicht damit für etwa fünf Sites, weshalb du für Agenturarbeit den bezahlten Plan ab 5 Dollar im Monat pro Konto brauchst (Limits).

Ob du für jeden Kunden ein eigenes Konto führst oder mehrere Kunden in einem bündelst, ist deine Entscheidung, technisch geht beides. Was eine typische Site im Monat tatsächlich kostet, hat noch niemand veröffentlicht, deshalb lohnt es sich, das beim ersten eigenen Projekt zu messen.

Für die Datenbank macht Cloudflare automatisch Backups, mit denen du bis zu 30 Tage zurückspringen kannst, Bilder brauchen aber eine eigene Sicherung. Und falls du später wieder weg willst: Der Code ist Open Source und läuft auch ohne Cloudflare, dann allerdings ohne einige Extras.

Sicherheit: was die Sandbox kann und was nicht

Die Zahlen für WordPress sind deutlich. Patchstack zählte 2025 über 11.000 neue Sicherheitslücken, 91 % davon in Plugins, und bis zum ersten Angriff vergehen im Mittel gerade einmal fünf Stunden.

EmDash setzt dagegen auf die Sandbox, in der Plugins von Drittanbietern nur die Rechte bekommen, die sie vorher angemeldet haben, und das ist ein echter Fortschritt. Für Agenturen hat die Sache aber einen Haken, denn die Plugins, die du selbst schreibst, laufen meist nicht in der Sandbox. Alles, was etwas im Editor oder auf der Website anzeigt, braucht volle Rechte, und für deinen eigenen Code gilt deshalb dasselbe wie bei WordPress: Du musst ihn selbst sauber prüfen.

Trotzdem fällt einiges weg, nämlich die PHP-Laufzeit, die Admin-Passwörter und die vielen Plugins aus unterschiedlichsten Quellen. Bei Sites mit wenigen Plugins verschwindet damit die grösste Gruppe typischer WordPress-Vorfälle, für Sites mit viel Eigenentwicklung ist der Gewinn deutlich kleiner.

Was die Kritiker sagen

Matt Mullenweg, der Gründer von WordPress, lobte EmDash als "very solid", schrieb aber auch, die Sandbox breche zusammen, sobald man sich anschaue, was die meisten WordPress-Plugins tun (Blogpost). Für Agenturen hat er damit recht.

Search Engine Journal kritisierte, EmDash sei für Entwickler gebaut und die besten Funktionen hingen an Cloudflare (Artikel). Auch das stimmt, wiegt für Agenturen aber weniger schwer, weil die Technik dein Team einrichtet und der Kunde nur das Admin sieht.

WP Umbrella riet Agenturen, EmDash erst 12 bis 18 Monate nach Version 1.0 neu zu bewerten (Artikel). Für den Umzug eines ganzen Portfolios halte ich das für einen vernünftigen Rat, und mein Test bestätigt ihn. Für ein, zwei Neubauten heisst Warten aber auch, dass dir später die Erfahrung fehlt.

Pilotplan: so startest du

1. Sortiere zuerst dein Portfolio. Geh deine Sites an einem Nachmittag durch. Shop, Page Builder, Mitgliederbereich oder eine italienische Redaktion bedeuten, dass die Site vorerst bei WordPress bleibt. Seitenbäume, komplexe ACF-Felder und eigene Plugins machen einen Umzug teurer, ein ohnehin geplantes Redesign macht ihn günstiger.
2. Bau dann eine neue Site auf EmDash. Nimm ein neues Projekt mit einer Kundenredaktion, die dir ehrlich Rückmeldung gibt, und richte Updates und Backups vor dem Launch ein und nicht erst danach.
3. Zieh eine einfache Site testweise um. Importiere in eine leere EmDash-Site und vergleiche alt und neu Seite für Seite. Dauert es mehr als doppelt so lange wie geschätzt, hör auf und schreib auf, wo die Zeit hingegangen ist.
4. Entscheide mit Zahlen. Nach drei Monaten kennst du die Stunden pro Projekt, den Aufwand pro Update und die Rückmeldungen deiner Kunden. Leg das neben deine heutigen WordPress-Wartungskosten und entscheide erst dann.

Was mir persönlich fehlt

Als Maintainer darf ich mir hier gleich selbst etwas wünschen. Manches ist Motzen auf hohem Niveau, die ersten beiden Punkte sind es aber nicht:

• Seitenbäume, denn so viele Kundensites leben davon, dass sie ohne sie bei WordPress bleiben.
• Einen echten Freigabeprozess mit Benachrichtigung.
• Ein italienisches und ein vollständig französisches Admin, was für die Schweiz kein Detail ist.
• Ein Werkzeug, das Updates über viele Sites gleichzeitig ausrollt.
• Einen Import, der laut wird, wenn etwas schiefgeht, und das geht auch an meine eigene Adresse.

Vor- und Nachteile im Überblick

Vorteile von EmDash:

• Admin, Inhalte und Website in einem Projekt
• Saubere Inhaltsstruktur und Vorschau für jeden Branch
• Login mit Passkeys statt Passwörtern
• Updates mit Pull Request statt Überraschungen
• Günstiges Hosting

Nachteile von EmDash:

• Keine Seitenbäume und keine eigenen Rollen
• Wenige Plugins und kein Shop
• Der Import braucht immer eine Aufräumrunde
• Jedes Update muss pro Site ausgerollt werden
• Kein italienisches Admin

Fazit

EmDash ist eine interessante zweite Plattform für Agenturen, die schon mit modernen Web-Werkzeugen und Git arbeiten und Content-Sites für Kunden bauen, die keinen Page Builder brauchen. Du bekommst saubere Inhalte, sichere Logins, gute Vorschauen und günstiges Hosting, baust dafür aber selbst, was es bei WordPress als Plugin gibt, und rollst jedes Update selbst aus.

Shops, Mitgliederbereiche, Builder-Sites und Kunden, die selbst Plugins installieren wollen, sind bei WordPress besser aufgehoben, und vorerst gilt das auch für alles, was Seitenbäume, Freigabeprozesse oder ein italienisches Admin braucht.

Unterm Strich steht für ein WordPress-Portfolio kein grosser Umzug an. Die spannende Frage ist eher, ob einzelne neue Content-Sites auf EmDash besser aufgehoben wären, und die beantwortet ein Pilot von drei Monaten besser als jeder Leitfaden.

Wie sieht es bei dir aus? Hast du EmDash schon bei einem Kunden im Einsatz, oder bleibst du bewusst bei WordPress? Schreib es in die Kommentare. Und wenn beim Testen etwas bricht, melde es im EmDash-Repository, ich lese dort mit.

Wenn ein neues EmDash-Release eine der genannten Lücken schliesst, passe ich den Abschnitt an und vermerke es am Ende des Artikels.