Content automatisieren: vom einmaligen Lauf zur Pipeline, die selbst veröffentlicht

Ein einzelner Durchgang aus Diagnose und Fix nützt einmal. Ein Playbook sind dieselben Schritte, verdrahtet, damit sie von selbst laufen, nach Zeitplan oder Trigger, bis hin zum veröffentlichten Beitrag. Hier steht, wie das unter der Haube funktioniert.

~7 Min. Lesezeit . Automatisierung

Einmal analyze_content, dann optimize_content auszuführen und das Ergebnis zu veröffentlichen, ist nützlich. Dieselbe Abfolge jede Woche für jeden neuen Entwurf auszuführen, ohne dass Sie das Werkzeug jedes Mal öffnen, ist Automatisierung. Die Playbooks von AdAstra machen aus einem einmaligen Werkzeuglauf eine Pipeline: einen Graphen aus Schritten mit Verzweigungen, Wiederholungen und Zeitplan, der dort endet, wo der fertige Inhalt landen soll.

Vom einmaligen Lauf zur Pipeline

Ein Playbook ist ein gerichteter Graph aus Knoten und Kanten: Werkzeugaufrufe (analyze_content, optimize_content, optimize_headline, generate_keyword_ideas und die übrigen), verbunden mit Kontrollfluss-Knoten, die entscheiden, was als Nächstes läuft. An dem, was ein Werkzeug tut, ändert ein Playbook nichts; es ändert, wann es läuft, in welcher Reihenfolge und was mit seiner Ausgabe geschieht. Dieselbe Abfolge aus Analyse und Optimierung, die Sie von Hand ausführen würden, wird zu einem Lauf, den Sie einmal einrichten und beliebig oft wiederverwenden.

Unter der Haube läuft ein Durchgang von den Wurzelknoten durch den Graphen, führt jeden Knoten aus und folgt seinen ausgehenden Kanten zum jeweils nächsten. Jeder Knoten meldet seinen eigenen Status, ok oder Fehler, und seine Ausgabe; nachgelagerte Knoten greifen direkt auf diese Ausgabe zu, sodass ein späterer Schritt genau das liest, was ein früherer Werkzeugaufruf erzeugt hat, statt dass Sie Werte von Hand kopieren.

Playbooks und Kontrollfluss

Vier Knotenarten geben einem Playbook echte Logik statt einer geraden Linie. Ein if-Knoten wertet eine Menge von Bedingungen aus und schickt den Lauf in seinen Wahr- oder Falsch-Zweig. Ein switch-Knoten prüft eine Liste benannter Regeln der Reihe nach und folgt der ersten, die zutrifft, oder fällt auf einen Standardzweig zurück, wenn keine zutrifft. Ein filter-Knoten prüft eine Bedingung und lässt den Lauf entweder weiterlaufen (pass), oder der Zweig endet dort schlicht, ohne dass etwas nachgelagert passiert. Ein loop-Knoten läuft durch ein Array, entweder Element für Element (each) oder in Gruppen fester Größe (batch), und führt seinen Rumpf einmal je Element oder Gruppe aus, bis zu einer konfigurierten Höchstzahl an Durchläufen.

Die Bedingungen selbst sind überall derselbe Baustein: Ein Wert wird mit einem anderen verglichen, über Operatoren wie gleich, enthält, größer als, ist leer oder passt auf Regex, verknüpft mit UND oder ODER. Ein Knoten mit zwei oder mehr eingehenden Zweigen, eine Raute, in der zwei Pfade wieder zusammenlaufen, wartet auf jeden Zweig, der tatsächlich laufen wird, bevor er weitermacht, damit ein schneller Zweig nie einem langsameren davonläuft, der noch unterwegs ist.

Fehler werden pro Werkzeugknoten behandelt, nicht pro Playbook. Jeder Werkzeugaufruf trägt eine Wiederholungsregel, eine Höchstzahl an Versuchen und eine Wartezeit dazwischen, entweder als feste Verzögerung oder als exponentielles Backoff, das sich jedes Mal verdoppelt. Wiederholt werden nur Fehler, die als vorübergehend, etwa eine kurze Störung, oder als Rate-Limit eingestuft sind; ein dauerhafter Fehler wie eine ungültige Eingabe scheitert sofort. Sind die Wiederholungen aufgebraucht, entscheidet die onError-Einstellung des Knotens, was passiert: den ganzen Lauf stoppen, trotzdem auf dem regulären Pfad weitermachen oder einem eigenen Fehlerzweig folgen.

Zeitpläne und Trigger

Ein Playbook kann auf drei Wegen starten. Ein manueller Trigger startet es auf Zuruf, so wie ein von Hand ausgeführtes Werkzeug. Ein Webhook-Trigger gibt dem Playbook eine eigene, tokengeschützte URL, sodass ein externes System oder Sie selbst einen Lauf per Request starten können. Ein Cron-Trigger führt das Playbook nach einem wiederkehrenden Zeitplan aus, definiert als Cron-Ausdruck mit eigener Zeitzone.

cron: "0 8 * * 1"
timezone: "Europe/Berlin"
# illustrative: every Monday at 08:00, Europe/Berlin

Das ist ein beispielhafter Zeitplan, kein fester Standard: Jeder gültige Cron-Ausdruck wird akzeptiert und beim Speichern des Triggers geprüft, statt später zur Laufzeit für Überraschungen zu sorgen. Die nächste Laufzeit eines Cron-Triggers wird aus Ausdruck und Zeitzone zusammen berechnet, damit ein Zeitplan über eine Zeitumstellung hinweg „acht Uhr morgens“ bedeutet, statt um eine Stunde zu verrutschen.

