An einem Abend habe ich für einen meiner Blogs eine Automatisierung gebaut, die neue Beiträge selbstständig auf Facebook und Instagram veröffentlicht. Sie läuft, sie hat einen gefüllten Redaktionsplan bis Anfang Oktober, und sie hat mich unterwegs vier Fehler gelehrt, die ich vorher nicht auf dem Zettel hatte.
Diese Serie ist das Protokoll. Kein Tutorial, das so tut, als hätte alles beim ersten Versuch funktioniert – sondern der tatsächliche Verlauf mit den Sackgassen. Wenn du etwas Ähnliches vorhast, sparst du dir damit hoffentlich ein paar Stunden.
In diesem ersten Teil geht es um die Entscheidung, die alles Weitere bestimmt: den Zuschnitt der Workflows. Sie sieht nach einer reinen Geschmacksfrage aus und ist in Wirklichkeit der Unterschied zwischen einer Automatisierung, die man betreiben kann, und einer, die man dauernd nachjustiert.
Die Ausgangslage
Der Blog erscheint unregelmäßig. Mal kommen drei Beiträge in einer Woche, dann sieben Monate nichts. Auf der zugehörigen Facebook-Seite lag der letzte Beitrag zehn Monate zurück. Instagram existierte, war aber praktisch ungenutzt.
Das Ziel klang simpel: Wenn ein neuer Beitrag erscheint, soll er auf beiden Kanälen auftauchen. Zeitversetzt, nicht als Salve.
Genau dieses „zeitversetzt“ ist der Grund, warum die naheliegende Lösung nicht funktioniert.
Der naheliegende Weg – und warum er scheitert
Man nimmt einen Trigger, hängt einen KI-Node dran, dahinter die Publish-Nodes, fertig. Ein Workflow, eine Kette, leicht zu verstehen.
Das Problem: Diese Kette koppelt zwei Dinge fest aneinander, die nichts miteinander zu tun haben – wann ein Beitrag erscheint und wann er auf Social Media läuft.
Erscheinen drei Beiträge an einem Vormittag, gehen drei Posts an einem Vormittag raus. Erscheint einen Monat lang nichts, ist es einen Monat lang still. Der Takt deines Social-Media-Kanals wird zum Spiegelbild deiner Redaktionslaune. Für einen Kanal, der Reichweite aufbauen soll, ist das die falsche Kopplung.
Man kann versuchen, das mit Wartezeiten im Workflow zu flicken. Ein Wait-Node, der zwei Stunden hält. Dann sechs. Das verschiebt das Problem nur: Bei drei Beiträgen an einem Tag hast du drei parallele Ausführungen, die alle warten, und niemand koordiniert sie. Und Wartezeiten über Tage hinweg sind fragil – jeder Neustart der Instanz, jede Migration bringt sie durcheinander.
Die Trennung
Die Lösung ist unspektakulär und macht den entscheidenden Unterschied: zwei Workflows und eine Tabelle dazwischen.
- Workflow 1 läuft stündlich, sucht neue Beiträge, erzeugt die Texte und legt einen Eintrag in einer Warteschlange ab. Er veröffentlicht nichts.
- Workflow 2 läuft zu festen Uhrzeiten, nimmt einen fälligen Eintrag aus der Warteschlange und postet ihn. Er erzeugt nichts.
Dazwischen liegt eine Datentabelle mit einer Statusspalte.
Diese Trennung ist der Kern der ganzen Konstruktion, und sie zahlt sich an mehreren Stellen aus:
Der Posting-Takt wird unabhängig von der Redaktion. Ob ein Beitrag oder zehn eingehen, ist für Workflow 2 gleichgültig. Er arbeitet seinen Rhythmus ab.
Fehler betreffen nur eine Seite. Fällt die Textgenerierung aus, weil ein Modellanbieter zickt, postet Workflow 2 weiter, was schon in der Warteschlange liegt. Fällt das Posten aus, weil ein Token abgelaufen ist, sammelt Workflow 1 trotzdem weiter ein. Nichts geht verloren.
Es entsteht ein Kontrollpunkt. Zwischen Erzeugen und Veröffentlichen liegt ein Zustand, den man ansehen, ändern und ablehnen kann. Bei KI-erzeugten Texten ist das keine Bequemlichkeit, sondern eine Notwendigkeit – dazu gleich mehr.
Wiederholen wird trivial. Ein fehlgeschlagener Post steht mit Status fehler in der Tabelle. Behebe die Ursache, setze den Status zurück, fertig. Ohne Warteschlange müsstest du den ganzen Erzeugungsvorgang wiederholen – inklusive der Kosten für den Modellaufruf.
Die Warteschlange ist kein Zwischenspeicher
Es lohnt sich, den Gedanken noch weiterzudrehen. Die Tabelle sieht aus wie technischer Kleinkram – ein bisschen Zustand zwischen zwei Schritten. Tatsächlich ist sie das inhaltliche Zentrum.
In ihr steht pro Beitrag: die Post-ID, der Titel, die URL, die Bild-URL, der fertige Facebook-Text, der fertige Instagram-Text, ein Status, ein geplanter Termin und – nach dem Posten – die IDs der erzeugten Beiträge.
Damit ist sie gleichzeitig:
- Redaktionsplan – was kommt wann
- Freigabemappe – was noch geprüft werden muss
- Doppel-Schutz – was schon dran war
- Protokoll – was wann rausging, mit Beleg
- Sperrliste – was nie erscheinen soll
Der letzte Punkt hat mich selbst überrascht. Als ich vierzehn alte Beiträge dauerhaft ausschließen wollte, war mein erster Reflex, eine Ausschlussliste im Code anzulegen. Dann fiel mir auf: Die Workflows prüfen ohnehin schon bei jedem Durchlauf, ob eine Post-ID bereits in der Tabelle steht – das ist der Doppel-Schutz. Also habe ich die vierzehn schlicht als Zeilen mit dem Status gesperrt eingetragen.
Kein neuer Filter, kein zweiter Ort zum Pflegen. Der Mechanismus, der Doppelposts verhindert, verhindert jetzt auch Unerwünschtes. Und rückgängig machen heißt: Zeile löschen.
Wenn du eine Automatisierung baust und dir eine zweite Liste einfällt – prüfe erst, ob ein vorhandener Mechanismus die Arbeit schon tut.
Warum überhaupt selbst bauen?
Eine berechtigte Zwischenfrage: Für „Blogbeitrag automatisch auf Social Media“ gibt es fertige Dienste. Buffer, Hootsuite, Later, dazu ein Dutzend jüngerer Anbieter. Viele davon lesen einen RSS-Feed und posten daraus.
Für viele Fälle ist das die richtige Antwort, und ich würde niemandem abraten. Drei Dinge haben bei mir dagegen gesprochen.
Der Text. Fertige Dienste posten Titel plus Link, manchmal mit KI-Beiwerk. Was ich wollte – Stichpunkte, die aus der tatsächlichen Gliederung des Beitrags stammen –, geht dort nicht. Genau darin liegt aber der Unterschied zwischen einem Post, der etwas sagt, und einem, der nur ankündigt. Teil 2 handelt davon.
Der Bestand. Achtzig alte Beiträge saisonal sortiert nachzuziehen ist keine Funktion, die ein RSS-basierter Dienst anbietet. Dafür braucht es eine eigene Liste mit eigenen Regeln.
Die Kontrolle über die Zwischenstufe. Bei einem fertigen Dienst siehst du den Text, wenn er draußen ist – oder in einer Vorschau, die man nicht mit eigenen Regeln filtern kann. Ich wollte einen Zustand, den ich abfragen, ändern und sperren kann.
Der Preis dafür ist ehrlich zu benennen: Ich betreibe jetzt Infrastruktur. Eine n8n-Instanz, Zugangsdaten, die ablaufen können, Workflows, die bei API-Änderungen nachgezogen werden müssen. Wer nur Titel plus Link posten will, zahlt mit einem fertigen Dienst weniger – nicht in Geld, sondern in Aufmerksamkeit.
Der dritte Workflow
Später kam eine Aufgabe dazu, die ich anfangs nicht eingeplant hatte: Der Blog hatte rund achtzig ältere Beiträge, die nie auf Social Media waren. Die sollten nachgezogen werden – aber saisonal passend. Ein Beitrag über Winter-Survival im August wäre albern.
Dafür entstand Workflow 3. Er trägt eine kuratierte Liste, in der jeder Beitrag ein Monatsfenster hat, filtert auf den aktuellen Monat und reiht ein, was passt.
Und hier zeigte sich der Vorteil der Trennung noch einmal deutlich: Workflow 3 musste nichts über Facebook oder Instagram wissen. Er schreibt in dieselbe Warteschlange, und Workflow 2 arbeitet sie ab, ohne zu unterscheiden, woher ein Eintrag stammt. Eine neue Quelle anzuschließen kostete keine Änderung am Posting-Teil.
Bewusst ist er manuell gestartet, nicht per Zeitplan. Er löst Modellaufrufe für viele Beiträge auf einmal aus – das will ich kontrollieren, nicht nachts überrascht werden.
Was mich das gekostet hat, was ich nicht erwartet hatte
Vier Dinge sind unterwegs schiefgegangen, und drei davon hätte ich nie vorhergesagt:
Das Sprachmodell hat eine URL falsch abgeschrieben. Aus einem Slug mit „haustuer“ wurde „tuer“. Ein toter Link, in einem Post, der ohne Kontrolle live gegangen wäre. Sprachmodelle sind beim wortgetreuen Kopieren langer Zeichenketten unzuverlässig – ein Punkt, den man beim Prompt-Design mitdenken muss und der die Lösung diktiert: Das Modell darf die URL gar nicht erst schreiben.
Die Bilder hatten das falsche Format. Der Blog liefert Beitragsbilder als WebP aus. Facebook nimmt bei Foto-Uploads kein WebP, Instagram verlangt eine öffentlich erreichbare JPEG-URL. Ohne Umwandlung wäre jeder einzelne Post gescheitert.
Die Meta-Berechtigungen haben mich drei Messrunden gekostet, weil die API auf fehlende Rechte mit Schweigen statt mit einem Fehler antwortet.
Ein Code-Node hat nur das erste von neunundvierzig Elementen verarbeitet – still, ohne Fehlermeldung. Der Massenlauf lief durch und reihte genau einen Beitrag ein.
Jeder dieser Punkte bekommt in dieser Serie seinen Platz, weil jeder eine übertragbare Lehre enthält.
Was die Trennung nicht löst
Der Ehrlichkeit halber: Die Aufteilung hat auch Preise.
Es gibt jetzt drei Workflows statt einem, und zwei davon enthalten fast identische Textbausteine. Ändere ich den Prompt, muss ich an zwei Stellen ran. Das ist echte Duplizierung, und sie wird mich irgendwann beißen. Ich habe es in Kauf genommen, weil die Alternative – ein Unter-Workflow, den beide aufrufen – die Sache an anderer Stelle verkompliziert hätte. Aber es ist eine bewusste Schuld, keine elegante Lösung.
Und: Eine Warteschlange muss man pflegen. Einträge, die auf fehler stehen, verschwinden nicht von selbst. Wer nie hineinschaut, merkt Ausfälle spät.
Was in dieser Serie kommt
Die weiteren Teile arbeiten die Bausteine der Reihe nach ab. Jeder ist für sich lesbar.
- Teil 1: Warum Texten und Posten getrennt gehören – dieser Beitrag
- Teil 2: Texte, die etwas sagen – warum der WordPress-Auszug als Grundlage nicht reicht und wie aus der Gliederung brauchbare Stichpunkte werden
- Teil 3: Die Warteschlange als Redaktionsplan – Datentabelle, Termine, Doppel-Schutz, Sperrliste
- Teil 4: Posten auf Facebook und Instagram – Bildformate, der zweistufige Instagram-Weg, Fehlerpfade
- Teil 5: Altbestand nachziehen und der Betrieb – Saisonfenster, Massenläufe und was danach zu tun bleibt
Wenn du nur einen Gedanken aus diesem Teil mitnimmst, dann diesen: Trenne das Erzeugen vom Veröffentlichen und lege einen sichtbaren Zustand dazwischen. Alles andere in dieser Serie ist Handwerk. Das hier ist die Entscheidung, die trägt.
