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.
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.
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:
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“.
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“.
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:
Wer diese drei Ebenen zusammenwirft, baut eine Maschine zum Kaputtmachen. Wer sie trennt, kann dem Kunden guten Gewissens den Schlüssel geben.
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.
Damit der Artikel ehrlich bleibt, die Gegenseite:
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.
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.
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.
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.
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.
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.
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.
Unverbindlich und auf Augenhöhe – ich sage dir ehrlich, was sinnvoll ist.
Termin vereinbaren → oder Kontaktdaten ansehen