Wissen · Websites & Projekte

Website pflegen mit KI und ohne CMS – wie weit ein KI-Editor wirklich trägt

1. September 2026 · Lesezeit ca. 9 Minuten · von Holger Klopmeyer

Die interessanteste Frage in einem Website-Projekt kommt fast nie im Angebot vor: Wer ändert das später? Nicht den Relaunch in vier Jahren – die Kleinigkeiten. Die neue Telefonnummer, den Satz, der sich überholt hat, das Team-Foto nach dem Personalwechsel. An dieser einen Frage entscheidet sich, welches System gebaut wird, und sie wird meist zugunsten der Bequemlichkeit im Verkaufsgespräch beantwortet statt zugunsten der Website.

Seit ein paar Monaten gibt es dafür eine dritte Antwort. Sie ist noch jung, sie hat Kanten, und ich baue selbst an einer davon – deshalb steht in diesem Artikel auch, was sie nicht kann.

Warum die Pflegefrage über das ganze System entscheidet

Die übliche Kette ist schnell erzählt. Der Kunde sagt: „Ich will Texte selbst ändern können.“ Also wird ein CMS gebaut, meistens WordPress. Damit kommen Datenbank, Login-Bereich, Theme, ein Dutzend Plugins und die Pflicht, das alles aktuell zu halten – nachzulesen im Artikel über Wartungsverträge. Und dann, drei Jahre später, stellt sich heraus: Der Kunde hat im Backend zweimal etwas geändert. Beide Male hat hinterher jemand aufgeräumt.

Die Alternative wäre eine statische Website: fertige HTML-Dateien, die der Server einfach ausliefert. Technisch ist das der bessere Bau – nur eben ohne Backend.

Der Haken steht schon im letzten Satz des vorigen Absatzes: ohne Backend. Genau deshalb wird die statische Website im Angebot meist wieder gestrichen, obwohl sie sachlich besser wäre. Nicht die Technik entscheidet, sondern die Redaktionsfrage.

Was ein KI-Editor an dieser Stelle ändert

Die Idee ist einfach: Statt ein Backend zu bauen, in dem der Kunde Inhalte pflegt, legt man einen Editor über die fertige Website. Der Kunde sieht seine Seite so, wie sie im Netz steht, klickt das Element an, das ihn stört, und schreibt in normalem Deutsch, was anders werden soll. Die KI ändert daraufhin das HTML.

Das ist mehr als ein hübscher Chat. Der entscheidende Unterschied zum klassischen CMS: Es gibt keine Trennung mehr zwischen „Inhalt“ und „Layout“. In WordPress kann der Kunde nur ändern, was jemand vorher als Feld angelegt hat. Hier kann er alles ändern – und das ist Segen und Fluch zugleich, dazu gleich mehr.

In der Praxis läuft nicht jede Änderung über die KI, und das ist der Punkt, an dem sich brauchbare Werkzeuge von Demos unterscheiden:

  1. Texte ändert man direkt in der Seite. Anklicken, tippen, fertig – ohne KI, ohne Wartezeit, ohne Kosten. Für 80 Prozent aller Pflegefälle ist das schon die ganze Geschichte.
  2. Bilder tauscht man über einen Dateimanager: Bild in der Seite markieren, neues Bild anklicken oder hochladen. Auch das braucht keine KI – es ist ein Dateivorgang, kein Sprachverständnis.
  3. Ganze Bausteine – eine Sektion, ein Kartenraster, ein Kontaktblock – lassen sich als Vorlage sichern und an anderer Stelle wieder einsetzen. Das ist reines Kopieren im HTML und passiert sofort.
  4. Die KI kommt für alles, wofür man sonst jemanden anrufen müsste: „Mach die Überschrift kleiner und setze sie linksbündig“, „Bau mir unter dem Team noch einen Abschnitt mit drei Kacheln“, „Die Abstände auf der Handy-Ansicht sind zu eng“.

Für die Geschwindigkeit heißt das grob: Textänderungen sind sofort da, eine einfache KI-Änderung liegt bei etwa fünf bis sieben Sekunden, eine, die die ganze Website betrifft, bei rund elf. Das ist kein Vergleich zu „Ich schreibe der Agentur eine Mail und warte bis Donnerstag“.

Der unterschätzte Teil: CSS gewinnt nicht automatisch

