KI-Publishing ohne WordPress: Eigenes CMS mit Vibe Coding planen

Worum es hier geht – und worum nicht

Wer heute „eigenes CMS" hört, denkt schnell an ein Wochenendprojekt, das nach drei Monaten unwartbar ist. Diese Sorge ist berechtigt, und deshalb geht es hier ausdrücklich nicht darum, WordPress durch eine selbst geschriebene Redaktionssoftware zu ersetzen, die Login, Rechte, Editor, Medienverwaltung und Datenbank nachbaut. Das wäre teuer, fehleranfällig und in den meisten Fällen unklug.

Es geht um etwas anderes: um ein Publishing-System als Denkmodell. Also um die Frage, wie Inhalte entstehen, wo sie liegen, wer sie prüft, wie sie zu Seiten werden und wie diese Seiten sicher online gehen. KI spielt dabei die Rolle eines Werkzeugs im Entstehungsprozess – beim Recherchieren, Strukturieren, Entwerfen und Prüfen – nicht die Rolle einer Instanz, die eigenständig veröffentlicht. Dieser Unterschied ist der Kern des gesamten Artikels.

WordPress fair einordnen

WordPress ist nicht „tot", und wer das behauptet, hat in den letzten Jahren nicht hingesehen. Ein sehr großer Teil des Webs läuft darauf, das Ökosystem aus Themes, Plugins, Hostern und Agenturen ist riesig, und für viele Betreiber ist genau das der entscheidende Vorteil: Man findet für fast jedes Problem eine Lösung, einen Dienstleister und eine Anleitung.

Die Stärken liegen auf der Hand. WordPress hat einen ausgereiften Editor, eine echte Benutzer- und Rechteverwaltung, eine Medienbibliothek, Kommentarfunktionen, unzählige Erweiterungen und eine große Community. Nicht-technische Redakteure können ohne Programmierkenntnisse arbeiten. Für Shops, Mitgliederbereiche, Foren oder Portale mit vielen dynamischen Funktionen ist ein datenbankgestütztes System oft schlicht das richtige Werkzeug.

Die Schattenseiten gehören ebenso ehrlich benannt: Ein Setup mit vielen Plugins wird zur Wartungsaufgabe. Jedes Plugin ist zusätzlicher Code von Dritten, der aktualisiert, geprüft und im Zweifel abgesichert werden muss. Performance hängt stark von Hosting, Caching und Theme-Qualität ab. Und die Angriffsfläche ist real: veraltete Kern-, Theme- oder Plugin-Versionen sind ein häufiger Einstiegspunkt für Kompromittierungen. Das ist kein Argument gegen WordPress an sich – es ist ein Argument für sauberes Betreiben.

Der ehrliche Satz lautet also: WordPress ist ein exzellentes Werkzeug für einen bestimmten Zweck. Ein KI-Publishing-System ist ein anderes Werkzeug für einen anderen Zweck. Die Frage ist nicht „besser oder schlechter", sondern „passt es zu diesem Projekt".

Die Begriffe sauber trennen

Bevor man plant, muss man vier Begriffe auseinanderhalten, die im Alltag oft vermischt werden.

Ein CMS (Content-Management-System) wie WordPress verwaltet Inhalte in einer Datenbank und erzeugt Seiten in dem Moment, in dem ein Besucher sie aufruft (serverseitig, dynamisch). Redakteure arbeiten in einer Oberfläche, alles liegt zentral im System.

Ein Static-Site-Generator (SSG) wie Astro oder Eleventy geht den umgekehrten Weg: Aus Inhaltsdateien (meist Markdown) und Vorlagen werden vorab fertige HTML-Dateien erzeugt. Diese Dateien enthalten keine Datenbankabfrage und keinen serverseitigen Code, nur ausgelieferten HTML-, CSS- und JavaScript-Text. Genau deshalb sind sie schnell, günstig zu hosten und schwer anzugreifen.

