Content-Automatisierung: Bilanz nach zwei Tagen

Werkstattbericht Content-Automatisierung – Teil 8 von 8. Wie ich für einen meiner Blogs die Beitragsproduktion mit n8n und Claude automatisiert habe: was funktioniert hat, was nicht, und was am Ende dabei herauskam. Zu den anderen Teilen: 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8.

Ich fange mit dem Satz an, der in Berichten dieser Art fast nie steht:

Ich weiß noch nicht, ob es funktioniert.

Am Anfang dieser Serie standen null Klicks in drei Monaten. Am Ende steht ein Workflow mit 135 Nodes, fünf eigenen Code-Nodes, einem zweiten Workflow zur Nachpflege, einer PHP-Datei auf dem Server und einer Tabelle mit 1.121 geplanten Beiträgen. Was nicht am Ende steht, ist ein einziger zusätzlicher Klick. Dafür ist es zu früh.

Wer dir eine Content-Automatisierung mit Erfolgszahlen verkauft, die zwei Tage alt ist, verkauft dir etwas anderes als einen Werkstattbericht.

Dies ist Teil 8, der letzte. Bilanz.

Was am Ende steht

Der Stand in Zahlen

Die Kette von hinten

So sieht der Weg eines Beitrags heute aus, ab dem Punkt, an dem die Kapitel geschrieben sind:

Artikel zusammensetzen
  → Bereinigung            (Quellenmarker, kaputte href, Mehrfachlinks, Codefences)
  → Stil überarbeiten      (Floskeln, Wiederholungen, Nominalstil)
  → Überarbeitung prüfen   (verwirft bei Schrumpfung, geänderten Überschriften, fehlenden Zahlen)
  → Interne Links planen   (sieht den ganzen Artikel + 8 Kandidaten mit Titel und Anriss)
  → Links einfügen         (sechs Prüfungen, jede Verwerfung protokolliert)
  → Abschlussblöcke        (Weiterlesen + bedingter Hinweisblock)
  → Markdown → HTML
  → WordPress als Entwurf
  → Yoast-Felder setzen
  → Yoast-Felder nachlesen und vergleichen
  → Zeile in die Ergebnistabelle

Und diese Zeile in der Ergebnistabelle ist, wenn ich ehrlich bin, das eigentliche Ergebnis dieser zwei Tage. Sie enthält inzwischen sieben Spalten, die es vorher nicht gab: Cleanup Report, Prüfung nötig, Interne Links, Hinweisblock, Fokus-Keyphrase, Yoast, Stil.

Der Unterschied zwischen einer Automatisierung, die man betreiben kann, und einer, die man fürchtet, ist genau diese Zeile. Ohne sie müsste ich 1.121 Beiträge gleich gründlich lesen. Mit ihr sehe ich, welche davon Aufmerksamkeit brauchen.

Was noch offen ist

Ich liste das vollständig auf, auch die unangenehmen Punkte.

Die Baustellen im Workflow

Die Fehlerbehandlung fehlt weiterhin. Das ist der größte offene Punkt. Scheitert ein Lauf, bleibt die Tabellenzeile auf „In Progress“ stehen, wird nie wieder aufgegriffen und taucht nirgends als Fehler auf. Der Falsch-Zweig der Eingabeprüfung ist nach wie vor nicht verbunden. Ich habe das bewusst nicht im Vorbeigehen repariert – eine Fehlerbehandlung, die man nicht durchgetestet hat, ist schlimmer als keine, weil man sich auf sie verlässt.

Schlagwörter mit Umlauten erzeugen vermutlich Dubletten. Der Workflow sucht ein vorhandenes Schlagwort über ?slug=ausrüstung. WordPress speichert Slugs aber ohne Umlaute – je nach Spracheinstellung als ausrustung oder ausruestung. Die Suche findet das vorhandene Schlagwort dann nicht und legt ein neues an. Prüfbar in einer Minute: in WordPress unter Beiträge → Schlagwörter nachsehen, ob dort Paare wie „ausrüstung“ und „ausruestung“ stehen. Ich habe es nicht blind korrigiert, weil die Umschrift von der Locale abhängt und ich sie nicht raten wollte.

Das Schlagwort-Schema widerspricht dem Prompt. Der Ausgabeparser deklariert "tags": "string" – einen einzelnen Text. Das Beispiel im selben Prompt zeigt eine Liste. Was davon deine n8n-Version daraus macht, sieht man am schnellsten an einem erzeugten Entwurf: Hängen dort fünf bis zehn einzelne Schlagwörter oder ein einziges langes?

