Eine KI baut heute in kurzer Zeit eine gute Website. Was sie dabei nicht mitliefert, ist ein Weg, auf dem dein Kunde danach die Öffnungszeiten ändert. Dafür gibt es vier Lösungen. Sie unterscheiden sich darin, wer die Arbeit hat und was schiefgehen kann.
1. Der Kunde schreibt dir, und du änderst
Die einfachste Lösung. Der Kunde schickt eine E-Mail, du öffnest das Projekt, lässt die KI die Änderung machen und veröffentlichst neu. Bei einer Website mit zwei Änderungen im Jahr ist das vernünftig. Bei zehn Kundenwebsites wird daraus ein Postfach voller Kleinigkeiten, und jede wartet auf dich.
2. Inhalte in Dateien, dazu ein Git-basiertes CMS
Die Texte wandern aus dem HTML in Dateien, meist Markdown oder JSON. Ein CMS wie Decap, Sveltia oder TinaCMS legt eine Oberfläche darüber. Der Kunde meldet sich an, ändert ein Feld, und das CMS schreibt die Änderung in das Git-Repository. Danach baut der Hoster die Website neu.
Das kostet wenig, und alles bleibt im Repository. Es setzt aber voraus, dass die Website mit einem Generator wie Astro, Hugo oder Eleventy gebaut ist, der diese Dateien einliest. Von Hand geschriebenes HTML passt nicht dazu. Außerdem richtest du die Anmeldung für den Kunden ein, und die Felder der Oberfläche beschreibst du selbst in einer Konfigurationsdatei.
3. Ein Headless CMS
Die Inhalte liegen bei einem Dienst wie Sanity, Contentful oder Storyblok. Die Website holt sie über eine Schnittstelle, beim Bauen oder bei jedem Aufruf. Der Kunde bekommt eine ausgereifte Oberfläche mit Rollen und Verlauf.
Dafür betreust du zwei Systeme: das CMS und die Website, die zu ihm passen muss. Das Datenmodell legst du an, die Anbindung baust du, und das Hosting kommt getrennt dazu. Für die Website einer Praxis mit fünf Seiten ist das viel.
4. Eine Plattform, in der die KI baut und der Kunde pflegt
Die Website entsteht von Anfang an in dem System, in dem sie später gepflegt wird. So ist Cleverpage gebaut. Claude Code verbindet sich mit deinem Konto und baut die Website aus Komponenten. Jede Komponente hat Felder mit festem Typ: ein Text, ein Bild, eine Liste von Terminen. Aus diesen Feldern entsteht der Editor von selbst, niemand konfiguriert ihn.
Dein Kunde sieht nach der Anmeldung jede Seite so wie auf der Website und ändert Texte und Bilder direkt darin. An Farben, Schriften und Abstände kommt er nicht heran. Was sich wiederholt, etwa Neuigkeiten, Termine oder Stellenanzeigen, liegt in Collections. Wer nur ändern und wer veröffentlichen darf, legst du über Rollen fest.
Wünscht sich der Kunde etwas, das die Komponenten nicht hergeben, landet der Wunsch bei dir, und Claude Code setzt ihn später um.
Die vier Wege im Vergleich
| Wer ändert | Arbeit am Anfang | Arbeit im Betrieb | Kann der Kunde das Layout beschädigen? | |
|---|---|---|---|---|
| Du änderst | du | keine | jede Änderung | nein |
| Git-basiertes CMS | Kunde | Generator, Anmeldung, Konfiguration | gering | je nach Konfiguration |
| Headless CMS | Kunde | Datenmodell, Anbindung, Hosting | zwei Systeme | je nach Datenmodell |
| Cleverpage | Kunde | Claude baut in der Plattform | Änderungswünsche | nein |
Welche Fragen die Wahl entscheiden
- Wie oft ändert sich etwas? Bei zwei Änderungen im Jahr reicht Weg 1.
- Wie technisch ist der Kunde? Wer mit Git umgehen kann, kommt mit Weg 2 gut zurecht. Die meisten Kunden können es nicht.
- Wer betreut die Website in zwei Jahren? Ein Setup, das nur du verstehst, ist dann ein Risiko für den Kunden und eine Last für dich.
- Wie viele Websites betreust du? Bei einer ist jedes Setup tragbar. Bei zwanzig zählt, dass alle gleich funktionieren.
Cleverpage ist für den letzten Fall gemacht: viele Kundenwebsites, die eine KI baut und die der Kunde selbst pflegt. Für einen Onlineshop oder eine Anwendung mit eigenem Server-Code ist es das falsche Werkzeug.