Ein Headless CMS trennt die Inhaltsverwaltung von der Darstellung. Es liefert eine Redaktionsoberfläche und speichert Inhalte, überlässt die Anzeige aber einem separaten Frontend. Eine besonders schlanke Variante ist ein Git-basiertes CMS wie Decap CMS (ehemals Netlify CMS): Es gibt Redakteuren eine Editor-Oberfläche im Browser, speichert die Inhalte aber nicht in einer Datenbank, sondern als Dateien in einem Git-Repository.

Ein „KI-Publisher" im Sinne dieses Artikels ist kein eigenes Produkt, sondern ein Prozess: KI unterstützt beim Entwerfen und Strukturieren von Inhalten, diese landen als saubere Dateien in einer versionierten Ablage, ein Build erzeugt daraus statische Seiten, und ein Deployment bringt sie online. Der Mensch bleibt an jeder Weiche die entscheidende Instanz.

Vier technische Grundbegriffe, ohne die nichts davon Sinn ergibt

Damit die folgenden Abschnitte tragen, lohnt sich ein kurzer Umweg über vier Wörter, die auf diesem Weg ständig fallen.

Ein Build ist der Vorgang, bei dem aus Ihren Rohdateien – Texten, Bildern, Vorlagen – die fertige Website erzeugt wird. Man kann sich das wie das Setzen und Drucken eines Buches vorstellen: Das Manuskript (Ihre Inhalte) wird nach festen Regeln in ein auslieferbares Ergebnis (die HTML-Seiten) verwandelt. Der Build passiert einmal vor der Veröffentlichung, nicht bei jedem Seitenaufruf.

Git ist ein Versionsverwaltungssystem. Es merkt sich jede Änderung an Ihren Dateien, wer sie wann gemacht hat und warum. Man kann jederzeit zu einem früheren Stand zurück, Änderungen vergleichen und nichts geht unbemerkt verloren. Für ein Publishing-System ist Git zugleich Archiv, Sicherheitsnetz und Protokoll.

Ein Branch (Zweig) ist eine parallele Arbeitskopie innerhalb von Git. Man kann in einem Branch an einem neuen Artikel arbeiten, ohne die veröffentlichte Website zu berühren. Erst wenn der Text fertig und geprüft ist, wird der Branch mit dem Hauptstand zusammengeführt. So entsteht ein natürlicher Ort für die redaktionelle Freigabe.

Ein Deployment ist das Ausliefern der fertig gebauten Seiten an den Ort, an dem Besucher sie sehen – etwa das Hochladen der HTML-Dateien per FTP auf einen Webspace oder das automatische Übertragen auf einen Hosting-Dienst. Build erzeugt das Ergebnis, Deployment bringt es an die Öffentlichkeit.

Drei realistische Varianten eines KI-Publishing-Systems

Es gibt nicht „das eine" richtige System. Sinnvoll sind je nach Team und Anspruch drei Ausbaustufen.

Variante 1 – Dateien plus Static-Site-Generator. Inhalte werden als Markdown-Dateien geschrieben, KI hilft beim Entwurf, ein SSG wie Eleventy oder Astro baut daraus die Seiten, das Ergebnis geht per FTP online. Diese Variante ist maximal schlank, komplett ohne Datenbank, günstig und langlebig. Sie setzt aber voraus, dass die schreibenden Personen mit Dateien und einem Editor umgehen können. Für Einzelbetreiber und kleine, technisch affine Teams ist das oft die beste Wahl.

Variante 2 – Static-Site-Generator plus Git-basiertes CMS. Hier kommt eine Redaktionsoberfläche dazu, etwa Decap CMS. Redakteure schreiben in einem Editor im Browser, die Inhalte werden aber weiterhin als Dateien in Git gespeichert und ein SSG baut die Seiten. Das verbindet die Bedienbarkeit eines CMS mit der Robustheit statischer Seiten. Der Preis ist etwas mehr Einrichtungsaufwand und die Bindung an eine Authentifizierungslösung für den Editor. Für kleine Redaktionen mit gemischten Kenntnissen ein sehr guter Mittelweg.

