14. August 2026
Blogpost-Bewertungen mit n8n auswerten: zwei Workflows, ein Regelkreis
Unter jedem Artikel in meinem Blog steht eine Bewertung mit einem Klick. Was danach passiert, übernehmen zwei n8n-Workflows: einer nimmt das Feedback an und räumt es auf, einer verdichtet es und schreibt das Ergebnis zurück nach WordPress.
Ausgangslage
Unter meinen Beiträgen auf hobbyblogging.de steht ein Formular mit fünf Stufen von „Sehr schlecht" bis „Sehr gut", dazu ein optionales Textfeld. Die Abgabe ist anonym, es gibt keine Anmeldung und keinen Login.
Ohne Automatisierung wäre das ein Datenfriedhof: Rückmeldungen landen irgendwo und niemand rechnet sie zusammen. Ich wollte drei Dinge – Bewertungen zentral sammeln, sie pro Beitrag verdichten, und das Ergebnis im Beitrag selbst sichtbar machen. Dazu kam ein Problem, das ich beim Bauen nicht auf dem Zettel hatte: ein offenes Formular zieht Spam an.
Es geht mir dabei nicht nur um ein Kontrollinstrument für mich. Die Bewertungen schaffen im Blog auch Transparenz nach außen: Besucher sehen direkt, welche Beiträge ankommen, und ich sehe, wo ich nachschärfen muss. Gerade neue Leser finden so schnell die Artikel, die nicht nur ich für gelungen halte, sondern auch die, die anderen tatsächlich geholfen haben.
Das ist für mich der Unterschied zwischen einem Blog, der Inhalte ablegt, und einem, der als Informationsmedium taugt. Ich schreibe nicht nur für mich, sondern um anderen ein Thema näherzubringen – und dann muss auch sichtbar sein, was dabei funktioniert.
Herausgekommen sind zwei getrennte Workflows. Der erste läuft dauerhaft und nimmt einzelne Bewertungen an. Der zweite rechnet aus allen gesammelten Bewertungen die Durchschnitte und schreibt sie zurück. Die Trennung ist Absicht: Annahme muss sofort und zuverlässig passieren, Auswertung darf warten.
Der zweite Grund ist Last. Würde jede einzelne Bewertung sofort die komplette Kette auslösen, würde bei jedem Klick neu über alle Beiträge gerechnet und mein Blog-Server doppelt angefragt – einmal für die Kategorie und einmal für das Zurückschreiben. Deshalb passiert es in zwei Schritten. Rückblickend ist das vor allem wegen Spam wichtig: In einer Welle aus automatisierten Einsendungen hätte jede einzelne davon den gesamten Prozess angestoßen.
Workflow 1: Feedback annehmen
Auslöser ist ein Webhook, der eine POST-Anfrage des Formulars entgegennimmt. Mitgeschickt werden Beitragstitel, Post-ID, die gewählte Bewertung und der optionale Text. Danach durchläuft jede Einsendung sechs Stufen, bevor sie in der Tabelle landet.
Vorfilter: offensichtlicher Müll fliegt sofort raus
Die erste Prüfung ist billig und wirkt sofort: Die Post-ID muss eine reine Zahl sein. Was dort ankam, war nämlich unter anderem 21060'" – ein halbherziger Versuch, über das Formular etwas einzuschleusen. Wer keine gültige Beitrags-ID mitschickt, will keine Bewertung abgeben. Dazu kommt eine bekannte Spam-Phrase, die bei mir im Dauerlauf war.
Spam-Bewertung mit Punkten statt Ja oder Nein
Danach bekommt jede Einsendung einen Punktwert. Ein Link im Text zählt 3 Punkte, eine bekannte Spam-Phrase ebenfalls 3, englischer Text ohne ein einziges deutsches Wort 2 Punkte, ein Text ohne jede Bewertung 1 Punkt, ein sehr kurzer Text 1 Punkt. Ab 4 Punkten gilt die Einsendung als Spam und wird verworfen.
Der Punktwert ist der wichtigste Unterschied zu einem starren Filter: Ein einzelnes Merkmal reicht nie aus. Ein kurzer deutscher Kommentar ohne Bewertung fliegt nicht raus, ein englischer Text mit Link und Werbephrase sehr wohl. Die Regeln lassen sich erweitern, ohne dass ich die Logik anfassen muss.
Bewertung zuordnen
Das Formular liefert die Bewertung nicht als saubere Zahl, sondern je nach Feld als 4|🙂, als reines Emoji oder unter wechselnden Feldnamen. Ein Zuordnungsschritt sammelt alle möglichen Varianten ein, nimmt den ersten belegten Wert und schlägt ihn in einer Tabelle nach. Heraus kommen drei sauber getrennte Angaben: Zahl von 1 bis 5, Textstufe wie „Gut", und das Emoji.
Das ist der unspektakulärste Teil und derjenige, der am meisten Ärger erspart. Alles danach rechnet mit einer Zahl und muss keine Emojis mehr kennen.
Speichern mit Fallback
Die Bewertung wird als neue Zeile in einer Tabelle abgelegt: Beitragstitel, Post-ID, Bewertung als Zahl und als Text, Anmerkung, Zeitpunkt. Der Schritt versucht es bei einem Fehler automatisch erneut.
Wenn die Tabelle trotzdem nicht erreichbar ist, geht die Bewertung nicht verloren, sondern in eine Tabelle innerhalb von n8n – und ich bekomme eine Nachricht per Telegram. Genau das ist der Teil, den ich beim ersten Bauen weggelassen hätte und der sich am deutlichsten gelohnt hat: Ein Ausfall beim Dienstleister kostet mich keine Daten, sondern nur eine Nacharbeit.
Kategorie nachtragen
Ist die Zeile gespeichert, holt der Workflow über die WordPress-API den Beitrag, liest dessen Kategorien und schreibt den Kategorienamen in dieselbe Zeile nach. Die Kategorie „vorgestellt" wird dabei übersprungen, weil sie nichts über das Thema aussagt. Damit kann ich später auswerten, welche Themenbereiche gut ankommen, ohne die Bewertungen einzeln durchzusehen.
Workflow 2: Durchschnitte berechnen und zurückschreiben
Der zweite Workflow arbeitet nicht mit einzelnen Bewertungen, sondern mit dem gesamten Bestand. Ich starte ihn bewusst von Hand, weil er alle Beiträge anfasst und ich sehen will, was er tut.
Der Ablauf im Detail: Alle Zeilen der Tabelle werden gelesen, Zeilen ohne Bewertung fallen heraus. Anschließend werden die Bewertungen je Post-ID zusammengefasst – Summe, Anzahl und Durchschnitt auf zwei Dezimalstellen. Anschließend geht jeder Beitrag in eine Schleife, die ihn einzeln über die WordPress-API aktualisiert und drei Werte in die Beitrags-Metadaten schreibt: Anzahl, Summe und Durchschnitt.
Zwischen den Aufrufen liegt eine kurze Wartezeit, damit ich die Schnittstelle meines eigenen Blogs nicht mit einem Schlag durchrattere. Jeder Aufruf hat zwei Versuche; scheitert er, überspringt die Schleife diesen Beitrag und macht mit dem nächsten weiter, statt den ganzen Lauf abzubrechen.
Entscheidungen
Kein Plugin. Für Bewertungen gibt es fertige WordPress-Erweiterungen. Ich wollte keine zusätzliche Abhängigkeit im Blog, keinen unnötigen Overhead und keine Blackbox, in die ich bei Problemen nicht hineinsehen kann. Mit n8n war die Infrastruktur in meinem Homelab ohnehin vorhanden, und ich war damit schneller am Ergebnis als mit Auswahl, Einrichtung und Pflege eines Plugins.
Elementor-Formulare für die Übertragung. Das Formular selbst baue ich mit Elementor, das im Blog schon im Einsatz ist, und lasse es die Daten an den Webhook schicken. Das funktioniert zuverlässig, und ich musste im Blog nichts eigenes entwickeln.
Google Sheets als Ablage. Das ist die Entscheidung, die am meisten Erklärung braucht – und sie hängt daran, dass hier keine personenbezogenen Daten anfallen. Die Bewertung ist schon im Blog anonym: keine Anmeldung, keine Kennung, keine Adresse. Übertragen wird serverseitig, als Absender erscheint immer der Blog-Server. Hinter dem Blog lässt sich also nicht mehr feststellen, von wem eine Bewertung kam.
Damit ist Google an dieser Stelle unproblematisch, und ich bekomme etwas, das ich sonst selbst bauen müsste: eine Oberfläche zum Auswerten. Ich sortiere, filtere und rechne direkt in der Tabelle, ohne eine eigene Ansicht dafür zu entwickeln.
Was ich anders machen würde
Der Schwachpunkt ist die Auswertung über die Zeit. Die Tabelle zeigt gut, wie ein Beitrag im Moment dasteht, aber schlecht, wie sich das Feedback entwickelt hat. Eine eigene Auswertungsansicht mit Verlauf über Wochen und Monate wäre der nächste sinnvolle Schritt – dann sieht man auch bei älteren Beiträgen, ob eine Überarbeitung tatsächlich etwas verbessert hat.
Fehlerbehandlung an drei Stellen
- Ungültige Eingaben werden früh verworfen, statt später Fehler zu erzeugen. Die Prüfung auf eine numerische Post-ID kostet nichts und fängt sowohl Spam als auch kaputte Formularabsendungen.
- Speicherfehler führen nicht zum Datenverlust: Wiederholversuch, danach Ausweichspeicher in n8n und eine Nachricht an mich.
- Fehler beim Zurückschreiben betreffen immer nur einen Beitrag. Die Schleife läuft weiter, der nächste Lauf holt den Beitrag automatisch nach, weil er ohnehin alles neu berechnet.
Ergebnis
Aktuell liegen 479 Bewertungen mit einem Durchschnitt von 4,42 von 5 vor (Stand 08/2026). Für mich zählt daran weniger die Note als die Verteilung: Ich sehe, welche Beiträge Rückfragen auslösen und welche Themen bei Lesern tatsächlich funktionieren – und schreibe darauf aufbauend weiter.
Die Zeitersparnis liegt bei etwa zwei Minuten pro Einsendung, die ich sonst mit Abtippen, Zuordnen und Nachrechnen verbringen würde. Bei ein paar hundert Bewertungen ist das der Punkt, an dem sich der Bau gelohnt hat – vorher nicht.
Mein Fazit
Zwei Dinge nehme ich aus diesem Aufbau mit, und beide sind auf andere Workflows übertragbar. Erstens: Annahme und Auswertung trennen. Was sofort passieren muss, sollte klein und robust bleiben; alles, was rechnen und viele Systeme anfassen muss, darf später und gesammelt laufen. Zweitens: Filter mit Punkten statt mit Ja oder Nein. Ein einzelnes Merkmal ist selten aussagekräftig, mehrere zusammen schon.
Und drittens etwas, das ich beim ersten Bauen unterschätzt habe: Ein Ausweichweg mit Benachrichtigung ist kein Luxus. Genau der Schritt entscheidet, ob ein Ausfall Daten kostet oder nur Nacharbeit. Mehr Workflows aus dem laufenden Betrieb stehen auf der Seite zu den n8n-Automationen.