"Aber mein Kunde muss das bearbeiten können." Was ich nach 3 Astro-Migrationen tatsächlich übergebe.

Jedes Mal, wenn ich einem Kunden vorschlage, WordPress zu verlassen, kommt derselbe Satz innerhalb von zwei E-Mails.

"Aber wir müssen das selbst bearbeiten können."

Berechtigte Frage. Genau genommen ist es nicht mal eine Frage, es ist die ganze Entscheidung. Ich habe inzwischen drei WordPress-zu-Astro-Migrationen für Kunden gemacht, und der technische Teil war der einfache. Weiterleitungen, Templates, Formulare, Build-Pipeline: alles in einer Woche lösbar. Was ich beim ersten Mal falsch gemacht habe, war die Annahme, die CMS-Wahl sei ein Detail, das ich am Ende klären kann. Sie ist kein Detail. Sie entscheidet darüber, ob dein Kunde im sechsten Monat zufrieden ist oder still eine andere Agentur fragt, ob sie ihn wieder auf WordPress setzt.

Die meisten "nimm doch einfach Astro"-Beiträge winken das mit einem Link auf die Doku-Seite mit vierzig Integrationen weg. Das ist keine Antwort. Ein Astro-CMS für Kunden auszuwählen ist die schwerste Entscheidung im ganzen Projekt, also hier, was ich Leuten tatsächlich gebe, was es 2026 kostet und wo jede Option auseinanderfällt.

Das eigentliche Problem ist nicht das CMS, sondern der Build-Schritt

Und jetzt das, wovor niemand die Kunden warnt. In WordPress ist Bearbeiten eine Handlung. Du änderst ein Wort, klickst auf Aktualisieren, lädst den Tab neu, das Wort ist anders. Das ganze mentale Modell lautet: "Die Website ist ein Ding, in das ich tippe."

Eine statische Astro-Seite ist das nicht. Dein Kunde klickt auf Speichern, das CMS committet oder schreibt in eine API, ein Webhook feuert, irgendwo, was er nicht sehen kann, startet ein Build, und 40 bis 90 Sekunden später erscheint die Änderung. Nichts auf seinem Bildschirm sagt ihm, dass irgendetwas davon passiert. Also lädt er neu. Nichts. Er lädt noch mal neu. Nichts. Dann schreibt er mir: "Ich glaube, die Seite ist kaputt."

Sie ist nicht kaputt. Sie baut. Aber "bauen" ist kein Konzept, das eine Physiotherapeutin oder ein Hochzeitslocation-Betreiber irgendeinen Grund hat im Kopf zu haben, und ihnen zu sagen, sie sollen geduldig sein, ist eine miese Antwort. Die Lösung ist langweilig und funktioniert: Bau irgendwo in die Bearbeitungsoberfläche einen sichtbaren Deploy-Status ein und sag die Zahl bei der Übergabe laut dazu. "Du siehst es in etwa einer Minute." Ein Satz beim Einlernen beseitigt die meisten Supportanfragen.

Das Zweite, was sie verlieren, ist die Vorschau. In WordPress sehen sie die Seite ungefähr, während sie schreiben. Die meisten Headless-Setups geben dir ein Textfeld und ein Versprechen. Storyblok und Sanity haben das mit echtem visuellem Bearbeiten sauber gelöst. Die git-basierten Werkzeuge größtenteils nicht, und diese Lücke ist einer nicht-technischen Redakteurin wichtiger, als jede Feature-Vergleichstabelle dir sagen wird.

Drittens, und das habe ich unterschätzt: Drag-and-drop-Layout ist weg. Wenn dein Kunde vier Jahre lang Seiten in Elementor gebaut hat, versteht er sich nicht als jemanden, der Inhalte schreibt. Er versteht sich als jemanden, der Seiten gestaltet. Ihm einen strukturierten Content-Editor zu geben, ist in seinen Augen kein Downgrade, sondern die Wegnahme der einzigen gestalterischen Kontrolle, die er hatte. Manchmal ist das genau das, was du willst. Manchmal beendet es die Beziehung. Entscheide, mit welchem Fall du es zu tun hast, bevor du das Projekt zuschneidest, nicht danach.