Eine fachliche Endprüfung gibt es nicht. Der Gedanke aus Teil 3 – ein Modellaufruf, der den fertigen Text gegen eine Liste von Sachverhalten prüft, die im jeweiligen Gebiet nicht vorkommen dürfen – ist nicht gebaut. Er braucht Ausschlusslisten je Sachgebiet, und die muss jemand schreiben, der das Gebiet kennt.

Neue Beiträge bekommen weiterhin kaum eingehende Links. Der Weiterlesen-Block aus Teil 6 mildert das, löst es aber nicht.

Die Baustellen daneben

Die neuen Kategorien sind nie angelegt worden. In meiner Themen-Tabelle stehen ausschließlich IDs vorhandener Kategorien. Die vorgeschlagene neue Struktur – 19 Haupt- und 11 Unterkategorien – wartet weiterhin darauf, in WordPress zu entstehen. Das ist Handarbeit, und sie ist Voraussetzung dafür, dass die Portalstruktur überhaupt entsteht.

75 Beiträge brauchen eigene Fotos. Es gibt eine Liste. Sie ist nicht abgearbeitet. Solange sie es nicht ist, produziere ich Beiträge über Orte, an denen ich war, mit KI-Bildern von Orten, die es nicht gibt.

56 Beiträge sind Zurückstellungskandidaten. Begriffe aus den unteren Stufen meiner Nischenliste – Suchbegriffe, nach denen vermutlich niemand sucht. Sie stehen in der Gesamttabelle. Sie herauszunehmen ist ein Filter, kein Projekt.

Zwei Tabellenspalten werden nicht mehr ausgewertet und müssen trotzdem gefüllt bleiben, weil die Eingabeprüfung sonst den Lauf stumm beendet. Ein Widerspruch, der sich sauber auflösen lässt, sobald ich Tabelle und Workflow gleichzeitig anfasse.

Was ich anders machen würde

Erst lesen, dann importieren

Der teuerste Fehler dieses Projekts war nicht per_page und auch nicht der 20-Minuten-Takt. Es war die Reihenfolge: Ich habe die Vorlage in Betrieb genommen und danach gelesen.

Zwischen Import und erster echter Prüfung liegen bei mir Monate und mindestens 16 Entwürfe. In dieser Zeit sind Beiträge in falschen Kategorien entstanden, mit dem Alt-Text des ersten Bildes an allen Bildern, mit einer Sprachanweisung, die auf ein leeres Feld zeigte, und mit vier parallelen Läufen, die niemand bestellt hatte.

Hätte ich die JSON-Datei am ersten Tag durchgelesen, hätte ich sechs davon in zehn Minuten gefunden. Eine gekaufte Vorlage nimmt dir das Bauen ab, nicht das Verstehen.

Fünf Regeln, die sich bewährt haben

Was ich aus diesen zwei Tagen tatsächlich mitnehme, lässt sich auf fünf Sätze eindampfen:

1. Ein Modell darf vorschlagen, nicht ausführen. Links, Stilüberarbeitungen, Yoast-Werte – alles geht durch eine mechanische Prüfung, die nicht verhandelbar ist. Im Zweifel passiert nichts. „Kein Link“ ist ein zulässiges Ergebnis, „keine Überarbeitung“ auch.

2. Prüf bei jeder Prompt-Regel, ob der Aufruf sie einhalten kann. Sechs isolierte Copywriter können nicht wissen, was die anderen fünf verlinkt haben. Die Regel „jede URL nur einmal“ war deshalb kein strenger Maßstab, sondern ein Wunsch.

3. Ein 200 beweist nur, dass die Anfrage angekommen ist. WordPress verwirft geschützte Meta-Felder stillschweigend. Bei allem, was Zustand verändert, ist Zurücklesen die einzige verlässliche Prüfung.

4. Jede Schleife, die auf Erfolg wartet, braucht eine Obergrenze – und jeder Zeitplan, der Arbeit verteilt, eine Nebenläufigkeitssperre. Der kleine Workflow ist nicht der harmlose.

5. Trenne ändern von melden. Was eindeutig falsch ist, wird repariert. Was Urteilssache ist, wandert in eine Protokollspalte. Sonst liest du entweder alles oder gar nichts.

Und eine sechste, die eigentlich über allen steht: Ändere nicht neun Dinge gleichzeitig an einem System, das läuft. Ich habe das in Teil 7 einmal versucht und wieder zurückgedreht.

Der Messpunkt

