Blogbeiträge mit n8n und KI automatisch erstellen
Ein Blogprozess mit n8n und einem Sprachmodell kann Briefings, Entwürfe und redaktionelle Übergaben verbinden. Der wichtige Punkt ist die Grenze zwischen Vorarbeit und Veröffentlichung: Ein erzeugter Text ist zunächst ein Vorschlag. Quellen, Aussagen, Links, Bilder, Tonalität und der geplante Termin brauchen eine verantwortliche Prüfung.
Mit einem überprüfbaren Briefing beginnen
Legen Sie vor dem ersten Workflow-Lauf ein kurzes Briefing an. Es sollte Thema, Zielgruppe, gewünschte Handlung, Suchintention, Sprache, Umfang, Quellen und Ausschlüsse enthalten. Leitplanken wie belegbare Zahlen, zulässige Aussagen und ein klarer Freigabepunkt gehören ebenfalls ins Briefing. Speichern Sie außerdem eine eindeutige Briefing-ID und den Status „entwurf“.
n8n muss aus dem Briefing erkennen können, ob Pflichtangaben fehlen. Fehlt die Zielgruppe oder ist das Thema mehrdeutig, endet der Lauf mit einem Prüfstatus. Ein leerer Platzhalter darf nicht stillschweigend zu einer Tatsachenbehauptung werden. Diese kleine Eingangskontrolle ist oft wertvoller als ein komplizierter Prompt.
Entwurf und Prüfung trennen
Der erste n8n-Zweig kann aus dem Briefing eine Gliederung und anschließend einen Entwurf erstellen. Das Sprachmodell liefert dabei Textbausteine; es ist keine Quelle. Für jeden Abschnitt sollte die Redaktion festhalten können, welche Quelle die Aussage trägt oder ob es sich um eine ausdrücklich gekennzeichnete Einschätzung handelt.
Bauen Sie danach einen Haltepunkt ein. Der Text wird intern abgelegt und einer Person zur Prüfung vorgelegt. n8n dokumentiert für Gmail die Operation Send and Wait for Approval mit Approve- und Disapprove-Entscheidung: n8n Gmail Message Operations. Für komplexere Freigaben kann ein Workflow warten und mit einem eindeutigen Prüfstatus fortsetzen. Bis zur Freigabe bleibt der Datensatz im Entwurf.
Ein kleiner n8n-Einstieg
Beginnen Sie mit einer kurzen Kette: Briefing-Daten oder manueller Trigger → Pflichtdaten-Filter → KI-Entwurf → Wartezustand für die Redaktion → erneuter Statuscheck → CMS-Draft → Deduplizierung über Briefing-ID und Inhaltsversion. Der Filter stoppt unvollständige Briefings. Der Statuscheck prüft nach der Wartezeit, ob die Freigabe noch zur gleichen Version gehört. Erst danach wird die CMS-Übergabe ausgeführt. Ein solcher Einstieg lässt sich an einem Themenformat prüfen und später um Quellen- oder Kanalzweige erweitern.
SEO als Prüfliste verwenden
SEO sollte hier aus konkreten Kontrollen bestehen: Passt der Titel zur Frage? Beantwortet der Anfang das Versprechen? Sind Überschriften verständlich, Links erreichbar und Begriffe konsistent? Gibt es eine eindeutige Canonical-URL, eine sinnvolle Meta-Beschreibung und eine konsistente Version? Die GSC-Daten können später zeigen, welche Suchanfragen und Seiten tatsächlich Impressionen erhalten. Sie begründen keine Zusage für eine bestimmte Position.
Ein n8n-Lauf kann diese Prüfpunkte sammeln und fehlende Werte markieren. Die Entscheidung über eine fragwürdige Aussage bleibt bei der Redaktion. Bei Quellenkonflikten wechselt der Status auf „redaktionelle Klärung“. Ein kurzer manueller Blick auf Zahlen, Eigennamen und Links gehört zum Ablauf.
CMS als kontrollierte Übergabe
Erst nach der redaktionellen Entscheidung wird der Inhalt an das CMS übergeben. Der n8n-WordPress-Node dokumentiert das Erstellen, Abrufen und Aktualisieren von Beiträgen und Seiten: n8n WordPress node. Übergeben Sie zunächst den Status „draft“, speichern Sie die CMS-ID und verknüpfen Sie sie mit der Briefing-ID. So kann ein zweiter Lauf denselben Beitrag aktualisieren, statt einen Duplikatbeitrag anzulegen.
Die Veröffentlichung bleibt eine eigene Entscheidung. Prüfen Sie vor dem Klick nochmals Slug, Canonical, sichtbare Links, Bildrechte, Autor, Veröffentlichungszeit und die Darstellung auf kleinen Bildschirmen. Das verhindert, dass ein technisch erfolgreicher API-Aufruf mit einer fachlich freigegebenen Veröffentlichung verwechselt wird.
Geplante Termine und externe Kanäle
Ein Redaktionskalender kann nur den gewünschten Zeitpunkt liefern. Der n8n-Google-Calendar-Node beschreibt das Lesen und Bearbeiten von Ereignissen: n8n Google Calendar node. Verwenden Sie den Kalendereintrag als Arbeitsauftrag und prüfen Sie Zeitzone, Status und Verantwortliche, bevor ein Veröffentlichungszweig startet.
Nach der Freigabe können vorbereitete Hinweise für bereits festgelegte Kanäle erzeugt werden. Jeder Kanal braucht seine eigenen Zeichenlimits, Links und Prüfungen. Newsletter-Abonnements, Kaltversand oder ungefragte Social-Media-Posts gehören nicht in diesen Ablauf. Ein Kanal ohne verifizierte Freigabe bleibt aus.
Beispielablauf
Das folgende fiktive Beispiel verwendet ausschließlich Platzhalterdaten. Das Briefing B-104 lautet: „Erkläre kleinen Teams, wie sie eine Quellenprüfung für Blogentwürfe aufbauen. Nutze drei offizielle Quellen und plane den internen Review am Donnerstag.“ n8n erzeugt eine Gliederung, fragt die drei Quellen ab, markiert eine unbelegte Formulierung und legt den Entwurf in einem Prüfkanal ab. Die Redaktion ersetzt die Formulierung, bestätigt die Links und wählt Approve. Danach erstellt der WordPress-Node einen Entwurf mit der CMS-ID DRAFT-104. Ein späterer manueller Schritt veröffentlicht ihn. Der Wert des Beispiels liegt in der nachvollziehbaren Kette, nicht in einem behaupteten Ergebnis.
Fehler, Wiederholungen und Wartezustände
Definieren Sie für jeden Übergang einen Fehlerstatus. Bei einem API-Timeout wechselt der Lauf in einen sichtbaren Fehlerstatus und erzeugt keinen neuen Beitrag. Bei ungültigen Zugangsdaten endet der Lauf und meldet den Fehler. Bei einer abgelehnten Freigabe wird die Version archiviert oder gezielt überarbeitet. Die n8n-Wait-Dokumentation beschreibt Fortsetzungen nach Zeitintervall, Zeitpunkt oder Webhook und weist auf Resume-URL, Authentifizierung und Server-Zeitzone hin. Diese Eigenschaften müssen zum internen Berechtigungsmodell passen.
Vergeben Sie eine Lauf-ID, eine Briefing-ID und eine Inhaltsversion. Prüfen Sie vor einem Wiederanlauf, ob diese Version bereits im CMS liegt. So wird ein Netzfehler nicht zu einem Duplikat und eine verspätete Freigabe nicht zu einer ungeplanten Veröffentlichung.
Rollen und Zugriff
Legen Sie fest, wer ein Briefing ändern, Quellen ergänzen, einen Entwurf ablehnen und die Veröffentlichung auslösen darf. Ein Workflow kann diese Rollen sichtbar machen, aber er ersetzt keine Berechtigungsprüfung im CMS oder beim Versanddienst. Speichern Sie die Person oder Rolle, die eine Entscheidung getroffen hat, zusammen mit Zeit, Inhaltsversion und Begründung. So bleibt nachvollziehbar, warum ein Entwurf zurückgestellt oder veröffentlicht wurde.
Verwenden Sie für Testläufe eine getrennte Zielumgebung und klar markierte Beispieldaten. Ein versehentliches Testen mit einer echten Empfängerliste ist ein Prozessfehler, den ein gutes Prompt nicht verhindert. Entfernen Sie interne Kommentare, persönliche Kontaktdaten und nicht freigegebene Anhänge, bevor Sie einen Text an ein Modell oder ein externes System übertragen.
Versionen und Rücklauf
Ein redaktioneller Workflow braucht einen Rückweg. Wenn eine Quelle nachträglich korrigiert wird, muss die betroffene Inhaltsversion auffindbar und der Beitrag erneut prüfbar sein. Speichern Sie deshalb Briefing-ID, Quellenstand, Modelllauf, Inhaltsversion, CMS-ID und Freigabestatus getrennt. Ein Änderungsantrag erzeugt eine neue Version; er überschreibt nicht lautlos die bereits freigegebene Fassung.
Bei einem Fehler im CMS markiert der Workflow den Übergang als fehlgeschlagen. Die Redaktion öffnet den letzten bekannten Entwurf, behebt die Ursache und holt anschließend eine neue Freigabe ein. Damit bleibt ein Rollback eine bewusste redaktionelle Entscheidung und kein unbemerkter Automatismus.
Messung ohne Versprechen
Messen Sie getrennt, was im Prozess passiert: Zeit bis zum ersten brauchbaren Entwurf, Zahl der redaktionellen Korrekturschleifen, abgelehnte Quellen, Wartezeiten, CMS-Fehler und doppelte Läufe. Für die Website kommen später Impressionen, Klicks, CTR und Suchanfragen aus GSC hinzu. Die Kennzahlen beschreiben den eigenen Verlauf; Ranking, Leads und Umsatz werden separat bewertet.
Starten Sie mit einem einzigen Themenformat und einer freigabeberechtigten Person. Prüfen Sie einige reale Durchläufe, dokumentieren Sie Ausnahmen und entscheiden Sie erst danach, welche Schritte stabil genug für eine weitere Automatisierung sind.