SEO-Content automatisieren mit fünf KI-Agenten

Kann KI wirklich produktionsreife SEO-Texte liefern?

Ja, aber nicht aus einem einzigen Prompt und nicht aus einem einzigen Workflow, der alles in einem Durchlauf erledigen soll. KI kann recherchieren, entwerfen, prüfen und formatieren, bis am Ende ein brauchbarer SEO-Text steht. Das funktioniert aber nur, wenn man die Arbeit auf spezialisierte Schritte aufteilt, statt einem Modell die ganze Aufgabe auf einmal in den Kopf zu legen.

Ich weiß das, weil ich genau diese Pipeline gebaut habe. Zwei Alleingänge sind vorher gescheitert, bevor ich bei einem Fünf-Agenten-Setup gelandet bin, das heute fertige Entwürfe ausliefert.

Diese kurze Antwort überspringt den Teil, der eigentlich zählt: wie man die Arbeit aufteilt und warum diese Aufteilung wichtiger ist als die Modellwahl. Hier ist, was ich beim Bau einer funktionierenden Content-Pipeline gelernt habe, samt beider gescheiterter erster Versuche, die beide auf ihre eigene Art lehrreich waren.

Warum ein einzelner Prompt nicht reicht

Ein brauchbarer SEO-Artikel braucht ungefähr sieben manuelle Schritte, von der Keyword-Recherche bis zu den Metadaten. Dazwischen liegen Konkurrenzanalyse und Gliederung. Dann kommen Entwurf, Formatierung und Bilder. Zwei Abkürzungen sehen dabei verlockend aus, und beide scheitern auf ihre eigene Art.

Die erste Abkürzung ist ein überladener n8n-Workflow, der alles in einem einzigen Prompt an ein Modell schickt. Recherche, Gliederung, Entwurf und Formatierung laufen dabei in einem einzigen Aufruf zusammen. Das hat die Kontextgrenzen gesprengt und Tokens für Aufgaben verbrannt, die gar kein Spitzenmodell gebraucht hätten. Ein Modell, das Suchintention, Struktur und Text gleichzeitig im Kopf behalten soll, erzeugt Drift, und Drift ist teuer, wenn er innerhalb eines LLM-Aufrufs passiert, den man ohnehin schon bezahlt.

Die zweite Abkürzung ist der Ein-Prompt-Ansatz in ChatGPT: Keyword rein, Artikel raus. Beim ersten Lesen wirkte das Ergebnis brauchbar, beim zweiten las es sich flach. Der Text zeigt keinen Blickwinkel, der über das hinausgeht, was die Top-Ergebnisse ohnehin schon sagen. Ein Briefing hätte eine konkrete Behauptung gesetzt, aber es gab keins, nur ein Keyword.

Keiner der beiden Wege trägt für Produktions-Content. Gibt man einem Modell zu viel auf einmal, sinkt die Qualität lange bevor eine Kontextgrenze erreicht ist. Gibt man ihm zu wenig Struktur, hat der Output kein Rückgrat, an dem er sich selbst prüfen kann. Beide Abkürzungen sparen am Anfang Zeit und kosten sie später doppelt zurück, in Korrekturschleifen, die sich mit den fünf Agenten von Anfang an vermeiden lassen.

Fünf Agenten, je eine Aufgabe

Die Lösung: fünf spezialisierte Agenten mit je einer Verantwortung, hintereinandergeschaltet in n8n. Jede Übergabe zwischen ihnen ist ein JSON-Dokument, das der nächste Agent liest, und keiner weiß mehr, als er für seine eine Aufgabe braucht. Das Schaubild unten zeigt die Reihenfolge: ein Keyword geht rein, zwischen jeder Station sitzt ein Code-Node, der die Übergabe in sauberes JSON packt, und am Ende steht ein fertiger Entwurf.

Stratege

Ich füttere ihn mit einem Keyword, und er liefert ein Rechercheergebnis zurück, keinen Entwurf. Dabei arbeitet er die Suchintention heraus, prüft, was schon rankt, und markiert genau die Lücke, die diesen Ergebnissen fehlt. Diese Lücke wird zum Rückgrat für alles, was danach kommt, vom Briefing des Architekten über den Entwurf des Autors bis zum letzten Feinschliff des UX-Texters.