Jedes Astro-CMS für Kunden, und was es 2026 kostet

Ich habe das alles im September 2026 geprüft, denn CMS-Preise bewegen sich, und die Hälfte der Vergleichsbeiträge, die du findest, zitiert Zahlen von 2023.

Directus ist das, worauf ich baue, also nimm das mit der angemessenen Prise Salz. Self-Hosting ist kostenlos für jede Organisation mit weniger als 5 Millionen Dollar Gesamtjahreseinnahmen, was praktisch jeden Kunden abdeckt, den ich je hatte. Die Bearbeitungsoberfläche sieht aus wie ein Datenbank-Adminpanel, weil sie im Kern eines ist, und das schneidet in beide Richtungen: Kunden, die von Excel kommen, verstehen es sofort, Kunden, die von Elementor kommen, starren es an. Der Haken ist, dass selbst gehostet heißt, dass dir der Server, die Backups und die Upgrades gehören. Das sind echte laufende Kosten, nur eben keine, die auf einer Anbieterrechnung stehen. Directus hat außerdem im Dezember 2025 seine günstige Starter-Cloud-Stufe eingestellt und ist mit v12 im April 2026 auf die neue Monospace Sustainable Core License gewechselt. Wenn du also für eine kleine Seite auf die gehostete Stufe setzen wolltest, ist diese Tür zu. Cloud startet jetzt bei rund 99 Dollar im Monat.

Sanity hat mit Abstand die beste kostenlose Stufe auf dieser Liste: 20 Plätze, Live-Vorschau und ein wirklich gutes Bearbeitungserlebnis. Growth kostet 15 Dollar pro Redaktionsplatz und Monat, reine Betrachter sind kostenlos. Sanitys visuelles Bearbeiten kommt dem "der Kunde sieht, was er ändert" am nächsten, was es in dieser Kategorie gibt. Der Preis dafür ist, dass Studio eine React-App ist, die du im Code konfigurierst, jede Schema-Änderung also eine Entwickleraufgabe ist. Für mich ist das in Ordnung. Es ist eine Abhängigkeit, die dein Kunde verstehen sollte.

Storyblok empfehle ich, wenn der ganze Einwand des Kunden visuell ist. Der visuelle Editor lässt eine Redakteurin einen Block auf einer gerenderten Vorschau der echten Seite anklicken und dort bearbeiten. Das ist das WordPress-Gefühl, ordentlich umgesetzt. Der kostenlose Plan hat einen Nutzer und einen Space, genug für eine Demo und zu wenig für ein Geschäft. Growth kostet 99 Euro im Monat für 5 Plätze, weitere Plätze 15 Euro. Growth Plus kostet 349 Dollar im Monat. Für eine fünfseitige Seite eines lokalen Betriebs ist das absurd. Für einen Kunden mit drei Leuten, die wöchentlich publizieren, ist es billiger als die Diskussion, die du sonst jeden Monat führst.

Payload ist hervorragend und ist eigentlich keine CMS-Entscheidung, sondern eine Architekturentscheidung. Payload 3 kommt als Next.js-Plugin, Admin und Frontend leben also in einer Codebasis. Wenn du auf Astro bist, betreibst du Payload ohnehin als separate App. Es ist kostenlos und MIT-lizenziert, selbst gehostete Infrastruktur landet realistisch zwischen 25 und 60 Dollar im Monat, sobald du eine Postgres-Instanz und Dateispeicher mitrechnest. Payload ist 2026 zu Figma gestoßen, wozu ich noch keine starke Meinung habe, außer der Anmerkung, dass "übernommen" eine Information ist, die in eine Fünfjahresempfehlung für Kunden einfließen sollte.