Ein Detail, das erklärt, warum viele KI-Editor-Demos beeindrucken und im Alltag dann enttäuschen. Wenn die KI eine Gestaltungsregel schreibt – sagen wir, eine kleinere Zeilenhöhe für Überschriften –, heißt das noch lange nicht, dass diese Regel auch wirkt. Themes und Frameworks setzen ihre eigenen Regeln oft mit Vorrang, und dann verliert die neue Regel wirkungslos gegen die alte.

Sichtbar ist das für den Nutzer nur als Frust: „Ich hab's dreimal gesagt, es ändert sich nichts.“ Ein Werkzeug, das taugt, muss die Kaskade deshalb nachrechnen und die neue Regel gezielt so weit verstärken, dass sie gewinnt – ohne dabei versehentlich die halbe Website mitzuverändern. Das ist unspektakuläre Fleißarbeit und macht den Unterschied zwischen „nett“ und „benutzbar“.

Freigeben und Veröffentlichen sind zwei Dinge

Hier liegt die zweite Stelle, an der sich Spielzeug und Werkzeug trennen. Wenn der Kunde direkt an der Live-Website arbeitet, ist jeder Tippfehler sofort öffentlich. Wenn er gar nichts sieht, bis die Agentur freigibt, ist der Vorteil dahin.

Der brauchbare Weg liegt dazwischen und hat drei Ebenen:

  • Arbeitsstand. Jede Änderung ist sofort in der Vorschau sichtbar, aber nur dort. Jeder einzelne Handgriff steht in einer Historie mit Uhrzeit und Auftrag und lässt sich einzeln zurücknehmen – nicht nur der letzte.
  • Version. Ein bewusst festgeschriebener Stand der ganzen Website, mit Notiz und Namen. Erst damit kann man überhaupt sagen, was freigegeben war und was sich seither geändert hat. Zwei Versionen lassen sich nebeneinanderlegen und vergleichen.
  • Veröffentlichen. Nach draußen geht immer die freigegebene Version, nie der Arbeitsstand – und übertragen werden nur die Dateien, die sich tatsächlich geändert haben.

Wer diese drei Ebenen zusammenwirft, baut eine Maschine zum Kaputtmachen. Wer sie trennt, kann dem Kunden guten Gewissens den Schlüssel geben.

Für Agenturen: ein Editor, viele Kundenwebsites

Der Punkt, warum das für Agenturen interessanter ist als für einzelne Unternehmen: Ein solcher Editor ist nicht an eine Website gebunden. Er sitzt auf dem eigenen Server und bedient beliebig viele Kundenwebsites nebeneinander – jede mit eigener Historie, eigenen Versionen, eigenen Zugängen und eigenem Veröffentlichungsziel. Gestaltungsvorlagen lassen sich dagegen bewusst über Websites hinweg nutzen: Eine Sektion, die sich beim einen Kunden bewährt hat, wandert in die nächste Website.

Dazu kommt die Rollenfrage, die im Agenturalltag entscheidend ist: Der Kunde ändert Texte, darf aber nichts freigeben. Der Projektleiter gibt frei und veröffentlicht. Die Agentur verwaltet Zugänge und Rollen. Damit bleibt die Verantwortung dort, wo sie hingehört, und der Kunde bekommt trotzdem das Gefühl, nicht für jede Telefonnummer betteln zu müssen.

Wirtschaftlich ist der Reiz nicht der Werkzeugverkauf, sondern die Verschiebung: Statt Kleinstaufträge zu bearbeiten, die niemand gern schreibt und niemand gern bezahlt, betreut man Systeme. Das rechnet sich für beide Seiten.

Was das Ganze nicht kann

Damit der Artikel ehrlich bleibt, die Gegenseite:

  • Die KI versteht nicht, was du meinst – sie verarbeitet, was du schreibst. Unpräzise Aufträge liefern unpräzise Ergebnisse, und gelegentlich etwas, das plausibel aussieht und trotzdem falsch ist. Wer damit arbeitet, sollte wissen, was eine Halluzination ist.
  • Jede KI-Änderung kostet Geld. Nicht viel pro Vorgang, aber es ist keine Flatrate. Deshalb ist es kein Zufall, dass Text- und Bildänderungen bewusst ohne KI laufen.
  • Der Kunde kann alles ändern – auch das, was er nicht ändern sollte. Ein CMS schützt durch enge Felder. Hier schützt nur die Versionierung. Das ist ein anderer Sicherheitsgurt, kein schlechterer, aber man muss es wissen.
  • Ein KI-Editor ersetzt keine Konzeption. Er macht das Ändern billig, nicht das Denken. Eine Website mit schwacher Struktur wird durch schnelle Änderungen nicht besser, nur schneller schlechter.
  • Barrierefreiheit entsteht nicht von selbst. Wer per Prompt Kontraste verstellt oder Überschriftenebenen durcheinanderbringt, macht die Seite unbemerkt unzugänglicher.