Variante 3 – Headless CMS plus statisches Frontend. Ein vollwertiges Headless CMS verwaltet Inhalte zentral, ein SSG oder ein Framework erzeugt daraus das Frontend. Diese Variante skaliert am besten, bietet echte Rechteverwaltung und strukturierte Inhaltsmodelle, ist aber auch die aufwendigste und teuerste. Sie lohnt sich, wenn viele Personen parallel arbeiten oder Inhalte über mehrere Kanäle ausgespielt werden.

Wichtig ist die ehrliche Einordnung: Je weiter rechts in dieser Liste, desto näher rückt man wieder an die Komplexität heran, die man mit „weg von WordPress" eigentlich vermeiden wollte. Der Reiz liegt für die meisten kleinen Projekte klar bei Variante 1 oder 2.

Der redaktionelle Ablauf – vom Einfall zur veröffentlichten Seite

Der eigentliche Wert eines Publishing-Systems liegt nicht in der Technik, sondern im Ablauf dahinter. Ein durchdachter Workflow sieht in etwa so aus.

Am Anfang steht die Themenfindung und Recherche. Hier darf KI helfen, indem sie Strukturvorschläge macht, Fragen sammelt oder Rohentwürfe liefert. Entscheidend ist, dass jede fachliche Aussage anschließend an einer belastbaren Quelle überprüft wird – offizielle Dokumentationen, Primärquellen, seriöse Fachmedien. Der KI-Entwurf ist Ausgangsmaterial, nicht Ergebnis.

Es folgt das Schreiben und Strukturieren. Der Text bekommt eine klare Überschriftenhierarchie, eine direkte Antwort nach der Hauptüberschrift, Beispiele, Grenzen und Risiken. Metadaten wie Titel, Beschreibung und Veröffentlichungsdatum werden festgelegt. In einem dateibasierten System geschieht das direkt in der Inhaltsdatei.

Dann kommt die redaktionelle Prüfung. Ein Mensch liest gegen, prüft Fakten, streicht unbelegte Superlative, trennt sauber zwischen Anbieterangaben und eigener Einordnung. In einem Git-basierten System ist der natürliche Ort dafür ein Branch mit einem Freigabeschritt: Der Artikel existiert erst nur im Zweig, wird geprüft und erst nach Freigabe zusammengeführt.

Erst danach folgen Build und Deployment. Der Generator erzeugt die fertigen Seiten, die Ausgabe wird kurz gesichtet, und dann geht sie online. Nach der Veröffentlichung schließt sich die Pflege an: Prüf- und Aktualisierungsdaten, spätere Korrekturen, das Nachziehen von Quellen. Weil alles in Git liegt, ist jede dieser Änderungen nachvollziehbar dokumentiert.

Was aus welcher Quelle stammt – Transparenz als Prinzip

Ein gutes Publishing-System zwingt einen dazu, die Herkunft von Aussagen sauber zu trennen. Die folgende Übersicht zeigt, wie das im Alltag aussieht.

Der praktische Nutzen: Wer diese Trennung ernst nimmt, produziert automatisch Inhalte, die sowohl für Leser als auch für Suchsysteme glaubwürdiger sind – weil sie prüfbar sind und nicht so tun, als wäre alles gleich sicher.

SEO und GEO – was ein statisches System kann und was nicht

Ein selbst gebautes Publishing-System hat bei der Suchmaschinenoptimierung einen strukturellen Vorteil: Man kontrolliert jede Zeile HTML. Individuelle Seitentitel, eindeutige Meta-Beschreibungen, saubere Überschriften, Breadcrumbs, interne Verlinkung, Canonical-Angaben, strukturierte Daten und eine korrekte Sitemap sind nicht von einem Plugin abhängig, sondern Teil der Vorlage. Ladezeiten sind bei statischen Seiten typischerweise sehr gut, und schnelle, schlanke Seiten sind eine solide Grundlage. Mehr dazu unter KI für SEO.