Decap CMS verdient eine Richtigstellung. Das Internet hat beschlossen, Decap sei verwaist, und ich habe es halb geglaubt. Stimmt nicht. Das Repo hat im Juni 2026 3.14.0 ausgeliefert, im Juli 3.15.0 und am 31. August 2026 3.16.0. Das ist ein echter Takt. Es ist immer noch der Nachfahre von Netlify CMS mit den technischen Altlasten, die das bedeutet, und Sveltia CMS ist die schnellere moderne Neufassung, zu der Leute migrieren, aber "Decap ist tot" ist eine Meinung von 2024, die Leute 2026 immer noch nachplappern. Schau dir die Releases-Seite selbst an, bevor du irgendwem glaubst, mir eingeschlossen.

Keystatic ist kostenlos, MIT, von Thinkmill und die sauberste git-basierte Option für Entwickler. TinaCMS ist die git-basierte mit echtem visuellem Bearbeiten, kostenlos für 2 Nutzer, TinaCloud-Pläne ab 24 Dollar im Monat und redaktioneller Workflow ab 49. Beide sind schön. Beide setzen weiterhin einen Build-Schritt zwischen Speichern und Live.

EmDash, Cloudflares quelloffener WordPress-Nachfolger, ist auf Astro gebaut, was ihn hier zum interessantesten Eintrag macht. Ich habe ihn in I Tried Cloudflare's EmDash CMS So You Don't Have To ordentlich getestet. Kurzfassung: Das gesandboxte Plugin-Modell ist wirklich die richtige Idee, und es war im April 2026 eine v0.1.0-Vorschau mit einem Marktplatz, auf dem praktisch niemand etwas veröffentlicht hat. Ich beobachte es. Ich setze dieses Jahr keinen Kundenumsatz darauf.

Die Optionen, die niemand als richtig zugeben will

Zwei meiner drei migrierten Kunden bearbeiten ihre Seite seltener als einmal im Monat. Einer davon hat in vierzehn Monaten zweimal Inhalte geändert. Beide Male war es eine Telefonnummer.

Für diesen Kunden ist jede Option oben falsch. Ein CMS aufzusetzen, ihn darauf zu schulen, es zu warten und dafür zu zahlen, damit er zweimal im Jahr eine Telefonnummer ändern kann, heißt, dass ich mein eigenes Unbehagen löse statt sein Problem. Was tatsächlich funktioniert:

"Schick mir die Änderung per Mail." Pack einen kleinen monatlichen Retainer dazu, der Inhaltsänderungen abdeckt, sagen wir 30 Minuten. Der Kunde bekommt einen Menschen, der es richtig macht, du bekommst eine wiederkehrende Beziehung, und niemand wartet ein CMS, das niemand öffnet. Das ist häufiger die richtige Antwort, als die Webentwicklungsbranche laut zuzugeben bereit ist.

Eine Markdown-Datei im Repo, bearbeitet über GitHubs Web-Editor. Kostenlos, versioniert, und wenn der Kunde technisch genug ist, um Kommentare in Google Docs zu benutzen, kriegt er das nach einem Screenshare meistens hin. Fragil, wenn nicht.

Ein Google Doc oder eine Tabelle als Quelle, beim Build abgeholt. Wirklich gut für eine Seite, bei der der veränderliche Inhalt eine Speisekarte, eine Preisliste, Öffnungszeiten oder eine Teamliste ist. Dein Kunde weiß schon, wie das geht, und genau darum geht es, und die Schulungssitzung fällt komplett weg.

Es gibt keine Regel, die sagt, dass ein Astro-CMS für Kunden Software sein muss. Meine Schwelle: unter einer Inhaltsänderung pro Monat, bau kein CMS. Ein bis vier im Monat, git-basiert oder Google Sheets. Wöchentlich oder öfter, oder mehr als eine publizierende Person, kauf ein echtes CMS mit Vorschau.

