Automatisierung

WordPress, Divi & n8n – Seiten per Freigabe-Mail veröffentlichen

Vereinfacht das Veröffentlichen neuer Seiten ohne CMS-Login und ohne Flaschenhals im Freigabeprozess. Ein Python-Script synchronisiert lokale HTML-Dateien automatisch mit WordPress/Divi, n8n ergänzt die Freigabe komplett per E-Mail – übertragbar auf jedes Unternehmen mit Freigabeprozessen.

Juni 2026 · 7 Min Lesezeit · WordPress Divi 5 n8n

Projekt auf einen Blick

🎯

Ziel

Seiten ohne CMS-Login veröffentlichen, mit klarem Freigabeprozess.

👥

Zielgruppe

Eigene Homepage-Pflege, übertragbar auf Redaktionsteams in Unternehmen.

🛠️

Technologien

Python, WordPress REST API, n8n, IMAP.

✅

Status

Live, im Alltag produktiv im Einsatz.

📦

Umfang

1 Sync-Script, 3 Nutzungsszenarien, ~2 Sekunden Sync-Zeit.

Die Ausgangslage

Meine Homepage läuft auf WordPress mit Divi 5 – aber der Visual Builder war für die tägliche Pflege nicht die richtige Arbeitsumgebung: Browser-Login, Ladezeiten, kein gewohnter lokaler Editor.

Dasselbe Problem gibt es in vielen Unternehmen, nur größer: Mehrere Personen schreiben Inhalte, aber nicht jede Person soll direkten CMS-Zugriff bekommen – trotzdem soll eine Freigabe stattfinden, bevor eine Seite live geht.

Die Herausforderung

Lokale HTML-Dateien und WordPress mussten zuverlässig in Sync bleiben, ohne dass jemand Inhalte manuell kopiert – und ohne dass eine falsche Datei versehentlich die falsche Seite überschreibt.

Zusätzlich sollte die Freigabe nicht über ein Extra-Tool laufen, sondern über einen Kanal, den ohnehin jeder täglich verwendet: E-Mail.

Die Lösung

Ein Python-Script beobachtet den lokalen HTML-Ordner, ordnet Dateien per mapping.json der passenden WordPress-Seite zu und aktualisiert sie per REST API. n8n übernimmt die Freigabe-Kette: Es überwacht das Postfach per IMAP und legt eine Datei erst nach bestätigter Freigabe-Antwort im Sync-Ordner ab.

Die Umsetzung

Sync-Mechanik

Drei Komponenten arbeiten zusammen: der lokale html/-Ordner als Quelle, mapping.json als Zuordnungstabelle und wp_sync.py als stilles Bindeglied zu WordPress. Kein CMS-Login, kein manuelles Copy-Paste, keine Verzögerung zwischen fertigem Entwurf und live Seite.

Schritt 1

HTML-Datei im Ordner ablegen – manuell gespeichert, per n8n abgelegt oder per Script übergeben.

Schritt 2

wp_sync.py erkennt die Änderung – im Watch-Modus innerhalb von ~2 Sekunden, alternativ per direktem Aufruf oder Webhook.

Schritt 3

mapping.json liefert die Seiten-ID – das Script schlägt nach, welche WordPress-Seite zu dieser HTML-Datei gehört.

Schritt 4

REST API aktualisiert das Divi Code-Modul – PATCH-Request mit dem neuen HTML-Inhalt, Seite wird auf publish gesetzt.

Die Zuordnungsdatei mapping.json sieht so aus:

{
  "detail-divi-sync.html":    1234,
  "n8n-artikel-divi_1.html":   567,
  "garten-artikel.html":       890
}

Szenario 1 – Freigabe per Mail, Seite geht live

Ein Angestellter schreibt einen Artikel und schickt die fertige Datei per E-Mail an die zuständige Person. Die liest, antwortet mit einer Freigabe. n8n überwacht das Postfach per IMAP, erkennt die Freigabe-Antwort und legt die Datei automatisch im richtigen Ordner ab. wp_sync.py erkennt die neue Datei und publiziert sie auf WordPress – ohne dass jemand einloggen muss.