Für GEO (Generative Engine Optimization) – die Auffindbarkeit in KI-gestützten Antwortsystemen – gelten ähnliche Prinzipien: klare Definitionen, direkte Antworten nach der Überschrift, sichtbare Quellen, kurze Zusammenfassungen, FAQ-Bereiche, wo fachlich sinnvoll. Ein System, das strukturierte, gut belegte Inhalte erzwingt, spielt diesem Ziel in die Hände.

Zwei Grenzen muss man ehrlich benennen. Erstens: Niemand kann Rankings, Featured Snippets, AI Overviews oder Erwähnungen in KI-Systemen garantieren – wer das verspricht, ist unseriös. Zweitens gilt Googles Linie zu hilfreichen, für Menschen geschriebenen Inhalten: Massenhaft automatisiert erzeugter Text ohne echten Mehrwert ist ein Risiko, kein Vorteil. Die Technik erleichtert gutes Publizieren, sie ersetzt es nicht.

Die Risiken automatisierten Publizierens – klar benannt

Genau hier liegt die größte Gefahr solcher Systeme, und sie verdient einen eigenen Abschnitt. Wer das Erzeugen von Inhalten stark automatisiert, gerät leicht in Versuchung, auch die Veröffentlichung zu automatisieren. Das ist der Punkt, an dem gute Projekte scheitern.

Automatisiert ohne Prüfung veröffentlichte Inhalte können sachlich falsch sein, ohne dass es jemand merkt. Sie können rechtlich heikle Aussagen enthalten, unbelegte Behauptungen streuen oder schlicht dünn und wertlos sein. Bei Skalierung multipliziert sich jeder dieser Fehler. Und der Reputationsschaden, wenn eine erfundene „Studie" oder ein falscher Preis auffliegt, ist größer als jeder Zeitgewinn.

Die Konsequenz ist einfach und nicht verhandelbar: Automatisierung endet vor der Veröffentlichung. KI darf recherchieren, entwerfen, strukturieren und sogar gegenlesen. Den letzten Schritt – „das geht jetzt online" – macht ein Mensch, der die Verantwortung trägt.

Sicherheit und Datenschutz – fair und ohne Versprechen

Statische Seiten haben einen echten sicherheitstechnischen Vorteil: Ohne Datenbank und ohne serverseitig ausgeführten Anwendungscode fällt eine ganze Klasse klassischer Angriffe weg. Es gibt keine SQL-Datenbank, die man über eine Lücke im CMS abfragen könnte, und keine dutzenden Plugins, die aktuell gehalten werden müssen. Datensparsamkeit lässt sich sauber umsetzen: keine externen Schriften, keine unnötigen Tracker, keine API-Schlüssel im Frontend.

Trotzdem – und das ist wichtig – bedeutet „statisch" nicht „unangreifbar". Der Satz „Diese Website kann nicht gehackt werden" ist falsch und sollte nie fallen. Angriffsflächen verschieben sich nur: Sie liegen jetzt in der Lieferkette (welche Build-Werkzeuge und Bibliotheken vertraue ich?), im Umgang mit Zugangsdaten (FTP-Passwörter, Deployment-Tokens, Editor-Logins) und in eingebautem clientseitigem JavaScript, das bei unsauberer Umsetzung Cross-Site-Scripting ermöglichen kann. Ein Git-Editor mit schwacher Authentifizierung ist ebenso ein Einfallstor wie ein veraltetes Plugin.

Deshalb gehören auch zu einem schlanken System handfeste Vorkehrungen: Zugangsdaten und Tokens niemals im Repository ablegen, Abhängigkeiten bewusst wählen und aktuell halten, Nutzereingaben und dynamische Inhalte sauber behandeln, sichere Header und eine praktikable Content-Security-Policy vorbereiten, externe Links absichern. Vertiefung dazu unter KI-Sicherheit. Die Datenschutz-Grundverordnung verlangt datenschutzfreundliche Voreinstellungen und angemessene technische Maßnahmen – das ist bei einem datensparsamen Static-Setup leichter einzuhalten, aber es passiert nicht von allein.

WordPress und eigenes Publishing im direkten Vergleich

