Mein CMS ist ein Chatbot: Wie ich meine Website nur noch per Zuruf pflege
Ich habe einen erheblichen Teil meines Berufslebens in CMS-Backends verbracht. Seit 2009 baue ich Websites, die ersten Jahre fast ausschließlich mit Drupal. Und wer je ein Drupal-Backend gepflegt hat, kennt die Choreografie: einloggen, durch drei Menüebenen klicken, das richtige Textfeld finden, ändern, speichern, Cache leeren, hoffen. Ich habe das viele tausend Mal gemacht, und ich habe diese Backends selbst gebaut, also beschwere ich mich auf hohem Niveau.
Heute pflege ich meine eigene Website so: Ich öffne ein Chat-Fenster und schreibe hinein, was ich will. Das war's. Kein Backend, kein Login, kein Formular.
Das klingt nach Marketing-Übertreibung, ist aber wörtlich gemeint. webiator.de hat kein CMS im klassischen Sinn. Die Website ist eine Next.js-Anwendung, die Inhalte liegen als Markdown-Dateien mit strukturierten Metadaten direkt im Git-Repository. Gepflegt wird das Ganze im Dialog mit Claude Code, einem KI-Coding-Agenten: Ich beschreibe, was passieren soll, der Agent ändert die Dateien (Inhalte genauso wie Code), Git hält jede Änderung als Commit fest, und nach dem Push deployt Vercel automatisch die neue Version. Dass ich seit Jahren eigene KI-Systeme baue, hat die Hemmschwelle sicher gesenkt. Aber überzeugt hat mich erst der Alltag.
Wie das konkret aussieht: drei echte Beispiele
„Stell die komplette Website auf Du um." Im Juli habe ich entschieden, dass die Website ihre Leser konsequent duzen soll. Vorher war die Anrede ein gewachsener Mix. In einem klassischen CMS wäre das eine Woche Klickarbeit gewesen, mit garantiert übersehenen Stellen. Hier war es ein Auftrag im Chat. Der Agent hat 55 Dateien angefasst: alle 20 Blog-Artikel, sämtliche Marketing-Seiten, Komponenten, FAQ-Daten. 377 Zeilen neu, 373 raus. Inklusive der Feinheiten, an denen solche Aktionen sonst scheitern: FAQ-Fragen in Kundenstimme blieben beim „ihr" („Was kosten eure Pakete?"), wörtliche Rede Dritter blieb unangetastet, die Rechtstexte blieben beim Sie, und keine einzige URL hat sich geändert. Ein Auftrag, ein Review, ein Commit.
Der Redaktionsplan, der sich selbst veröffentlicht. Anfang Juli habe ich mit dem Agenten elf Blog-Artikel vorproduziert und auf die Dienstage von Juli bis Mitte September terminiert. Ein Markdown-Blog weiß erst mal nicht, was „terminiert" bedeutet, also hat der Agent im selben Zug die Blog-Logik erweitert: Artikel mit Veröffentlichungsdatum in der Zukunft werden ausgefiltert, die Seiten bauen sich stündlich neu, und jeden Dienstag erscheint pünktlich ein Artikel, ohne dass ich irgendetwas tue. Dazu gab es pro Artikel drei fertige LinkedIn-Posts als Textbausteine. Der Text, den du gerade liest, ist übrigens auf genau demselben Weg erschienen: vorproduziert, terminiert, automatisch veröffentlicht.
Und der ganze Rest. Die LinkedIn-Banner für Profil und Firmenseite hat der Agent als SVG im Website-Design gebaut und als PNG exportiert: 1584 mal 396 Pixel für das eine, 1128 mal 191 für das andere Format. Für ein SEO- und KI-Sichtbarkeits-Audit liefen mehrere spezialisierte Prüfungen parallel: Code, Live-Site, Content. Am Ende wurden sie zu einem priorisierten Maßnahmenkatalog zusammengeführt. Und ja: Auch die Ein-Zeilen-Korrektur am Telefon-Link im Impressum lief durch denselben Kanal. Der Agent unterscheidet nicht zwischen glamourös und banal, und genau das macht ihn als Werkzeug so brauchbar.
Warum das funktioniert, und zwar aus drei Gründen
Erstens: strukturierte Inhalte. Jeder Artikel ist eine Markdown-Datei mit Frontmatter: Titel, Datum, Kategorie, Tags als klar benannte Felder. Das ist das Schema, das der Agent braucht: Er muss nicht raten, wo der Titel steht, er liest ihn aus einem Feld. Das ist exakt das Argument aus meinem Artikel zum KI-ready-Relaunch: Inhalte als Daten statt als Text-Tapete. Bei mir zahlt sich das jeden Tag aus.
Zweitens: Git als Sicherheitsnetz. Jede Änderung des Agenten ist ein Commit mit Beschreibung, Zeitstempel und vollständigem Diff. Ich sehe vor der Veröffentlichung, was sich geändert hat, Zeile für Zeile. Und wenn etwas doch daneben geht, ist der Rollback eine Sache von Sekunden, nicht von Backup-Restaurierung. Ohne diese Versionierung wäre das gesamte Setup fahrlässig. Ein Agent, der ungeprüft und unversioniert auf einer Live-Website schreibt, ist kein Fortschritt, sondern ein Vorfall mit Ansage.
Drittens: Deploy-Automatik. Zwischen „Commit ist im Repository" und „Änderung ist live" liegt kein manueller Schritt. Das klingt banal, ist aber der Grund, warum sich das Ganze wie ein CMS anfühlt und nicht wie ein Entwicklungsprojekt.
| Klassisches CMS | Mein Setup (Agent + Git) | |
|---|---|---|
| Inhalte ändern | Backend-Formulare, Klickstrecken | Auftrag im Chat, Agent editiert Dateien |
| Nachvollziehbarkeit | Revisionen, je nach System lückenhaft | Jede Änderung ein Commit mit Diff und Begründung |
| Fehler zurücknehmen | Revision oder Backup einspielen | Rollback per Git, in Sekunden |
| Massenänderungen | Manuell, Seite für Seite | Ein Auftrag über 55 Dateien, ein Review |
| Code und Inhalt | Zwei getrennte Welten | Derselbe Workflow, derselbe Agent |
| Rollen und Freigaben | Eingebaut und ausgereift | Handarbeit, ehrlicherweise kaum vorhanden |
Die ehrliche Einordnung: für wen das (noch) nichts ist
Die letzte Tabellenzeile ist der Haken, und ich will ihn nicht kleinreden. Ich bin eine Ein-Personen-Redaktion: Autor, Reviewer und Freigabe-Instanz in Personalunion. Das Review vor jedem Commit bin ich selbst. Ein klassisches CMS bringt Redaktions-Workflows, Rollen, Rechte und Vier-Augen-Freigaben fertig mit. Bei einem Agenten-Setup wie meinem ist all das Stand heute Handarbeit oder schlicht nicht da. Ein Marketing-Team mit fünf Redakteuren, Freigabeprozessen und einer Rechtsabteilung sollte seine Website nicht auf ein Chat-Fenster umstellen, nur weil ein Solo-Dienstleister davon schwärmt.
Und die Compliance-Frage gehört auf den Tisch, bevor der erste Agent publiziert: Wer verantwortet, was da live geht? Die Antwort ist unbequem einfach – du. Am Impressum, am Wettbewerbsrecht, an der Verantwortung des Betreibers ändert KI nichts. Deshalb gehört ein menschlicher Freigabe-Schritt in jeden Agenten-Workflow, bis die Werkzeuge Freigaben selbst abbilden.
Der Blick nach vorn: Die CMS-Branche baut genau daran
Womit wir bei der Pointe wären. Ich komme aus der Drupal-Welt und begleite ihr Altwerden bis heute, und ausgerechnet dort passiert gerade das Interessanteste auf diesem Feld. Die Drupal AI Initiative wird von 28 Unternehmen getragen, die zusammen mehr als 23 Vollzeit-Contributors stellen, und hat sich für 2026 acht Fähigkeiten vorgenommen, darunter Seitengenerierung aus Designsystem-Komponenten, Kontext-Management für Markenstimme und Governance-Regeln sowie Hintergrund-Agenten, die auf Trigger und Zeitpläne reagieren und dabei redaktionelle Workflows respektieren. Der erklärte Anspruch: KI nicht als Chatbot anflanschen, sondern in den Prozess der Content-Erstellung selbst einbetten, mit Audit-Trails und Governance.
Das ist bemerkenswert, denn es sind exakt die Lücken, die ich zwei Absätze weiter oben als Handarbeit beschrieben habe. Was ich heute mit Git, Markdown und einem Chat-Fenster manuell zusammenstecke, wird dort gerade mit Rollen, Freigaben und Nachvollziehbarkeit als Produkt gebaut. Mein Setup ist ein Vorgriff, kein Endzustand.
Was du daraus mitnehmen kannst
Auch wenn du deine Website nicht morgen per Zuruf pflegen wirst: Die Voraussetzungen dafür sind dieselben, die sich heute schon lohnen. Strukturierte Inhalte mit klaren Feldern statt Text-Tapeten. Ein programmatischer Zugang zu deinen Inhalten. Versionierung, die jede Änderung nachvollziehbar macht. Und eine geklärte Antwort auf die Frage, wer freigibt, was live geht. Das ist keine Wette auf einen Hype, sondern solide Webtechnologie, die nebenbei die Tür für Agenten öffnet.
Wenn du wissen willst, ob deine Website (oder dein nächster Relaunch) dafür schon bereit ist: Sprich mich an. Ich schaue mir dein Setup an und sage dir ehrlich, was heute schon geht, was Handarbeit bleibt und wovon ich dir abraten würde. Die Antwort schreibe ich übrigens noch selbst.
Häufige Fragen
- Kann ein KI-Agent wirklich eine komplette Firmenwebsite pflegen?
- Ja, wenn die Voraussetzungen stimmen: Inhalte müssen strukturiert vorliegen (etwa als Markdown-Dateien oder über eine API), jede Änderung muss versioniert werden, und ein Mensch sollte vor der Veröffentlichung prüfen. Ohne Versionierung und Review ist ein schreibender Agent auf einer Live-Website keine Automatisierung, sondern ein Risiko.
- Was passiert, wenn der KI-Agent einen Fehler auf der Website macht?
- In einem Git-basierten Setup ist jede Änderung ein Commit mit nachvollziehbarer Beschreibung. Ein Fehler lässt sich als Diff erkennen, bevor er live geht, und nach dem Deploy in Sekunden zurückrollen. Genau deshalb ist Versionierung die nicht verhandelbare Grundlage für jeden Agenten, der Inhalte verändert.
- Brauche ich dafür eine neue Website oder geht das auch mit meinem bestehenden CMS?
- Entscheidend ist nicht das System, sondern die Struktur: Ein Agent braucht Inhalte als Daten mit klaren Feldern und einen programmatischen Zugang, etwa eine API. Moderne CMS wie Drupal bauen solche Agenten-Funktionen gerade direkt ins Produkt ein. Eine Text-Tapete ohne Schnittstelle bleibt dagegen für jeden Agenten unbrauchbar.
- Wer verantwortet Inhalte, die eine KI auf der Firmenwebsite veröffentlicht?
- Das Unternehmen selbst. Daran ändert der Einsatz von KI nichts. Wer publiziert, verantwortet den Inhalt, egal ob ihn ein Mitarbeiter, eine Agentur oder ein Agent geschrieben hat. Praktisch heißt das: Vor der Veröffentlichung gehört ein menschlicher Freigabe-Schritt in den Prozess, solange Agenten-Workflows keine eingebauten Freigaben mitbringen.
Quellen
Artikel teilen
Brauchst du eine digitale Plattform?
Drupal, Next.js, Python — wir bauen Plattformen, die wachsen und bereit sind für KI.
Erstgespräch buchen