Warum ich jetzt nicht weiterplane

Es gibt einen Punkt in solchen Projekten, an dem Planen angenehmer wird als Machen. Man hat Tabellen, Cluster, Architekturskizzen, und jede weitere Stunde Planung fühlt sich produktiv an, weil sie etwas hervorbringt, das man ansehen kann.

Ich habe 1.121 geplante Beiträge, verteilt auf 81 Wellen, geordnet nach Clustern, mit Kategorie-IDs, Recherchestufen und Wortzahlen. Das ist ausreichend geplant. Ehrlicherweise: mehr als ausreichend.

Was fehlt, sind Daten. Und die bekomme ich nicht aus einer weiteren Tabelle, sondern aus veröffentlichten Beiträgen, die ein paar Wochen in der Search Console gestanden haben.

Der nächste Schritt ist deshalb nicht der Ausbau. Es sind: die neuen Kategorien anlegen, einen einzigen Testbeitrag laufen lassen, ihn Zeile für Zeile prüfen – Sprache, Kategorie, Alt-Texte, Schlagwortzahl, Laufzeit, interne Links, Yoast-Spalte, Stil-Spalte – und dann die erste Welle starten.

Was ich messe und wann

Nach den ersten fünfzig Beiträgen sehe ich nach, und zwar an drei Dingen:

In der Ergebnistabelle: Wie oft schlägt „Prüfung nötig“ an? Wie oft wurde eine Stilüberarbeitung verworfen? Wie viele Beiträge haben null interne Links bekommen – also: Wie oft greift die Verwandtschaftsrechnung daneben, und lohnt der Umstieg auf Einbettungen?

In der Nachbearbeitung: Wie lange brauche ich pro Beitrag tatsächlich? Wenn es zwanzig Minuten sind, sind vierzehn Beiträge pro Woche viereinhalb Stunden Redaktionsarbeit. Das ist die Zahl, an der das Projekt scheitern kann – nicht die Modellkosten.

In der Search Console: nicht nach zwei Wochen. Frühestens nach acht. Und die Kennzahl, auf die es ankommt, ist bei null Klicks nicht die Position, sondern die schlichte Frage, ob überhaupt jemand klickt.

Fazit

Zwei Tage, neun Workflow-Fassungen, fünf eigene Code-Nodes, ein Dutzend Befunde – und der ehrliche Stand ist: Die Maschine ist gebaut, geprüft und angeschlossen. Ob sie das Problem löst, das sie lösen soll, weiß ich in einem halben Jahr.

Was ich jetzt schon sagen kann, ist das hier: Die Automatisierung hat mein eigentliches Problem nicht gelöst, sondern verschoben. Mein Problem war nie, dass ich nicht schreiben konnte. Es war, dass ich im Februar aufgehört habe. Ein Workflow, der vierzehn Entwürfe pro Woche produziert, hört nicht auf – aber er verlangt, dass ich vierzehn Entwürfe pro Woche lese. Wenn ich das nicht durchhalte, habe ich in achtzig Wochen 1.121 ungeprüfte Beiträge statt 71 geprüfter.

Deshalb steht die Regel aus Teil 1 unverändert am Ende dieser Serie, und sie ist mir wichtiger als jeder Node darin:

Produktion automatisch. Freigabe manuell.

Der Teil, der Arbeit spart, ist automatisiert. Der Teil, der über die Qualität entscheidet, ist es nicht. Und die Schlachttiere im Wildbret-Beitrag sind der Beleg dafür, dass das keine Koketterie ist.

Ich melde mich wieder, wenn es Zahlen gibt. Auch dann, wenn sie schlecht sind.

Alle Teile der Serie

• Teil 1: Null Klicks in drei Monaten
• Teil 2: 120 Nodes geerbt
• Teil 3: Schlachttiere im Wildbret-Beitrag
• Teil 4: Vier Beiträge in zwei Sekunden
• Teil 5: Interne Verlinkung, neu gebaut
• Teil 6: Yoast über die REST-API
• Teil 7: Stil, Modelle und Kosten
• Teil 8: Bilanz nach zwei Tagen (dieser Beitrag)

◀ Zurück zu Teil 7: Stil, Modelle und Kosten

Wie es weitergeht: Aus derselben Werkstatt stammt die Serie Hands-on-Lab: Social-Media-Automatisierung mit n8n – wie neue und alte Blogbeiträge selbstständig auf Facebook und Instagram landen. Die Zugangsdaten dafür sind ein Thema für sich: Facebook- und Instagram-Token für n8n.