Die Content Maschine
Ich wollte wissen: Kann eine Pipeline aus einem einzelnen Keyword einen fertigen Blogartikel produzieren? Recherche, Text, Bilder, Meta-Daten, WordPress-Upload. Gebaut mit n8n und fünf KI-Agenten.
Ein Keyword rein, ein Content-Draft raus. Kein Kopieren zwischen Tools, kein Prompt-Hopping. Die Pipeline läuft von der Recherche bis zur Veröffentlichung durch.
Das Problem
Einen brauchbaren SEO-Artikel zu schreiben dauert Stunden. Keyword-Recherche, Wettbewerbsanalyse, Gliederung, Schreiben, Formatieren, Bilder, Meta-Daten. Sieben Schritte, die alle Kontext voneinander brauchen.
Mein erster Versuch war ein einziger großer Automation-Workflow, der mit der Zeit immer komplizierter wurde.
Die Idee: ein umfassendes Dokument erzeugen und davon einzelne Content Pieces ableiten. Das Ergebnis war zu ungerichtet, und ich bin ständig an Context-Fenster-Grenzen gestoßen. Außerdem Token-Verschwendung aus der Hölle.
Aber auch mit einem einzelnen ChatGPT-Prompt über ein Custom-GPT ist es nicht getan. „Schreib mir einen Artikel über X“. Was rauskommt, klingt vielleicht passabel und war aber inhaltlich dünn. Ein Prompt kann nicht gleichzeitig recherchieren, analysieren und schreiben. Verschiedene Aufgaben brauchen verschiedene Spezialisten.
Der Ansatz
Die Content Maschine zerlegt den Prozess in Module. Jedes hat eine Aufgabe und übergibt sein Ergebnis an das nächste. Der Recherche-Agent weiß nichts über Textformatierung. Der Writer weiß nichts über Keyword-Analyse. Jeder bekommt genau den Kontext, den er für seine Aufgabe braucht.
Technisch war die Modularität das Kniffligste. Ich wollte einen einzigen Flow, der je nach Eingabe verschiedene Content-Formate ausgibt. Die Lösung: eine Code Node vor jedem Agenten, die den Prompt ausliest, dynamische Felder wie das Content-Format reinmerged und alles als JSON verpackt. Jeder Agent bekommt nur diesen JSON-Prompt, keinen weiteren Text.
Die KI-Agenten
Fünf Agenten, fünf Aufgaben. Keiner versucht alles zu können.
Der Strategist
Analysiert das Keyword und den Wettbewerb. Was rankt schon? Wo gibt es inhaltliche Lücken? Sein Output ist ein Recherche-Dokument mit konkreten Daten, auf dem der Rest der Pipeline aufbaut.
Der Architect
Baut aus der Recherche ein Briefing und eine Gliederung. Welche Abschnitte braucht der Artikel, wie tief geht jeder, welche Argumente tragen. Das Skelett entsteht hier. Der Writer füllt es dann.
Der Writer
Schreibt den Text auf Basis von Gliederung und Briefing. Er kennt die Vorgaben zu Tonalität und Schwerpunkten, hat Zugriff auf eine Datenbank bestehender Inhalte und die Sitemap der Website. Kann also intern verlinken und vermeidet inhaltliche Dopplungen.
Die Wahl des richtigen LLMs hat hier viel ausgemacht. Für die Schreibarbeit braucht es große Modelle wie Gemini 3.1 Pro, die den massiven Input verarbeiten können. Für Sortieren oder Fettmarkierung reichen kleinere Modelle. Spart Zeit und Kosten.
Der Auditor
Prüft den Text gegen das Briefing. Stimmt die Gliederung? Fehlen Punkte? Erst wenn der Auditor zufrieden ist, geht der Artikel weiter.
Der UX Writer
Kümmert sich um Lesbarkeit. Zwischenüberschriften, kürzere Absätze, Aufzählungen wo sinnvoll. Damit der Artikel am Handy genauso gut funktioniert wie am Desktop.
Strategic Infusion
Was die Pipeline von einem normalen KI-Workflow unterscheidet: Jeder Agent bekommt Leitplanken. Vorgaben, die aus meiner Positionierung und meinen inhaltlichen Zielen kommen. Die Pipeline produziert deshalb Artikel, die zu meiner Strategie passen, statt generischen SEO-Text.
Automatische Bildgenerierung
Nach dem Text kommen die Bilder. Ein separater Flow generiert passende Bilder für den Artikel. Jedes Bild hat eine ID, die als Tabellenplatzhalter im Text steht.
Das Zuordnungsproblem war knifflig: Nach einem Loop muss der Flow noch wissen, welcher ALT-Text, welche Beschreibung und welcher Dateiname zu welchem Bild gehört. Die Lösung waren eindeutige IDs in den Platzhaltern, die der Flow nach der Generierung wieder matcht. Am Ende sind die Bilder fertig eingesetzt, inklusive ALT-Texte und WebP-Konvertierung.
Was ich gelernt habe
Ein unterschätztes Problem: Wo speichert man die ganzen Daten? Am Anfang hatte ich alles in Google Sheets. Die API war zu langsam, und das Ordnen und Pflegen der Sheets war mühsam. Seit ich run_ids, Prompts, Identities und alle Folder-IDs in n8ns Data Tables speichere, läuft es deutlich besser. Dieses Feature hat mir extrem geholfen.
Genauso wichtig: Evals aufsetzen. Wie lange dauert ein Run? Wie gut schaffen es verschiedene LLMs, den SEO-Score zu treffen? Werden alle Aufgaben erledigt, also Keywords eingefügt, Schreibstil eingehalten, keine Bildfehler? Ohne diese Messungen optimiert man im Blindflug.
Und Error-Flows. Bei so großen Workflows will man nicht ewig auf ein Ergebnis warten, das nie kommt. Wenn ein Agent hängt oder eine API nicht antwortet, muss das sofort auffallen.
Das Ergebnis
Was in WordPress landet:
- Recherchierter Fachartikel mit Gliederung
- Meta-Daten (Title, Description, Slug)
- Featured Image
- Formatierung mit Zwischenüberschriften und Listen
- Als Draft gespeichert. Ich gebe die finale Freigabe.
Würde ich es wieder in n8n machen? Ja. Aber vieles würde ich heute auslagern, z.B. direkt über Agentic Tools wie Claude Code starten und dann über n8n-Prozesse laufen lassen. Die Anbindungen über APIs sind in n8n einfach sehr praktisch, und mit MCPs lässt sich das Ganze noch besser verbinden.
Die Pipeline übernimmt den zeitintensiven Teil: Recherche, Ersttext, Bilder, Formatierung. Ich mache das, was sich nicht automatisieren lässt: lesen, entscheiden, verbessern, freigeben.
Fragen zur Content Maschine?
Ich teile meine Erfahrungen mit KI-Workflows offen. Wenn dich das Thema interessiert, lass uns auf LinkedIn connecten.