Die Tabelle ist bewusst keine Wertung „gut gegen schlecht". Sie zeigt Kompromisse. Fast jede Zeile ist für das eine Projekt ein Vorteil und für das andere ein Nachteil.

Meine eigene Erfahrung mit diesem Weg

Ich betreibe mehrere Websites bewusst als statische Projekte, weil der Ansatz zu ihnen passt – und ich habe dabei sowohl gute Erfahrungen als auch Lehrgeld gesammelt. Diese Einordnung ist meine persönliche Sicht als Betreiber, nicht ein neutrales Testurteil.

Bei kleineren, klar umrissenen Seiten wie einer Standort- und Angebotsseite für ein Lokal war der statische Weg ein Gewinn: schnelle Ladezeiten, praktisch keine Wartung, günstiges Hosting, und die Inhalte ändern sich selten genug, dass ein Build vor dem Upload nicht stört. Für solche Projekte würde ich WordPress heute nicht mehr aufsetzen.

Bei BOMOTS.de selbst ist der Vorteil ein anderer: Ich habe volle Kontrolle über jede Seite, kann strukturierte Daten, saubere Metadaten und Datensparsamkeit konsequent umsetzen und bin von keinem Plugin abhängig. Der Preis ist ehrlich: Ohne eine Redaktionsoberfläche muss man mit Dateien und einem Build-Prozess umgehen können. Für ein Team gemischter Kenntnisse würde ich deshalb eher zur Variante mit Git-basiertem Editor raten.

Meine wichtigste Lehre betrifft nicht die Technik, sondern die Disziplin. Der Reiz, mit KI schnell viel Text zu erzeugen, ist groß – und genau das ist die Falle. Die Projekte, bei denen ich zu schnell zu viel veröffentlicht habe, mussten später aufwendig nachgebessert werden. Die, bei denen ich jeden Text bewusst geprüft habe, bevor er online ging, haben mir diese Arbeit erspart. Ein bewusst als Prüfprojekt genutztes Vorhaben habe ich unter anderem dafür verwendet, genau diesen Ablauf – entwerfen, prüfen, dann erst bauen – für mich selbst zu testen. Die Erkenntnis war jedes Mal dieselbe: Der Flaschenhals ist nie die Technik, sondern die redaktionelle Sorgfalt.

Ein realistischer Plan in Phasen

Wer ein solches System aufbauen will, sollte nicht mit der Technik anfangen, sondern mit dem Inhalt.

In Phase 1 klärt man die Grundlagen: Welche Inhaltstypen gibt es? Wie sieht die URL- und Seitenstruktur aus? Wer schreibt, wer prüft, wer gibt frei? Diese Fragen entscheiden über den Rest und lassen sich vollständig ohne eine Zeile Code beantworten.

In Phase 2 wählt man die Variante. Einzelbetreiber mit technischer Grundkompetenz starten mit Dateien plus SSG. Kleine Teams mit gemischten Kenntnissen nehmen den Git-CMS-Mittelweg. Nur wer wirklich viele parallele Autoren und komplexe Inhaltsmodelle hat, prüft ein Headless CMS.

In Phase 3 baut man einen minimalen, funktionierenden Kern: ein paar echte Seiten, eine Vorlage, ein Build, ein Deployment per FTP. Kein Feature-Zoo, sondern ein durchgehender Weg vom Text bis zur Live-Seite. Erst wenn dieser Weg steht, kommen weitere Inhaltstypen, eine lokale Suche oder strukturierte Daten dazu.

In Phase 4 verfestigt man den redaktionellen Ablauf und die Pflege: Prüf- und Aktualisierungsdaten, Quellenführung, ein bewusster Freigabeschritt über Branches, gelegentliche Aktualisierung der Abhängigkeiten. Ab hier ist das System kein Bauprojekt mehr, sondern Routine.

