Werkstattbericht Content-Automatisierung – Teil 3 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.
Der Satz, an dem ich hängen geblieben bin, lautete:
„Beim Betäuben sollten Verletzungen und Angst durch ruhiges Zutriebverhalten vermieden werden.“
Er stand in einem Beitrag über Wildbrethygiene. Also über Wild, das erlegt wurde. Es gibt dabei kein Zutreiben. Keine Betäubung. Keinen Transport zum Schlachtort. Kein Tier, das man beruhigen könnte, weil es zu dem Zeitpunkt bereits tot ist.
Der Absatz war sprachlich einwandfrei. Fachlich war er sauber recherchiert. Und er gehörte in ein völlig anderes Sachgebiet.
Dies ist Teil 3 des Werkstattberichts. In Teil 2 ging es um die Fehler in der Verdrahtung des Workflows. Jetzt geht es um die Fehler in dem, was er produziert – und die sind interessanter, weil sie nicht an einem Feld liegen, sondern am Aufbau.
Was aus der Maschine kam
16 Entwürfe, zwei Bauarten
Um überhaupt beurteilen zu können, was schiefgeht, habe ich meine WordPress-Entwürfe exportiert. 16 Stück. Beim Durchsehen zerfielen sie in zwei erkennbar verschiedene Bauarten:
| 13.10. – 02.11. (6 Entwürfe) | 23.11. – 05.12. (5 Entwürfe) | |
|---|---|---|
| Einführung / Fazit / „Über uns“ | fehlt durchgehend | vorhanden |
| Bilder | keine | je drei |
| interne Links | keine | zwei bis sechs |
| Gliederung | mal nur H3, mal nur H2, einmal gar keine Überschrift | H2 + H3, gleichmäßig |
Die zweite Gruppe entspricht exakt dem Aufbau, den der Workflow in seiner jetzigen Fassung erzeugt: Einführung → drei Kapitel mit je zwei Unterkapiteln → Fazit → Handlungsaufforderung → „Über uns“. Die erste Gruppe tut das nicht.
Meine Einschätzung – und ich kennzeichne sie ausdrücklich als solche, weil ich sie nicht beweisen kann: Die Beiträge ab dem 23.11. stammen aus dieser Fassung des Workflows, die vom Oktober aus einer früheren. Die Analyse habe ich deshalb auf alle elf Entwürfe gestützt, die Ursachenzuordnung aber nur dort vorgenommen, wo sie in der vorliegenden Datei tatsächlich nachweisbar war.
Das ist eine Arbeitsweise, die ich empfehlen kann: Erst sortieren, was aus welchem Stand kommt. Sonst suchst du im aktuellen Workflow nach Fehlern, die es dort längst nicht mehr gibt.
Der Beitrag, der mich aufmerksam gemacht hat
Auffällig wurde die Sache am Beitrag über Wildbret-Hygiene vom 05.12.2025. Vier Stellen daraus:
„Auch der Transport zum Schlachtort muss schonend erfolgen.“ „Die Erkenntnisse zur Hoftötung, einer Betäubung in der Nähe des Hofes…“ „Intensive Weidehaltung, die häufigen Kontakt zwischen Tieren und Landwirten umfasst…“ „Beim Betäuben sollten Verletzungen und Angst durch ruhiges Zutriebverhalten vermieden werden.“
Wer jagt, zuckt bei jedem dieser Sätze zusammen. Wer nicht jagt, liest darüber hinweg – sie klingen kompetent, sie sind grammatisch tadellos, und sie enthalten Fachbegriffe. Genau das macht sie gefährlich.
Themendrift: warum plötzlich Nutztiere im Text stehen
Der Prompt, der nur aus zwei Wörtern bestand
Die Ursache steckt an einer Stelle, die man beim Überfliegen des Workflows nicht beachtet. Der Node, der die Unterkapitel recherchiert, bekommt als vollständigen Prompt:
Topic: {{ $json.subchapters }}Mehr nicht. Kein Artikelthema. Keine Zielgruppe. Kein Kapitel. Nur die Überschrift des Unterkapitels, als Suchanfrage an Perplexity gereicht.
Eines dieser Unterkapitel hieß:
„Stressvermeidung als Schlüssel zur Qualität“
Lies den Satz noch einmal, ohne zu wissen, dass es um Wild geht. Er könnte über Sportler handeln, über Mitarbeiterführung, über Weinbau. Was er in der Fachliteratur tatsächlich trifft, ist ein riesiges, gut belegtes Feld: Stress und Fleischqualität bei Nutztieren. PSE-Fleisch, DFD-Fleisch, Zutrieb, Betäubung, Transportdauer.
Perplexity hat also fachlich völlig korrekt geantwortet – zum falschen Sachgebiet. Und der Copywriter hat es brav ausgeschrieben.
Verstärkt wurde das durch eine zweite Anweisung, die in allen drei Research-Prompts stand:
Return the exact research result provided by your research tool.
Do not modify or paraphrase the content.Der Agent durfte gar nicht korrigieren, was er bekam. Er war ausdrücklich zum Durchreichen verpflichtet.
Exkurs: warum „Deeper Research“ das Problem vergrößert
Hier liegt die strukturelle Schwäche der ganzen Konstruktion, und sie ist es wert, verstanden zu werden – denn sie gilt für jede Automatisierung, die Recherche in Häppchen zerlegt.
Die Vorlage hat einen Schalter namens Have Deeper Research. Steht er auf Yes, recherchiert nicht nur ein Agent zum Kapitel, sondern zusätzlich einer je Unterkapitel. Klingt nach mehr Tiefe. Ist es auch – aber der Preis dafür ist:
Je feiner du schneidest, desto mehrdeutiger wird das Stück.
„Wildbrethygiene: Kühlung und Reifung“ ist eine eindeutige Suchanfrage. „Stressvermeidung als Schlüssel zur Qualität“ ist keine. Der Kapiteltitel trägt noch den Kontext, das Unterkapitel nicht mehr. Und weil das Modell die Anfrage ohne Kontext stellt, landet es in dem Sachgebiet, in dem die Formulierung am häufigsten vorkommt – nicht in deinem.
Die Korrektur bestand darin, den Kontext mitzugeben:
Übergeordnetes Artikelthema: {{ Topic }}
Zielgruppe: {{ Target Audience }}
WICHTIG: Recherchiere ausschließlich INNERHALB dieses Artikelthemas. Wenn der unten
genannte Abschnitt für sich genommen mehrdeutig ist, lege ihn immer im Sinne des
Artikelthemas aus. Übertrage keine Erkenntnisse aus benachbarten Sachgebieten, die
auf das Artikelthema nicht zutreffen.
Kapitel: {{ chapter_title }}
Abschnitt (Unterkapitel): {{ subchapters }}Dazu die Perplexity-Suchanfrage selbst umgestellt: nicht mehr nur {{ subchapter }}, sondern {{ Topic }} – Teilaspekt: {{ subchapter }}.
Und jetzt die ehrliche Einschätzung, die dazugehört: Das verringert die Drift deutlich. Es beseitigt sie nicht. Ein Modell, das zu „Stressvermeidung beim Wild“ recherchiert, findet weiterhin Nutztierliteratur – sie ist nun einmal umfangreicher. Für fachlich heikle Gebiete – bei mir Jagd, Waffenrecht, Wildbrethygiene, Erste Hilfe – habe ich deshalb zusätzlich Have Deeper Research auf No gestellt. Dann recherchiert nur der Kapitel-Agent, mit dem vollen Kapiteltitel als Anfrage, und die Angriffsfläche ist erheblich kleiner. Nebenbei halbiert das ungefähr die Kosten pro Beitrag.
Drei weitere Fehler mit derselben Handschrift
Fußnoten, die niemand bestellt hat
Im selben Wildbret-Beitrag standen 17 Marker dieser Art:
„…da Stresshormone wie Adrenalin und Cortisol die Glykogenreserven im Muskel verringern [1][4][7].“
In den zehn anderen Entwürfen: keiner.
Die Ursache ist dieselbe Anweisung wie oben – „Return the exact research result… do not modify or paraphrase“. Perplexity liefert seine Antworten mit genau diesen Quellenmarkern. Der Agent reicht sie weisungsgemäß durch. Und in keinem der vier Copywriter-Prompts stand, dass sie zu entfernen sind.
Warum das nur in einem von elf Beiträgen auftrat, kann ich nicht sagen. Wahrscheinlich haben die Copywriter sie meistens beim Umformulieren verloren. Verlassen kann man sich darauf nicht.
Ein Unterkapitel auf Englisch, und drei tote Links
Im Beitrag „Wanderungen rund um Kelmis“ stand mitten im Text:
Überschrift: „2. Exploring the Extended Paths of the Hohnbachtal Daffodil Bloom„ Fließtext: „In the serene embrace of Kelmis lies the Hohnbachtal, a haven of diverse…“ Ankertext: „Learn more about the unique flora“
Damit war der Verdacht aus Teil 2 keiner mehr: Die Sprachanweisung {{ ... ['Content Language'] }} zeigte auf ein Feld, das Language hieß, löste sich zu einem leeren Wert auf, und in neun Prompts stand „must generate the content entirely in „ „. In den meisten Läufen rettete das deutsche Thema die Sprachwahl. In diesem einen Unterkapitel nicht.
Im Beitrag vom 23.11. wiederum waren alle drei internen Links kaputt:
<a href="\"https://wildnisruf.de/wanderbekleidung-und-ausruestung-im-ueberblick/\"">Die Adresse beginnt mit einem Backslash. Kein Browser folgt dem, und für Google existiert der Link nicht. Ursache: Der Copywriter soll Markdown liefern, gibt aber gelegentlich rohes HTML aus – und zwar mit den maskierten Anführungszeichen, wie sie in der JSON-Antwort stehen. Der Markdown To HTML-Node reicht HTML unverändert durch, also auch die Maskierung.
Und dann war da noch der Beitrag „Effektive Wildregulierung“, in dem alle drei H2-Überschriften identisch lauteten:
„Gesetzliche Grundlagen und Strategien der Wildregulierung: Reh, Hirsch, Schwarzwild im Überblick“
Dreimal. Die wahrscheinliche Ursache ist alte Bekannte aus Teil 2:
chapter_title = {{ $('Wait2').first().json.output.chapter_title }}.first() greift auf das erste je verarbeitete Unterkapitel zu – also auf Kapitel 1, in jedem Durchlauf. Warum es nur in einem von fünf Beiträgen auftrat, kann ich nicht erklären; vermutlich löst n8n .first() je nach Ausführungslauf unterschiedlich auf. Das ist eine begründete Vermutung, kein Beweis. Behoben durch $('Loop Over Chapter').item – und zusätzlich die Schleife von „alle Kapitel auf einmal“ auf batchSize = 1 umgestellt, damit der Bezug eindeutig ist.
Der Bereinigungs-Node
Acht Aufgaben, zwei davon nur melden
Prompts sind Bitten. Code ist eine Zusage. Für alles, was sich mechanisch prüfen lässt, habe ich deshalb einen Code-Node zwischen die Artikelmontage und die Markdown-Umwandlung gehängt. Er tut acht Dinge:
- entfernt Quellenmarker
[1],[1][4][7]– Markdown-Links bleiben unangetastet - repariert beschädigte
href– undsrc-Attribute (\") - entfernt übrig gebliebene Codefences
- löst Mehrfachverlinkungen auf dieselbe URL auf – der erste Link bleibt, die weiteren werden Text
- entfernt nackte URLs und „Quelle: https://…“-Zeilen
- meldet nichtssagende Ankertexte („hier“, „mehr“)
- meldet mutmaßlich englische Zeilen
- normalisiert Überschriften und Leerzeilen
Die Unterscheidung zwischen ändern und melden ist bewusst. Was eindeutig falsch ist, wird repariert. Was Urteilssache ist, landet in einem Textfeld namens cleanup_report, das in die Ergebnistabelle geschrieben wird. Dann sehe ich beim Durchsehen der Entwürfe auf einen Blick, welcher Beitrag Aufmerksamkeit braucht – statt alle 1.121 gleich gründlich lesen zu müssen.
Getestet habe ich ihn an den echten Entwürfen, nicht an konstruierten Beispielen:
| Beitrag | Ergebnis |
|---|---|
| Wildbret-Hygiene | 17 Fußnotenmarker entfernt |
| Dreiländereck | 5 beschädigte Link-Attribute repariert, 2 schwache Ankertexte gemeldet |
| Kelmis | 1 Mehrfachverlinkung aufgelöst, 5 englische Zeilen gemeldet, 1 schwacher Ankertext |
| Wildregulierung | 4 Mehrfachverlinkungen aufgelöst |
| Jagdpraktiken | nichts zu bereinigen |
Die letzte Zeile ist mir fast die liebste. Ein Prüfwerkzeug, das immer etwas findet, ist kaputt.
Was er nicht kann – und was daraus folgt
Und jetzt der Teil, den ich nicht wegmoderieren will.
Der Bereinigungs-Node hätte die Schlachttier-Passage nicht gefunden. Kein Prompt und kein Code-Node hätte sie gefunden. Sie war sprachlich einwandfrei, gut belegt und vollständig falsch. Es gibt kein Muster, gegen das man sie hätte prüfen können.
Gefunden habe ich sie, weil ich Jäger bin.
Daraus folgt eine Konsequenz, die man in Automatisierungsprojekten gern überliest: Eine Maschine kann prüfen, ob ein Satz die Form hat, die du erwartest. Sie kann nicht prüfen, ob er stimmt. Alles, was ich in dieser Serie an Prüfungen einbaue – Bereinigung, Linkkontrolle, Stilvergleich, Yoast-Gegenprüfung – prüft Form. Die Sache prüft weiterhin ein Mensch.
Was möglich wäre und was ich mir für später vorgenommen habe: ein zusätzlicher Modellaufruf vor der WordPress-Ausgabe, der den fertigen Text gegen eine kurze Liste von Sachverhalten prüft, die im jeweiligen Gebiet nicht vorkommen dürfen. Für Jagd zum Beispiel: kein Transport zum Schlachtort, keine Betäubung, keine Weidehaltung, kein Zutrieb, keine Rede von „Nutztieren“. Diese Ausschlusslisten muss allerdings jemand schreiben, der das Gebiet kennt – erfinden lassen kann man sie sich nicht.
Fazit
Zwei kleinere Befunde noch, der Vollständigkeit halber: Die Handlungsaufforderung am Beitragsende fehlte in drei von fünf Beiträgen, weil sie nicht eingesetzt, sondern durch das Sprachmodell geschickt wurde – ein HTML-Block überlebt diese Runde nicht immer. Und zwei Entwürfe hatten überhaupt keinen Titel: Fehlt das Feld, legt der WordPress-Node einen titellosen Beitrag an, und der Ablauf läuft ohne Fehlermeldung weiter.
Wenn ich die Befunde dieses Teils auf einen Nenner bringen soll, dann diesen: Fast jeder Fehler in den Texten war ein Fehler in der Verdrahtung, nicht im Modell. Die Schlachttiere kamen von einem Prompt ohne Themenkontext. Die eckigen Klammern von einer Anweisung, nichts zu verändern. Die englischen Sätze von einem Feldnamen. Die dreifache Überschrift von einem .first().
Ein besseres Sprachmodell hätte keinen einzigen dieser Fehler verhindert. Das ist eine unbequeme Erkenntnis, wenn man gerade dabei ist, Modelle zu vergleichen – und ich komme in Teil 7 darauf zurück, wenn es genau darum geht.
Im nächsten Teil geht es um den Moment, in dem ich in die Zeitstempel meiner eigenen Entwürfe geschaut habe und dort vier Beiträge fand, die innerhalb von zwei Sekunden entstanden sind.
Alle Teile der Serie
- Teil 1: Null Klicks in drei Monaten
- Teil 2: 120 Nodes geerbt
- Teil 3: Schlachttiere im Wildbret-Beitrag (dieser 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
◀ Zurück zu Teil 2: 120 Nodes geerbt | Weiter zu Teil 4: Vier Beiträge in zwei Sekunden ▶
Schreibe einen Kommentar