Was ich empfehlen würde, nach Kundentyp

Kein Schulterzucken. Hier ist die echte Entscheidung.

Lokaler Betrieb mit fünf Seiten, Änderungen zweimal im Jahr. Kein CMS. Retainer plus E-Mail, oder ein Google Sheet für die Handvoll Felder, die sich ändern. Kostenlos, und sie werden dir danken.

Kleines Unternehmen mit einem Blog, den es monatlich aktualisiert. Keystatic oder Decap, git-basiert, kostenlos, neben der Seite gehostet. Kläre bei der Übergabe die Erwartung an die Build-Verzögerung.

Content-getriebene Seite, ein oder zwei Redakteure, wöchentliche Veröffentlichung. Sanity. Die kostenlose Stufe deckt 20 Plätze, die Vorschau ist gut, und 15 Dollar pro Platz, wenn du herauswächst, ist kein schweres Gespräch.

Marketingteam, das von einem Page Builder kommt und visuelles Bearbeiten nicht loslassen wird. Storyblok, und kalkuliere die 99 Euro im Monat ab Tag eins ins Angebot, statt sie im zweiten Monat als Überraschung zu servieren.

Kunde mit strukturierten Daten, mehreren Inhaltstypen und Dingen, die eigentlich keine Seiten sind. Directus, selbst gehostet. Genau deswegen nutze ich es. Es hört auf, ein CMS zu sein, und wird zu ihrem Backend, und sobald du diese Linie überschreitest, ist der Rest des Vergleichs nicht mehr relevant.

Kunde, der Aktualisieren-und-es-ist-live nicht loslassen kann. Lass ihn bei WordPress. Wirklich. Wie ich diese Entscheidung treffe, habe ich in WordPress, Next.js, or Astro? Here's How I Actually Decide for Client Projects ausführlicher beschrieben, und meine breitere Sicht darauf, ob WordPress noch die richtige Wahl ist, in Should I Still Use WordPress in 2026?. Eine Migration, die die tägliche Arbeit deines Kunden verschlechtert, ist eine gescheiterte Migration, egal was der Lighthouse-Score sagt. Und wenn Geschwindigkeit dein Argument ist, steht die ehrliche Version dieser Zahlen in Astro vs WordPress: The Performance Numbers.

Was ich weiterhin falsch mache

Ich habe das nicht vollständig gelöst. Was mich weiter stört, ist, dass die Person, die das CMS auswählt, also ich, nie die Person ist, die darin leben muss. Ich optimiere darauf, wie es sich anfühlt, das an einem Nachmittag zusammenzustecken. Sie leben drei Jahre damit.

Bei den letzten beiden Migrationen habe ich deshalb etwas Naheliegendes getan, das ich von Anfang an hätte tun sollen: Bevor ich mich auf einen Stack festgelegt habe, habe ich mich mit dem Kunden hingesetzt und ihn eine echte Inhaltsänderung machen lassen, während ich zugesehen und nichts gesagt habe. Keine Demo. Seine Hände, meine Stille. Es ist ungefähr neunzig Sekunden lang unangenehm und sagt dir mehr als jede Vergleichstabelle.

Ein Astro-CMS für Kunden auszuwählen ist keine technische Entscheidung mit einer technischen Antwort. Es ist eine Vermutung darüber, wie sich eine bestimmte Person verhält, wenn du nicht im Raum bist. Alles andere, die Formulare, die Weiterleitungen, das Kontaktformular auf einer statischen Astro-Seite, ist im Vergleich unkompliziert.

Wenn du vor einer WordPress-Migration stehst und die Frage "aber sie müssen es bearbeiten können" dich blockiert, ist das die richtige Sache, an der man hängen bleibt. Es ist der einzige Teil, der wirklich schwer ist. Erzähl mir von dem Kunden, und ich sage dir, welche dieser Optionen ich tatsächlich nehmen würde.