Ein Hintergrund-Tick sammelt alle Playbooks ein, die gerade fällig sind, und führt jedes einzeln aus, in einer eigenen Fehler- und Timeout-Domäne, damit ein hängender Lauf den Rest des Stapels nicht blockiert. Am wichtigsten ist, was passiert, wenn ein Playbook noch läuft, während sein nächster Slot ansteht: AdAstra beansprucht jeden Lauf atomar, bevor er startet, sodass ein bereits laufendes Playbook nicht ein zweites Mal obendrauf angestoßen werden kann. Ein Cron-Slot, der mitten in einen Lauf fällt, wird als übersprungen vermerkt und nicht als überlappender Lauf gestartet. Nur ein per Cron ausgelöster Lauf schiebt den Zeitplan weiter; ein manueller Lauf verbraucht nie den nächsten Cron-Slot.

In WordPress veröffentlichen

Die Veröffentlichung in WordPress ist kein Knoten im oben beschriebenen Playbook-Graphen: Die Werkzeugsammlung, aus der ein Playbook schöpft, enthält kein WordPress-Werkzeug, also kann kein tool_call-Knoten die Ausgabe eines Laufs direkt auf eine Website bringen. Sie läuft stattdessen über eine zweite, getrennte Automatisierungsebene. Wenn Sie AdAstra bitten, die Veröffentlichung zu automatisieren, täglich, wöchentlich, zweiwöchentlich oder monatlich, wird ein wiederkehrender Auftrag gegen ein verbundenes WordPress-Profil angelegt, unabhängig vom graphbasierten Zeitplaner oben.

Dieser Auftrag authentifiziert sich so wie überall sonst in AdAstra: gegen den JWT-Endpunkt der Website (wp-json/jwt-auth/v1/token) mit Ihren WordPress-Zugangsdaten, und nutzt das erhaltene Token dann, um den Beitrag über die Standard-REST-API von WordPress (wp-json/wp/v2/posts) anzulegen, mit Titel, Inhalt, Tags und, falls angegeben, einem Beitragsbild, das zuvor in die Mediathek hochgeladen wird. Den Status des entstehenden Beitrags wählen Sie wie beim Veröffentlichen von Hand: sofort live oder als Entwurf, damit ein Mensch zuerst darüberschaut.

Leitplanken

Automatisierung schaltet die Prüfungen nicht ab, die überall sonst in AdAstra gelten. Ein geplanter oder per Webhook ausgelöster Lauf ruft dieselben Werkzeuge analyze_content, optimize_content und optimize_headline auf, die an anderer Stelle beschrieben sind: dieselbe Diagnose über drei Themen, dieselben verankerten Google-Ads-Zahlen, keine erfundenen Keyword-Daten als Ersatz für eine gescheiterte Abfrage. Auch ein Fehler in einem Playbook ist kein stilles Überspringen: Er wird am Knoten mit seiner Fehlerklasse vermerkt und stoppt entweder den Lauf oder folgt dem von Ihnen konfigurierten Fehlerpfad.

Die Verhinderung doppelter Läufe zählt vor allem als Leitplanke, nicht als Bequemlichkeit. Ohne atomaren Anspruch auf jeden Lauf könnte ein überlappender Trigger einen zweiten Durchgang über Inhalte starten, die ein erster noch nicht fertig optimiert hat, oder einen doppelten Entwurf aus einem Lauf veröffentlichen, der hätte übersprungen werden sollen. Den Lauf zu beanspruchen, bevor irgendein Werkzeug ausgeführt wird, macht eine geplante Pipeline überhaupt erst unbeaufsichtigt betreibbar.

Die Kurzfassung

• Ein Playbook ist ein Graph aus Werkzeugaufrufen und Kontrollfluss-Knoten; es ändert, wann und in welcher Reihenfolge Werkzeuge laufen, nicht was ein einzelnes Werkzeug tut.
• if-, switch-, filter- und loop-Knoten geben einem Playbook Verzweigungen, benannte Regeln, Abbruchbedingungen und Iteration je Element oder Gruppe, alle gesteuert über dieselben UND/ODER-Bedingungszeilen.
• Jeder Werkzeugknoten trägt seine eigene Wiederholungsregel (feste oder exponentielle Wartezeit, nur vorübergehende und Rate-Limit-Fehler) und eine onError-Einstellung: stoppen, regulär weiter oder in den Fehlerzweig.
• Playbooks starten manuell, über einen tokengeschützten Webhook oder über einen Cron-Zeitplan mit eigener Zeitzone; nur ein per Cron ausgelöster Lauf schiebt diesen Zeitplan weiter.
• Ein atomarer Run-Claim verhindert, dass ein Playbook zweimal gleichzeitig läuft; ein Cron-Slot mitten im Lauf wird als übersprungen vermerkt statt als zweiter, überlappender Lauf gestartet.
• Die Veröffentlichung in WordPress ist eine eigene, taktbasierte Automatisierung und kein Playbook-Schritt: Ein wiederkehrender Auftrag veröffentlicht über JWT-Authentifizierung und die Standard-REST-API auf einer verbundenen Website, als Live-Beitrag oder als Entwurf zur Prüfung.
• Für automatisierte Läufe gibt es keine Ausnahmen bei der Datenqualität: Dieselbe verankerte Diagnose und Optimierung gelten, und Fehler werden vermerkt und geroutet, nie still übersprungen.