Ich habe alle 45 CMS-Optionen für Astro durchgearbeitet. Für eine statische Seite ist dein KI-Agent das CMS.

Ich habe Pages CMS auf der Astro-Seite eines Kunden installiert, einen Tippfehler korrigiert und auf Speichern geklickt. Rund 50 Sekunden später lief schon ein kompletter Neubau der ganzen Seite.

Für einen Tippfehler.

Pages CMS schreibt jedes Speichern als Git-Commit, und der Host, Coolify, deployt bei jedem Push auf main. Zehn kleine Korrekturen hintereinander wären zehn komplette Deploys gewesen. Also habe ich nach einem besseren CMS für eine statische Seite gesucht und am Ende jedes einzelne aus Astros Doku durchgearbeitet. Es sind 45.

Am Schluss hatte ich eine Shortlist mit zwei Kandidaten, beide nicht ganz richtig. Und ich bin immer wieder beim selben Gedanken gelandet: Der beste Editor für diese Seite lag schon im Repo.

45 CMS-Optionen, und die Shortlist für statische Seiten hat zwei Einträge

Meine Anforderungen waren langweilig. Selbst gehostet, bleibt bei output: 'static', macht die MDX-Komponenten in den Blogposts nicht kaputt, und ich kann fünf Dinge bearbeiten und dann einmal veröffentlichen. So sind die 45 ausgegangen, plus eins, das nicht auf der Liste steht:

Urteil	Anzahl
Einen Test wert	1 (Keystatic), plus Sveltia, das nicht auf der Liste steht
Funktioniert, kostet aber Komplexität	3 (Directus, Decap, Sitepins)
Selbst hostbar, falsches Werkzeug für eine statische Seite	17
Nur SaaS	24

Mehr als die Hälfte der "CMS für Astro"-Liste ist die Cloud von jemand anderem. Okay, wenn du gerne pro Seat zahlst und deine Inhalte auf einem US-Server liegen. Mein Kunde ist deutsch und wollte nicht noch eine monatliche Rechnung pro Seite, also waren die am ersten Tag raus.

Die 17 in der Mitte sind größtenteils komplette Anwendungen mit eigener Datenbank: WordPress, Strapi, Payload, Ghost, Statamic. So etwas zu betreiben, damit jemand ein Dutzend Markdown-Dateien bearbeiten kann, ist viel Server für sehr wenig. EmDash und StudioCMS sind Astro-nativ, was perfekt klingt, bis du liest, dass beide output: 'server' brauchen, und deine statische Seite ist nicht mehr statisch. (Ich habe EmDash zum Launch getestet, falls du die lange Version willst.)

Am besten gepasst hat Sveltia CMS, und das steht nicht mal auf Astros Liste. Es sind zwei statische Dateien in public/admin/, und es ist das einzige Git-basierte CMS, das ich gefunden habe, mit einem echten "Publish Changes"-Button. Der MDX-Support steht auf der Roadmap als "TBD". Die Posts auf dieser Seite nutzen <CTABox> und <StatsBar> in MDX, und nichts in der Doku konnte mir sagen, ob Sveltia die unverändert zurückspeichert.

Die Optionen für Kunden habe ich schon nach Kundentyp verglichen, in "Aber mein Kunde muss das bearbeiten können." In diesem Post geht es darum, was passiert, wenn du aufhörst, nach dem richtigen CMS zu suchen.

Was ein CMS auf einer statischen Seite eigentlich macht

Das Deploy-bei-jedem-Speichern-Problem war nicht die Schuld von Pages CMS. Es war die meines Hosts. Coolify deployt, genau wie Netlify, Vercel und Cloudflare Pages, standardmäßig bei jedem Push. Schalte das ab, und jedes Git-basierte CMS speichert einfach nur, und Veröffentlichen wird etwas, das du bewusst auslöst.

Als ich das gesehen hatte, ist die Stellenbeschreibung eines CMS für eine statische Seite auf fast nichts geschrumpft. Es ist ein Formular, das Text in eine Datei in deinem Repo schreibt, plus ein Button, der einen Build startet. Login-Seite und Mediathek gibt es nur, um diese zwei Dinge zu stützen.

Und auf einer statischen Astro-Seite bringt das CMS seine eigenen Probleme mit:

• Das Schema gibt es zweimal. Dein Zod-Schema in content.config.ts legt schon fest, wie ein Post aussieht. Das CMS will eine eigene Config, die das spiegelt, und wenn die beiden auseinanderlaufen, schreibt das CMS Front Matter, das dein Build ablehnt.
• MDX wird zerlegt oder neu modelliert. Die meisten Editoren zeigen eine JSX-Komponente als reinen Text an oder lassen dich sie als strukturierten "Block" nachbauen.
• TypeScript-Datendateien sind tabu. Kein schemabasiertes Git-CMS bearbeitet ein TypeScript-Objekt als Formularfelder. Du konvertierst erst nach JSON, oder der Inhalt bleibt Entwicklersache.
• Irgendwer muss die Schlüssel halten. Die meisten Git-basierten Editoren brauchen für die Redakteurin oder den Redakteur einen GitHub-Account, und der Deploy-Token muss irgendwo liegen. Bei Coolify gilt dieser Token für das ganze Team, also kann ein Token im Browser eines Redakteurs auch jede andere App im Team neu starten.

Ein KI-Agent, der im Repo arbeitet, erledigt dieselben zwei Jobs. Er schreibt Dateien und kann einen Build starten. Er bearbeitet den echten Quellcode, also gibt es kein zweites Schema, das auseinanderlaufen kann. Er liest MDX als Text, weil MDX Text ist. Und du committest einmal, wenn du fertig bist, also geht eine Bearbeitungssitzung als ein Deploy live, selbst wenn Push-to-Deploy an bleibt.