Vibe Coding – also KI-gestützte, aber kontrollierte Softwareentwicklung – ist bei den Phasen 3 und 4 ein sehr nützliches Werkzeug, um Vorlagen und den Build zu erstellen, ohne alles von Hand zu schreiben. Auch hier gilt aber: Der erzeugte Code wird verstanden und geprüft, nicht blind übernommen. Wie KI beim Programmieren konkret hilft, zeigt KI für Coding.

Häufige Fehler, die den Weg teuer machen

Der erste und teuerste Fehler ist, ein vollwertiges CMS nachbauen zu wollen. Login-System, Rechteverwaltung, Editor, Medienbibliothek – all das existiert bereits ausgereift. Wer es neu schreibt, kauft sich Wartungslast ein, ohne einen Gegenwert zu schaffen.

Der zweite Fehler ist die automatisierte Veröffentlichung ohne Prüfung. Er wurde oben ausführlich behandelt, weil er so verbreitet und so folgenschwer ist.

Der dritte Fehler ist die Illusion der Unangreifbarkeit. „Statisch" reduziert Risiken, es beseitigt sie nicht. Wer Zugangsdaten sorglos behandelt oder Abhängigkeiten nie aktualisiert, hat nur die Angriffsfläche verschoben.

Der vierte Fehler ist, Menge mit Qualität zu verwechseln. Ein System, das tausend mittelmäßige Seiten pro Woche erzeugen kann, ist kein Vorteil, sondern ein Risiko. Die Frage ist nie, wie viel man publizieren kann, sondern was man verantworten kann.

Der fünfte Fehler ist, die falsche Variante für das Team zu wählen – etwa einen reinen Dateiweg für Redakteure, die nie mit einem Editor gearbeitet haben. Dann scheitert das System nicht an der Technik, sondern an der Bedienbarkeit.

Entscheidungshilfe: Was passt zu Ihnen?

Bleiben Sie bei WordPress, wenn Sie einen Shop, einen Mitgliederbereich oder viele dynamische Funktionen brauchen, wenn mehrere nicht-technische Personen parallel redaktionell arbeiten, oder wenn ein großes Plugin-Ökosystem für Sie ein echter Vorteil ist.

Wählen Sie ein Static-Site-System (Variante 1), wenn Sie ein inhaltsgetriebenes, überschaubares Projekt betreiben, Wert auf Geschwindigkeit, Datensparsamkeit und niedrige Kosten legen und mit Dateien und einem Build umgehen können oder es lernen wollen.

Nehmen Sie den Git-CMS-Mittelweg (Variante 2), wenn Sie die Robustheit statischer Seiten wollen, aber Redakteure eine bequeme Oberfläche brauchen.

Prüfen Sie ein Headless CMS (Variante 3) nur dann, wenn Ihr Team groß ist, viele parallel arbeiten und Sie Inhalte über mehrere Kanäle ausspielen. Und in allen Fällen gilt: Wenn Sie unsicher sind, beginnen Sie klein und ausbaubar, nicht groß und starr.

Mein Fazit

Ich halte ein eigenes KI-Publishing-System nicht für die Zukunft schlechthin und WordPress nicht für die Vergangenheit. Beide sind Werkzeuge, und die ehrliche Antwort auf „welches soll ich nehmen" lautet fast immer „kommt darauf an". Für meine eigenen inhaltsgetriebenen Projekte ist der statische Weg die richtige Entscheidung gewesen: Er zwingt mich zu Struktur, Datensparsamkeit und Sorgfalt, und er belohnt mich mit schnellen, wartungsarmen Seiten, die ich vollständig kontrolliere.

Der Kern, den ich jedem mitgeben würde, der mit dem Gedanken spielt: Bauen Sie kein CMS nach, automatisieren Sie nicht die Veröffentlichung, versprechen Sie keine Sicherheit, die es nicht gibt – und behandeln Sie KI als das, was sie ist: ein starkes Werkzeug im Entstehungsprozess, nicht als Redakteur mit Freigaberecht. Wenn Sie diesen einen Grundsatz einhalten, ist der Rest handwerkliche Fleißarbeit, die sich lohnt.

• KI für SEO
• KI für Content
• Praxis & Geschichte