Wer regelmäßig Inhalte für mehrere Websites veröffentlichen möchte, merkt relativ schnell, dass das eigentliche Schreiben nur einen Teil der Arbeit ausmacht. Themen müssen geplant, Überschneidungen erkannt, Suchintentionen geprüft, Artikel erstellt, interne Verweise gesetzt, Texte kontrolliert und Veröffentlichungen zeitlich gesteuert werden. Wenn all diese Informationen über einzelne Chatverläufe, Notizen und Dateien verteilt bleiben, lässt sich die eigentliche Texterzeugung zwar automatisieren, der gesamte Prozess darum herum aber nicht.
Genau deshalb entwickle ich Kosmos.Puls. Puls soll nicht einfach Texte mit einer KI erzeugen, sondern den vollständigen Weg eines Inhalts von der Themenidee bis zur Veröffentlichung strukturieren. Ein Thema kann lange vor dem eigentlichen Artikel existieren, ein fertiger Artikel kann bereits auf der Website liegen, ohne sichtbar zu sein, und eine Veröffentlichung kann zu einem späteren Zeitpunkt erfolgen, ohne dass ich an diesem Tag überhaupt etwas auslösen muss.
Damit wird Contentproduktion für mich zunehmend zu einem vorbereitbaren Prozess, der deutlich näher an meiner automatisierten Softwareentwicklung liegt, als es auf den ersten Blick erscheint.
Themenplanung muss vor der eigentlichen Texterzeugung stattfinden
Wenn ich jeden Tag spontan entscheide, worüber als Nächstes geschrieben werden soll, kann ich zwar regelmäßig Inhalte produzieren, entwickle aber kaum eine systematische Wissensbasis. Themen überschneiden sich, wichtige Bereiche bleiben möglicherweise jahrelang unberührt, und ähnliche Artikel entstehen mehrfach, weil nicht mehr eindeutig nachvollziehbar ist, was bereits geplant oder veröffentlicht wurde.
Puls soll deshalb bereits die Themenebene verwalten. Themen erhalten stabile IDs, können einem späteren Artikel zugeordnet werden und bleiben auch dann nachvollziehbar, wenn sich der endgültige Titel im Laufe der Ausarbeitung verändert. Dadurch lässt sich eine größere Contentplanung vorbereiten, ohne jeden einzelnen Artikel sofort schreiben zu müssen.
Gerade bei umfangreichen Themengebieten möchte ich vollständige Blöcke vorausplanen können. Wenn beispielsweise ein Bereich aus zwanzig sinnvoll aufeinander aufbauenden Artikeln besteht, sollen diese Themen bereits feststehen, bevor die eigentliche Produktion beginnt. Das schafft Struktur und erleichtert später sowohl interne Verlinkungen als auch Newsletter oder thematische Übersichten.
Vorproduktion verändert meinen Veröffentlichungsprozess grundlegend
Für mich ist besonders wichtig, Artikel nicht erst am Tag ihrer Veröffentlichung erzeugen zu müssen. Wenn die Themen feststehen und die notwendigen Informationen vorhanden sind, kann die Produktion deutlich früher stattfinden. Ein Text kann bereits vollständig auf der Website liegen, dort aber solange unsichtbar bleiben, bis sein Veröffentlichungsdatum erreicht ist.
Dadurch lässt sich Contentproduktion von meinem täglichen Kalender entkoppeln. Eine Phase mit verfügbarer Zeit oder KI-Kapazität kann genutzt werden, um zahlreiche Artikel vorzubereiten, während die eigentliche Veröffentlichung anschließend über Wochen hinweg automatisch erfolgt. Der sichtbare Rhythmus bleibt regelmäßig, obwohl die Arbeit dahinter längst abgeschlossen sein kann.
Diese Trennung wirkt für mich ähnlich wie Agenda bei Softwareaufgaben. Eine vorbereitete Arbeit ist noch nicht automatisch eine ausgeführte beziehungsweise veröffentlichte Arbeit. Zwischen beiden Zuständen liegt eine bewusste Freigabe und gegebenenfalls ein festgelegter Zeitpunkt.
Markdown bleibt die zentrale Inhaltsquelle
Meine Wissensartikel werden als Markdown-Dateien mit YAML-Frontmatter gespeichert. Dort stehen unter anderem eine stabile ID, Titel, Slug, Beschreibung, Kategorie, Lesezeit und Veröffentlichungsinformationen, während der eigentliche Artikeltext darunter folgt. Die Website verarbeitet diese Datei anschließend und erzeugt daraus die sichtbare Seite.
Für Puls ist dieses Format praktisch, weil Inhalte dadurch unabhängig von einer bestimmten Administrationsoberfläche bleiben. Ein Artikel kann von mir, ChatGPT, Codex oder einem späteren automatisierten Prozess erzeugt und trotzdem im selben standardisierten Format weiterverarbeitet werden. HTML oder konkrete Layoutdetails müssen dabei nicht Bestandteil der eigentlichen Contentproduktion sein.
Die Website bleibt für Darstellung und Veröffentlichung verantwortlich, während Puls den inhaltlichen Prozess organisiert. Diese Trennung verhindert, dass die Contentverwaltung zu eng an die technische Darstellung einer einzelnen Website gekoppelt wird.
Stabile Artikel-IDs erleichtern interne Verlinkungen
Interne Links sind bei einer größeren Wissensbasis besonders wertvoll, können bei manueller Pflege aber schnell unübersichtlich werden. Wenn ein Artikel direkt auf eine bestimmte URL verweist und sich der Slug später ändert, muss der Link entweder nachgezogen werden oder führt irgendwann ins Leere.
Deshalb verwende ich stabile Artikel-IDs und eine eigene Verweissyntax wie [[article:123|natürlicher Linktext]]. Die Website kann daraus beim Rendern die jeweils aktuelle URL erzeugen, während der Artikel selbst weiterhin auf die unveränderliche ID verweist.
Für Puls eröffnet diese Struktur weitere Möglichkeiten. Das System kann erkennen, welche Artikel aufeinander verweisen, welche Themen innerhalb eines Bereichs kaum miteinander verbunden sind und wo möglicherweise sinnvolle interne Links fehlen. Dadurch wird aus der reinen Linksetzung langfristig ein Teil der Contentstruktur.
Wichtig bleibt für mich dabei, dass Links im Text natürlich wirken und nicht als künstliche SEO-Blöcke unter einem Artikel stehen. Die technische Stabilität soll im Hintergrund helfen, ohne den Lesefluss zu verschlechtern.
Mehrere Websites brauchen gemeinsame Technik und unterschiedliche Regeln
Puls soll Inhalte für mehrere Websites verwalten, deren Zielgruppen und Schreibweisen deutlich voneinander abweichen. felderhoff.it richtet sich an Unternehmen und Entscheider, netzwerk-ninjas.de an Privathaushalte, während endlich-montag.it stärker meine Softwareentwicklung, KI-Arbeitsweise und eigenen Projekte behandelt.
Die technische Verarbeitung kann trotzdem weitgehend gemeinsam bleiben. Frontmatter, stabile IDs, Veröffentlichungslogik und interne Referenzen funktionieren nach denselben Grundprinzipien, während Stil, Ansprache, Suchintention und inhaltliche Regeln je Marke unterschiedlich bleiben.
Gerade für automatisierte Texterzeugung ist diese Trennung wichtig. Eine gemeinsame technische Plattform darf nicht dazu führen, dass am Ende alle Websites gleich klingen. Puls muss deshalb sowohl globale Regeln als auch markenspezifische Vorgaben berücksichtigen können.
Suchintention beginnt bereits beim Thema und nicht erst beim fertigen Artikel
Ein häufiger Fehler bei Contentplanung besteht darin, zunächst aus interner Sicht ein Thema zu formulieren und erst später zu versuchen, daraus irgendwie eine suchmaschinenfreundliche Überschrift zu machen. Für kundenorientierte Inhalte möchte ich inzwischen den umgekehrten Weg gehen.
Titel, Slug und Beschreibung sollen möglichst nah an realen Fragen oder Problemen liegen, nach denen die jeweilige Zielgruppe tatsächlich suchen würde. Der technische Lösungsbegriff kommt nur dann nach vorne, wenn er selbst Teil dieser Suchintention ist.
Der aktuelle Artikel ist dafür ein gutes Beispiel. Intern heißt die Anwendung Puls, aber jemand, der dieses Problem sucht, wird eher nach „Content-Planung automatisieren“ oder einer ähnlichen Formulierung suchen als nach einem Produktnamen, den er noch gar nicht kennt.
Diese Denkweise möchte ich bereits in Puls verankern, damit Suchintention nicht erst am Ende als SEO-Korrektur über einen ansonsten intern gedachten Artikel gelegt wird.
Qualitätssicherung gehört zwischen Erzeugung und Veröffentlichung
Dass eine KI einen Artikel erzeugen kann, bedeutet für mich nicht, dass dieser Text automatisch veröffentlicht werden sollte. Gerade bei fachlichen Aussagen, persönlichen Erfahrungen und geschäftlichen Inhalten möchte ich weiterhin bewusst prüfen können, was unter meinem Namen erscheint.
Puls soll deshalb mehrere Zustände zwischen Thema und Veröffentlichung abbilden können. Ein Artikel kann erzeugt, technisch geprüft, inhaltlich kontrolliert und freigegeben werden, bevor der öffentliche Veröffentlichungsstatus erreicht wird. Automatisierung darf dabei gerne möglichst viele Routineprüfungen übernehmen, die endgültige Freigabe soll jedoch sichtbar bleiben.
Das passt zu meiner allgemeinen Arbeitsweise mit KI. Ich möchte operative Arbeit reduzieren, ohne die Verantwortung für relevante Entscheidungen unsichtbar an das System abzugeben.
Newsletter können auf vorhandenen Artikeln aufbauen
Ein weiterer Grund für die strukturierte Themenplanung liegt in der späteren Wiederverwendung der Inhalte. Wenn ein Themenbereich ausreichend viele Artikel enthält, kann daraus ein Newsletter entstehen, der die wichtigsten Punkte zusammenfasst und auf die ausführlicheren Wissensartikel verweist.
Dadurch muss ein Newsletter nicht jedes Mal als völlig neues Stück Content beginnen. Die fachliche Grundlage ist bereits vorhanden, wurde geprüft und kann für ein anderes Format neu aufbereitet werden.
Langfristig kann Puls dadurch mehrere Ebenen miteinander verbinden: einzelne Artikel, Themencluster, Newsletter und weitere Formate. Die Voraussetzung dafür ist allerdings, dass die Inhalte von Anfang an sauber strukturiert und nicht nur als lose Folge einzelner Blogbeiträge behandelt werden.
Puls soll den Prozess automatisieren, nicht nur das Schreiben
Eine KI kann auch ohne Puls einen brauchbaren Artikel erzeugen. Genau deshalb liegt der eigentliche Wert der Anwendung für mich nicht in der Texterzeugung selbst. Spannend ist vielmehr die Kette aus Themenplanung, Vorbereitung, Generierung, Prüfung, interner Verlinkung, Freigabe, Vorproduktion und Veröffentlichung.
Wenn diese Schritte strukturiert ablaufen, muss ich nicht jeden einzelnen Artikel immer wieder von vorne organisieren. Ich kann stattdessen Themenbereiche vorbereiten und das System anschließend einen erheblichen Teil der operativen Arbeit übernehmen lassen.
Puls macht aus KI-generiertem Schreiben damit einen kontrollierbaren Produktionsprozess. Für mich ist genau das der Unterschied zwischen gelegentlicher Nutzung eines Sprachmodells und einer dauerhaft funktionierenden Contentplattform.