Was ich stattdessen ausliefere: drei Skills in jedem Template

Ich bin hier auf der Verkäuferseite, damit du weißt, worum es für mich geht: Jedes der 65 Astro-Templates, die ich auf juststart.now verkaufe (sie sind auf astro.build/themes gelistet), kommt ohne CMS. Stattdessen hat jedes drei Claude-Code-Skills dabei. dev-workflow liest das Projekt, bevor es irgendetwas ändert, dev-test lässt die Testsuiten laufen und schreibt neue Tests, wenn eine Änderung einen braucht, und dev-review liest die noch nicht committete Änderung mit frischem Blick.

Während ich diesen Post geschrieben habe, habe ich das Klempner-Template geöffnet und nach einem einzigen Preis gesucht, der Jahreswartung für den Boiler zu £89. Er steht in fünf Dateien.

Er steht in der Preisliste in src/data/prices.ts und in der Jobliste des Buchungsablaufs in src/data/booking.ts. Er steht in der priceNote von data/services/boiler-servicing.md. Er steckt in einer FAQ-Antwort in src/data/content.ts: "Our service is £89 fixed and we send a reminder a month before it is due." Und er steht in einem Satz im Ratgeberartikel how-often-to-service-a-boiler.mdx.

Kommt dir das bekannt vor?

So sehen echte Seiten kleiner Unternehmen aus. Ein Preis ist kein Feld, er ist ein Fakt, der in Sätzen auftaucht. Ein CMS kann dem Inhaber ein ordentliches Feld für die Preisliste geben, und die FAQ sagt die nächsten zwei Jahre weiter £89.

Genau dafür ist dev-workflow geschrieben. Der erste Schritt ist, die CLAUDE.md des Templates zu lesen, die Datei für Datei auflistet, wo welche Art von Inhalt liegt. Bei einer Inhaltsänderung steht dort, dass der meiste Text des Templates Daten sind und kein Markup, also erst dort nachsehen, bevor man eine Komponente anfasst, und der Agent soll nach der String-Form dessen suchen, was er ändert, und nach dem Symbol. Für die Buchungsauswahl, das Feature, um das das ganze Template gebaut ist, ist die Anweisung eine Zeile: "To change prices or options, edit the data file, not the maths."

Dann lässt dev-test laufen, was mit dem Template kommt: eindeutige Slugs, echte Datumsangaben, Trailing Slashes an jedem internen Link, Farbkontrast, der 4,5:1 schafft. Eine Preisänderung braucht keinen neuen Test, und der Skill sagt das, statt einen zu erfinden. Dann liest dev-review die geänderten Dateien komplett, denn, in den Worten des Skills: "A diff hides the consumer you broke."

Ein CMS-Formular prüft, ob ein Feld leer ist. Der Agent prüft, ob die Seite noch baut und ob irgendwo noch der alte Preis steht. Für den Inhaber ist es ein Satz: "Die Boilerwartung kostet jetzt £95."

Wenn du noch nie gesehen hast, was in eine CLAUDE.md gehört, ist die von Netflix, die in Produktion gelandet ist ein guter Einstieg. Und ich habe diese Art von Agent-im-Repo-Setup bei echter Kundenarbeit eingesetzt, darum geht es in Ich habe 3 Kundenseiten von WordPress zu Astro migriert.

Wo das auseinanderfällt

Der Inhaber, der nie ein Terminal öffnen wird. Für diese Person habe ich keine Lösung.

Manche Seiteninhaber tippen gerne einen Satz in Claude Code. Andere sehen einen blinkenden Cursor, klappen den Laptop zu und schreiben ihrem Entwickler eine Mail. Wenn dein Kunde zur zweiten Sorte gehört, ist dieser Post für ihn falsch. Die Optionen aus dem Post über CMS für Kunden, oder schlicht "schick mir die Änderung per Mail", sind dann die bessere Antwort.

Der Agent kostet außerdem ein monatliches Abo, während Sveltia nichts kostet. Und Agenten machen Dinge mit voller Überzeugung kaputt. Darüber habe ich einen ganzen Post geschrieben, Claude ist perfekt zum Bauen von Software. Und genauso gut darin, sie kaputtzumachen., und das ist der Grund, warum dev-test und dev-review überhaupt in den Templates sind. Die Skills machen den Agenten nicht vorsichtig. Sie sorgen dafür, dass seine Schlampigkeit sichtbar wird, bevor etwas live geht.

Und ich habe noch nicht neben einem nicht-technischen Käufer gesessen, während er mit diesen Skills seine eigene Seite bearbeitet. Der Teil über Inhaber ist eine Überlegung, keine Messung.

Das CMS war für die Zeit, in der niemand Technisches im Raum war

Ein CMS für eine statische Seite gibt es, weil der Entwickler geht und der Inhaber eine sichere Box braucht, in die er tippen kann. Diese Box ist ein Formular mit Leitplanken, die nichts über die Seite wissen. Sie weiß nicht, dass der Preis auch in der FAQ steht oder dass die Buchungsauswahl aus einer Datendatei liest.

Ein Agent mit den Anweisungen des Projekts und seinen Tests weiß das. Für eine statische Seite halte ich das für die bessere Box. Ob der Inhaber sie öffnet, kann ich dir nicht beantworten.

Wenn du gerade entscheidest, was du einem Kunden nach einem Astro-Projekt übergibst, oder du so ein Skill-Setup für dein eigenes Repo willst, erzähl mir von der Seite und ich sage dir, ob ich ihm einen Agenten oder ein CMS geben würde.