Architekt

Dieser Agent macht aus der Recherche ein Skelett, das der Autor nicht überspringen darf. Er legt die Reihenfolge der H2-Abschnitte fest und bestimmt, was jeder Block behaupten muss. Er zeigt außerdem, welche Aussage wohin gehört und wo ein Link seinen Platz wirklich verdient. Für den Autor ist dieses Briefing bindend, kein loser Vorschlag, von dem er nach eigenem Ermessen abweichen kann.

Autor

Streng nach diesem Briefing macht er aus Struktur Sätze. Ich gebe ihm Zugriff auf die echte Sitemap, damit ein Link auf einer echten Seite landet und nicht auf einer, die sich das Modell nur ausgedacht hat. Was zurückkommt, ist bewusst unformatierter Text. Das Formatieren übernimmt der nächste Agent.

Auditor

Bevor irgendetwas weitergeht, prüft dieser Schritt den Entwurf Zeile für Zeile gegen das Briefing. Er kontrolliert, ob jede geforderte Aussage standhält und ob sich jede Zahl und jede Behauptung wirklich belegen lässt. Außerdem prüft er, ob der Text den Blickwinkel behalten hat, den der Stratege gesetzt hat. Was nicht passt, geht einmal zurück zum Autor.

UX-Texter

Er ist die letzte Station, bevor ich den Text überhaupt zu Gesicht bekomme, der letzte Filter vor meinen Augen. Er bricht lange Absätze auf, schärft Zwischenüberschriften und tauscht Fließtext gegen eine Liste, wo der Lesefluss zäh wird. Gebaut ist das für jemanden, der auf dem Handy liest, nicht für einen durchgehenden Lesedurchgang am Schreibtisch.

Keiner der fünf macht mehr als eine Sache, und genau deshalb lässt sich ein schlechter Output leicht zurückverfolgen. Man weiß, welcher Schritt das Problem verursacht hat, statt hinterher einen einzigen Riesenprompt zu entwirren.

Das richtige Modell pro Agent wählen

Nicht jeder Schritt braucht dasselbe Modell, und für strukturierte JSON-Arbeit Spitzenpreise zu zahlen, bringt nichts. Stratege und Autor brauchen das stärkste verfügbare Reasoning; aktuell setze ich dafür eher auf Gemini bei der recherchelastigen Arbeit und auf Claude beim Text. Architekt und Auditor arbeiten mit strukturiertem JSON, dafür reicht ein kleineres, schnelleres Modell locker.

Allein diese Aufteilung hat die Kosten auf etwa ein Drittel gedrückt, verglichen mit dem, was der teuerste Modell überall gekostet hätte. Die Qualität der fertigen Texte hat darunter sichtbar nicht gelitten, jedenfalls nicht in dem, was am Ende beim Leser ankommt.

Bei der Modellmischung zählt, wo das teure Reasoning wirklich gebraucht wird. Genau zwei Schritte sind der Engpass, Stratege und Autor, und genau dort lohnt sich das teuerste Modell. Meinen Vergleich zwischen Sonnet und Opus hab ich genau für diese Modellentscheidung geschrieben, Schritt für Schritt.

Guardrails als Input, nicht als Nachbearbeitung

Jeder Agent bekommt Positionierung und Content-Guidelines als Teil seines System-Prompts, nicht als nachträgliche Korrekturrunde. Die Stimme wird einmal in den Guidelines festgelegt, und jeder Agent liest sie, bevor er zu arbeiten anfängt. Der Autor bekommt hinterher keine Erinnerung, wie er klingen soll. Er weiß es schon vorher, und das macht eine Korrekturrunde überflüssig, die sonst am Ende der Kette hängen würde.

Diese eine Entscheidung hält die Pipeline modular, weil sich jeder Agent austauschen lässt, ohne dass die anderen vier es merken. Lässt man sie weg, wird die naheliegende Lösung ein „Voice-Fixer“-Agent am Ende. Der repariert den Ton, nachdem der Schaden schon im Entwurf steckt, statt ihn von vornherein zu verhindern. Wie ich den Basis-Guide gebaut habe, den jeder Agent tatsächlich lesen soll, steht ausführlicher in Brand Voice entwickeln.