Ablauf im Überblick

Artikel schreiben → per Mail einreichen → Freigabe per Antwort-Mail → n8n legt Datei ab → wp_sync.py synct → Seite live. Die gesamte Kette läuft automatisch, sobald die Freigabe-Mail eingeht.

Szenario 2 – Überarbeitete Version einreichen

Wenn eine Seite aktualisiert werden soll, schickt der Angestellter die überarbeitete Datei erneut per Mail. n8n erkennt anhand des Dateinamens, dass es sich um eine bestehende Seite handelt, ersetzt die Datei im Ordner und der Sync-Prozess läuft durch – der Seiteninhalt auf WordPress ist innerhalb von Sekunden aktuell.

Tipp

Der Dateiname der Datei muss mit dem Eintrag in mapping.json übereinstimmen, damit das Script die richtige WordPress-Seite findet. Neue Seiten werden einmalig in der Mapping-Datei eingetragen.

Szenario 3 – Script direkt oder per Webhook aufrufen

Der Watch-Modus eignet sich für dauerhaften Betrieb. Für gezielte Einzelupdates lässt sich das Script auch direkt aufrufen – z.B. aus n8n heraus per Execute Command Node, oder von Hand im Terminal:

python3 scripts/wp_sync.py detail-divi-sync.html

Das macht den Workflow flexibel: Watch-Modus für aktive Arbeitsphasen, Direktaufruf für kontrollierte Einzelpublizierungen, Webhook-Trigger für die Anbindung an externe Systeme.

Ergebnis & Mehrwert

Im eigenen Alltag bedeutet das: Sync innerhalb von rund 2 Sekunden, kein CMS-Login, kein manuelles Copy-Paste zwischen Editor und WordPress. Dieses Prinzip lässt sich direkt auf Unternehmenswebsites übertragen. Überall dort, wo Inhalte von verschiedenen Personen gepflegt werden – Stellenanzeigen, Produktseiten, Landingpages – ersetzt dieser Workflow den manuellen CMS-Eingriff durch einen klar geregelten Freigabeprozess.

📝

Schreiben ohne CMS-Wissen

Angestellte schreiben in ihrem gewohnten Tool. Weder WordPress-Konto noch Einarbeitung nötig.

✅

Freigabe bleibt beim Chef

Nichts geht live ohne Genehmigung. Die Antwort-Mail ist der Auslöser – kein Extra-Tool, keine Plattform.

📋

Nachvollziehbarer Prozess

Jede Veröffentlichung ist einer E-Mail zugeordnet – protokollierbar, rückgängig machbar, auditierbar.

⚙️

Skalierbar auf viele Seiten

Neue Seiten brauchen nur einen Eintrag in mapping.json – der Rest läuft automatisch durch denselben Prozess.

Fazit

Content-Freigabe per Mail – Veröffentlichung automatisch.

Wer einen klaren Freigabeprozess hat, aber keinen technischen Flaschenhals will, bekommt mit diesem Workflow genau das: Menschen arbeiten wie gewohnt, die Technik im Hintergrund übernimmt den Rest.

Erkenntnisse

Eine Erkenntnis aus diesem Projekt: Der Freigabeprozess war der eigentliche Kern, nicht die Synchronisierung selbst. Das Sync-Script war technisch schnell gelöst – die eigentliche Arbeit steckte darin, den Freigabeprozess so zu gestalten, dass niemand ein neues Tool lernen muss.

Ich habe mich bewusst für IMAP-Überwachung statt für ein dediziertes Freigabe-Tool entschieden: E-Mail ist ein Kanal, den ohnehin jeder im Unternehmen täglich verwendet – jede zusätzliche Software-Hürde hätte die Akzeptanz gesenkt.

Der Watch-Modus mit rund 2 Sekunden Reaktionszeit hat sich im Alltag als der richtige Kompromiss erwiesen: schnell genug, um sich wie „live" anzufühlen, aber unabhängig von einem Webhook-Endpunkt, der ständig erreichbar sein müsste. Der Direktaufruf per Terminal bleibt trotzdem als Fallback für kontrollierte Einzelfälle bestehen.