Warum ich das selbst gebaut habe

Ich habe für dieses Problem lange keine Lösung gefunden, die mir gefallen hat: Entweder ein volles CMS mit allem Wartungsballast, oder eine statische Seite, bei der jede Kleinigkeit über mich läuft. Also läuft seit einigen Monaten ein eigener KI-Editor auf meinem Server, der genau das macht, was oben steht – Prompt-Leiste über der fertigen Website, Textmodus ohne KI, Bilder- und Vorlagenverwaltung, Historie, Versionen mit Vergleich, Rollen und Veröffentlichung per SFTP oder rsync. Er betreut mehrere Kundenwebsites gleichzeitig; Seiten lassen sich auch aus einem Figma-Entwurf anlegen.

Volle Transparenz: Das ist mein eigenes Werkzeug, es ist noch in Entwicklung, und ein paar Bereiche sind bewusst noch nicht scharf geschaltet – eine ganze Website aus Figma etwa, oder die Statistik-Ansicht. Was fertig ist, ist im Einsatz; was nicht fertig ist, sagt das im Werkzeug selbst. Wer lieber bei WordPress bleibt, kommt damit auch ans Ziel – der Vergleich der Systeme steht im Artikel WordPress, Baukasten oder individuell, und wie KI beim Erstellen einer Website hilft, im ehrlichen Vergleich der drei Wege.

Wenn du wissen willst, ob das für deine Website oder für deine Kunden passt: Ich zeige den Editor gern an einer echten Seite statt an einer Demo-Spielwiese. Melde dich über die Beratung, dann schauen wir uns das gemeinsam an. Wie ich Websites baue, steht unter Webdesign; was KI sonst noch im Alltag übernimmt, unter KI-Automation.

Häufige Fragen

Ist eine statische Website nicht ein Rückschritt?

Technisch ist sie das Gegenteil: schneller, sicherer und haltbarer als jede Datenbank-Anwendung. Der einzige echte Nachteil war immer die Redaktion – und genau der fällt weg, wenn ein Editor darübersitzt. Für Shops, Buchungssysteme oder Portale mit Benutzerkonten bleibt ein dynamisches System natürlich richtig.

Kann der Kunde die Website damit kaputt machen?

Kaputt im Sinne von „unwiederbringlich“ nicht, wenn das Werkzeug Historie und Versionen sauber trennt: Jede Änderung ist einzeln zurücknehmbar, und ein früherer Stand lässt sich zurückholen. Unschön aussehen lassen kann er sie schon – deshalb sollten Freigabe und Veröffentlichung an einer Rolle hängen, die nicht jeder hat.

Was kostet der Betrieb?

Zwei Posten: das Hosting der Website, das bei statischen Seiten am unteren Ende liegt, und die KI-Nutzung, die pro Änderung abgerechnet wird. Weil Text-, Bild- und Vorlagenänderungen ohne KI laufen, fällt der zweite Posten im Alltag klein aus. Eine belastbare Zahl hängt zu stark vom Nutzungsverhalten ab, um sie hier seriös zu nennen – das klären wir am konkreten Fall.

Funktioniert das auch mit einer bestehenden WordPress-Seite?

Nicht direkt. Der Editor arbeitet an HTML-Dateien, nicht an einer Datenbank. Eine bestehende WordPress-Seite lässt sich aber in einen statischen Stand überführen – ob sich das lohnt, hängt daran, wie viel echte Dynamik die Seite wirklich braucht. Meiner Erfahrung nach ist es deutlich weniger, als beim Bau angenommen wurde.

Kann ich das als Agentur für meine eigenen Kunden nutzen?

Dafür ist der Aufbau gemacht: eine Installation, beliebig viele Kundenwebsites, getrennte Zugänge und Rollen je Website, gemeinsame Vorlagen darüber. Melde dich, dann reden wir über den konkreten Zuschnitt.

Holger Klopmeyer
Holger Klopmeyer

Grafikdesigner & Programmierer. Seit über 25 Jahren in der Werbung zuhause – heute mit Fokus auf Websites, 3D, SEO und KI-Automation für Agenturen und Unternehmen.

Fragen zu deinem Projekt?
Lass uns sprechen.

Unverbindlich und auf Augenhöhe – ich sage dir ehrlich, was sinnvoll ist.

Termin vereinbaren → oder Kontaktdaten ansehen