Wo es kippt, und was ich beim nächsten Mal anders mache

Keine Pipeline dieser Größe läuft beim ersten Versuch sauber. Drei Dinge würde ich früher reparieren, wenn ich das noch mal von vorne machen würde, und zwar genau in der Reihenfolge, in der ich sie hier beschreibe.

Google Sheets als Zwischenspeicher zwischen den Agenten hat parallele Läufe nicht ausgehalten. Zeilen sind kollidiert, Updates gingen mitten im Schreiben verloren. Ich hab den Speicher auf n8n Data Tables umgestellt, und das Zuverlässigkeitsproblem war weg. Wer eine mehrstufige Pipeline baut, sollte die Tabellen-Zwischenlösung ganz überspringen und gleich mit einem richtigen Datenspeicher anfangen, auch für die erste Version, selbst wenn das am Anfang nach unnötigem Aufwand aussieht.

Ich hab die Auswertungsmetriken am Anfang unterschätzt, also Laufzeit pro Durchlauf, Token-Kosten und Fertigstellungsquote je Agent. Ohne diese Zahlen driftet die Pipeline still vor sich hin. Niemand merkt es, bis der Output schlecht genug ist, um es mit bloßem Auge zu sehen. Das gehört an Tag eins eingerichtet, nicht erst nach der ersten Qualitätsbeschwerde, wenn schon niemand mehr genau sagen kann, wo im Prozess es schiefgelaufen ist.

Fehlerbehandlung muss konkret sein. „Agent hängt seit über 60 Sekunden“ und „API hat einen 429er zurückgegeben“ sind zwei verschiedene Fehler mit zwei verschiedenen Lösungen. Ein pauschaler Retry verschleiert den ersten und verschlimmert den zweiten, weil ein Retry direkt ins Rate Limit hinein nur noch mehr von demselben Limit verbrennt. Mein Workflow-Überblick für n8n-Einsteiger behandelt dieselbe Lektion in kleinerem Maßstab, lesenswert, bevor man sich an etwas in dieser Größenordnung wagt.

Der Beweis: was tatsächlich in Produktion läuft

Ich nenne diese Pipeline Content Machine. Der Bau hat rund sechs Wochen gedauert, als Ein-Personen-Projekt auf n8n, GPT, Claude und Gemini. Ich hab die Aufgaben auf die fünf Agenten verteilt, wie oben beschrieben, und seitdem läuft die Pipeline durchgehend in Produktion.

Ein Keyword geht rein. Ein recherchierter, geschriebener, formatierter und bebilderter Artikel kommt als WordPress-Entwurf raus.

Die Bildgenerierung läuft als eigener paralleler Strang, unabhängig vom Text-Teil der Pipeline. Der Autor markiert Platzhalter-IDs im Entwurf, ein Bildgenerator gleicht sie mit dem Briefing ab, und der Alt-Text entsteht gleich mit jedem Bild. Meine Aufgabe bei jedem Durchlauf ist es, den fertigen Entwurf zu lesen und freizugeben oder zurückzuschicken. Alles davor läuft von allein, ohne dass ich eingreifen muss.

Das ist auch die ehrliche Grenze des Setups im Moment. n8n ist für diese Aufgabe die richtige Orchestrierungsebene. Meinen Vergleich mit Make hab ich genau deshalb geschrieben.

Recherche und Audit würden trotzdem von einem echten Dateibaum profitieren, von etwas, das näher an einer agentischen Coding-Umgebung liegt als an einer Workflow-Canvas. Wie dieser Wechsel auf der Coding-Seite statt beim Content aussieht, zeigt am ehesten mein WordPress-Theme-Bau mit Claude Code.

Bin neugierig, wo bei dir im Content-Prozess der Engpass sitzt, und ob eine ähnliche Aufteilung auf mehrere Schritte dort auch helfen würde. Schreib mir auf LinkedIn.